Back
[14:50:09] <jepler> actually I think that transmitting the gcode program from the machine with the GUI to the machine running emc is a perfectly sensible solution to the problem, better than requiring the two machines to have the same filesystem. Making the user explicitly copy a file is not good, particularly when you are generating code on the fly (i2g, gwiz, holecircle, etc)
[14:57:01] <cradek> I think I agree
[14:59:07] <jepler> on the other hand, nml doesn't seem to have a stream-type primitive, so you're stuck writing some small number of bytes (thousands at most) in a command request, waiting for the command to be received, and repeating until you're done
[14:59:25] <jepler> I have a feeling that will be slow
[15:00:42] <cradek> an nml message could set up another channel (tcp)
[15:00:47] <alex_joni> well.. maybe emcsvr could be extended with a streaming port to listen on
[15:01:02] <alex_joni> then the GUI just sends teh preparing messages, and feeds the data directly to that port
[15:01:18] <alex_joni> emcsrv then feeds stuff into task/interp like it would be a file
[15:02:03] <cradek> should task cache some or all of the file?
[15:02:37] <jepler> I imagined the whole file would be transferred to a file on the machine where task runs, then task would be instructed to open that file
[15:02:57] <alex_joni> yeah, that can work easily
[15:03:16] <jepler> the file might contain o-word subroutines, so I think it has to be completely present so that it can be reopened, seek'd, etc
[15:03:24] <cradek> oh right
[15:03:38] <alex_joni> and that it can reference O-words in the same dir ..
[15:03:44] <cradek> but isn't this just half the problem? how does the file get to the other guis if they need it?
[15:03:46] <alex_joni> (which obviously is a problem..)
[15:04:16] <alex_joni> what if it references a o-word function from another file, not available on the server
[15:04:24] <jepler> luckily I don't need this feature so I'll probably never do more than speculate about how it should be implemented
[15:04:36] <cradek> maybe we should use nfs
[15:04:55] <alex_joni> assuming the remote is on *nix
[15:04:55] <jepler> I think the people who want this feature want the other computer to be an OS that *cough* doesn't support nfs
[15:05:06] <alex_joni> smb :P
[15:05:28] <alex_joni> cradek: people wanting this can smbmount a certain share from the GUI PC
[15:05:58] <alex_joni> so on the linux box (emc2 on it) you just mount a whole dir with files & all
[15:05:59] <cradek> since I don't need to make money with emc, I have the luxury of not caring about windows
[15:06:03] <alex_joni> :D
[15:07:25] <jepler> I'll change my position again -- a shared filesystem is the way to go. in that case, the GUI needs a small amount of smarts to map between the local and remote paths for a file in the shared filesystem
[15:07:50] <jepler> the O-word subroutines from different files clenches it; It would be even worse to build into the GUI the logic to look through the program and find all O-words that might be called..
[15:07:58] <jepler> (since that's impossible anyway)
[15:08:34] <jepler> M66 E0 ; O#5399 call
[15:09:18] <cradek> haha
[15:09:22] <jepler> (does M66 E- work?)
[15:09:28] <jepler> (or was it never quite finished?)
[15:10:13] <cradek> g38.2 z0; O#5063 call
[15:22:45] <alex_joni> jepler: it does work
[15:23:08] <alex_joni> but it's only in TRUNK
[15:23:19] <alex_joni> (maybe you can be talked into a backport?)
[15:25:18] <jepler> the 2.2 documentation lists M66 E- so it should probably work :-P
[15:25:29] <jepler> how extensive are the required changes?
[15:25:42] <jepler> can you prepare a 2.2 checkout with the changes and let me read a diff?
[15:41:29] <alex_joni> I can do that when I get back home.. (I think I had it all in one commit though.. let me check)
[15:42:24] <alex_joni> it's work not touching other areas iirc
[15:43:13] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/motion.c.diff?r1=1.107;r2=1.108
[15:43:34] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/motion.h.diff?r1=1.88;r2=1.89
[15:44:07] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/control.c.diff?r1=1.134;r2=1.135
[15:44:23] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/emcmotcfg.h.diff?r1=1.12;r2=1.13
[15:44:57] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/mot_priv.h.diff?r1=1.64;r2=1.65
[15:45:40] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/taskintf.cc.diff?r1=1.82;r2=1.83
[15:46:01] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/emccanon.cc.diff?r1=1.120;r2=1.121
[15:46:52] <alex_joni> (I think those are the files I touched.. maybe I can find a complete list in the emc-commit archive..)
[15:48:13] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/nml_intf/emc_nml.hh.diff?r1=1.11;r2=1.12
[15:48:29] <jepler> It can wait until you're home again
[15:48:45] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/nml_intf/emcglb.h.diff?r1=1.15;r2=1.16
[15:48:51] <cradek> we should be able to make a diff by date (-D)
[15:48:53] <alex_joni> it's only 3-4 lines on each file :)
[15:49:14] <alex_joni> revision 1.12
[15:49:14] <alex_joni> date: 2007/11/12 20:08:00; author: alex_joni; state: Exp; lines: +1 -0
[15:55:06] <jepler> except for the $Tag$s the patches apply cleanly..
[15:55:19] <cradek> you're missing interp_convert
[15:55:28] <cradek> RCS file: /cvs/emc2/src/emc/rs274ngc/interp_convert.cc,v
[15:55:28] <cradek> retrieving revision 1.99
[15:55:28] <cradek> retrieving revision 1.100
[15:56:00] <alex_joni> yeah, I stopped when jepler said it can wait..
[15:56:04] <jepler> oh
[15:56:23] <cradek> I think that's the only one missing
[15:56:32] <alex_joni> interp_convert.cc is the last one
[15:56:32] <cradek> I found 10 files and you have 9 URLs above
[15:56:38] <alex_joni> err.. no
[15:56:39] <cradek> I agree
[15:56:41] <jepler> rcsmerge: warning: conflicts during merge
[15:56:48] <alex_joni> changelog should be the last one :D
[15:57:02] <alex_joni> cradek: bet you only ran it in src/
[15:57:08] <jepler> oh it was just the $Tag$ block .. I thought 'cvs up -j' was smarter than that
[15:57:20] <cradek> jepler: nope that happens all the time to me
[15:58:14] <cradek> there may or may not be a -k flag that will avoid that
[15:59:00] <cradek> diff -kk
[15:59:47] <cradek> so maybe cvs up -j -kk
[16:02:53] <jepler> seems to work
[16:03:20] <jepler> cradek: do you have any concerns about backporting this feature?
[16:07:03] <cradek> not really
[16:07:08] <alex_joni> I do have one
[16:07:25] <alex_joni> so far I know of no other people to have actually tested this besides me..
[16:07:40] <alex_joni> (it certainly/hopefully doesn't break anything else..)
[16:09:36] <jepler> I see it prints debug output that should probably be squashed
[16:09:55] <alex_joni> yeah.. I saw that in the diff's
[16:10:13] <alex_joni> one of these days we should revise the debug methods throughout emc2
[16:11:33] <jepler> here's the patch I have in one piece, in case anybody else cares to skim it:
http://emergent.unpy.net/files/sandbox/implement-m66-e.patch
[16:12:10] <cradek> thanks
[16:13:02] <jepler> hm, "cvs diff -kk" dies with an error
[16:13:03] <jepler> cvs [diff aborted]: cannot open file .cvsignore for comparing: No such file or directory
[16:13:19] <jepler> so you'll have to look at the spurious $Tag$s in the diff
[16:13:37] <cradek> I hate those stupid tags
[16:13:45] <cradek> if I ran the world...
[16:14:05] <jepler> se ondseconded.
[16:14:11] <jepler> er..
[16:14:13] <jepler> seconded
[16:14:25] <jepler> * jepler manually removed the $Tag$ patch chunks and reuploaded the file
[16:15:08] <cradek> I don't see any problem with this patch
[16:15:28] <alex_joni> I only miss one bit of info in there
[16:15:36] <alex_joni> * alex_joni check if he didn't do that earlier
[16:17:21] <alex_joni> _setup.parameters[5399] = GET_EXTERNAL_ANALOG_INPUT(_setup.input_index);
[16:17:38] <alex_joni> ok, I already had that in rs274ngc_pre.cc, so I'm happy with the diff
[16:17:45] <cradek> I think there's a check missing
[16:17:50] <cradek> both P and E words
[16:18:02] <jepler> I get an error for that
[16:18:07] <jepler> must have been another preexisting check?
[16:18:15] <cradek> oh I see it, sorry
[16:18:17] <jepler> emc/task/emctask.cc 312: interp_error: Invalid to select both a digital and an analog input with M66
[16:18:26] <alex_joni> cradek: the check was already there
[16:18:32] <cradek> oh I see it, sorry
[16:18:52] <alex_joni> sorry I didn't get my things together and did thise before the branch
[16:19:04] <jepler> this is accepted, and it goes to the old value of #5399 (but that's consistent with the way parameter modification occurs) m66p1g0x#5399
[16:19:52] <alex_joni> that's interp related imo
[16:19:57] <cradek> if (round_to_int(block->p_number) < 0) // safety check for negative words
[16:20:01] <cradek> this is redundant
[16:21:58] <cradek> why is wait timeout in integer seconds?
[16:22:06] <cradek> that's not how G4 works
[16:23:30] <cradek> that's not an issue for this backport but I think it's a bug
[16:26:23] <alex_joni> I probably agree with you
[16:26:33] <alex_joni> although I think I tested .5 delays
[16:45:17] <cradek> how could you have done that?
[16:50:49] <alex_joni> I question my sanity after reading the code :)
[16:51:35] <cradek> maybe round_to_int rounded it and you didn't notice
[16:52:21] <alex_joni> probably so..
[16:54:10] <cradek> #define round_to_int(x) ((int) ((x) < 0.0 ? ((x) - 0.5) : ((x) + 0.5)))
[16:54:17] <cradek> yeah it's not an error if it's not close to an int
[19:06:14] <cradek> when we revise the tool table let's keep in mind a 'nominal' value
[19:10:01] <skunkworks941> cradek: I ran b into the soft limit - after that - I could not really jog anything :)
[19:10:44] <skunkworks941> it is pretty cool when you jog B it keeps the tool tip in the same location. I have not played with more than 3 axis - so that was suprising.
[19:10:56] <cradek> skunkworks941: MDI works much better...
[19:11:21] <cradek> also if you move W it goes in whatever direction the tool is pointed. so, you could drill a hole or something, at any angle.
[19:11:43] <skunkworks941> Nice
[19:11:51] <cradek> when W=0, the tooltip is at XYZ and the tool points in the direction defined by BC
[19:13:24] <cradek> I think I am going to try to make max 5 axis to play with...
[19:13:41] <skunkworks941> hey - your right.
[19:13:51] <cradek> ?
[19:13:52] <skunkworks941> although you cannot jog the w axis. Only mdi it.
[19:14:00] <skunkworks941> that is cool
[19:14:13] <cradek> yes that's another way teleop is broken
[19:14:18] <cradek> no uvw support
[19:14:55] <skunkworks941> how do you plan on making the 4,5 axis?
[19:15:03] <skunkworks941> 2 rotory tables?
[19:15:07] <cradek> I have two rotary tables (one is already cnc)
[19:15:12] <skunkworks941> cool
[19:23:10] <skunkworks941> http://youtube.com/watch?v=w0-tXDEvAqg
[19:24:39] <cradek> yeah that's the other design I've considered
[19:25:18] <cradek> but it should be deeper so you don't need so much Y travel
[19:25:28] <skunkworks941> I want to make a big one for the K&T
[19:25:41] <skunkworks941> some day
[19:25:46] <cradek> go for it...
[19:26:50] <skunkworks941> we have some rather large high quallity rotory tables
[19:27:19] <cradek> I have one large one - I would need a second (slightly smaller) for the bridgeport
[19:28:36] <jepler> wasn't there a time not too long ago when *related* videos were shown inside the youtube player when the video was done?
[19:28:57] <jepler> now it's "amazing music" and "high speed motorcycle" and crap
[19:29:12] <skunkworks941> yes
[19:29:26] <skunkworks941> down the right side though gives similar videos
[22:04:40] <tissf> good night all
[23:51:42] <tomp2> the puma.hal puma.py example doesnt use the device.number.pinname scheme when it uses r.joint1 r.joint2 ( got no number) ...
[23:51:48] <tomp2> can we expect the rule to hold true usually?
[23:51:49] <tomp2> i was going to use it as an example of gEDA automatically generating a hal file.
[23:53:30] <tomp2> can i fake it by saying loadusr -Wn r.0 python puma.y ??
[23:55:48] <tomp2> nope waiting from component r.0 to become ready is forever :(