Back
[03:05:53] <cradek> hmm, G7G10L1P1X1, should X be rad or dia?
[03:07:59] <SWPadnos> for some reason, that looks like roman numerals to me
[03:08:13] <cradek> I can always count on you to help :-)
[03:08:38] <SWPadnos> heh
[03:08:53] <SWPadnos> G7/G8 mean rad/dia?
[03:09:03] <cradek> yes G7 is diameter mode
[03:09:26] <SWPadnos> ah, G10L1 is "set tool <urk>"
[03:09:28] <SWPadnos> (radius)
[03:10:01] <cradek> G10L1P1 is set the tool table entry for tool 1
[03:10:17] <SWPadnos> I think I'd look at G7 as a distance mode (like G90/G91), not a units mode like G20/G21
[03:10:38] <SWPadnos> so I would expect X to be radius (assuming that's the
[03:10:50] <SWPadnos> "normal" definition of X with G10L1Px)
[03:15:06] <fenn> G10 is "offsets" so it should be radius
[03:15:17] <fenn> but what do i know
[03:17:38] <cradek> g10 units change with g20/g21 mode...
[03:17:50] <cradek> g10 does not change with g90/g91
[03:18:11] <SWPadnos> right
[03:18:15] <fenn> what modal group is G7/8?
[03:18:22] <SWPadnos> it's new! :)
[03:18:27] <fenn> is this even in a spec somewhere?
[03:18:34] <SWPadnos> I think it's a new group actually
[03:18:43] <fenn> hm then i'd just say you cant have it on the same line
[03:18:53] <fenn> diameter mode can go to hell
[03:19:01] <SWPadnos> since you could have mm/inch or absoute/relative diameters/radii
[03:19:21] <cradek> fenn: there's a reference implementation... too bad it's not complete yet
[03:19:32] <fenn> what's the reference implementation?
[03:19:37] <cradek> emc2
[03:20:29] <cradek> there's no agreement on how any of this crap works, so it's up to us to try to make our implementation sane
[03:20:38] <fenn> sounds like circular logic
[03:20:54] <cradek> forget I asked
[03:21:36] <SWPadnos> cradek, I think the tool offset should always be a radius
[03:22:10] <cradek> in the tool table, it is always saved as a radius (just like the tool table and var file is always in native units)
[03:22:22] <SWPadnos> unless there's a different code (G10L3 or some such) that says you're specifying a diameter
[03:23:06] <SWPadnos> sure, so I think the principle of least confusion is to use the number that will end up in the tool table
[03:23:26] <SWPadnos> "I programmed a 0.5, and all I saw was 0.25 in the tool table" ...
[03:23:50] <cradek> would you make the same argument for g20/g21? if so I'm pretty sure we disagree there
[03:24:08] <SWPadnos> well, that's an existing tool table problem
[03:24:12] <cradek> I think I'm coming around to the other side actually
[03:24:13] <SWPadnos> I think the tool table should have units in it
[03:24:24] <SWPadnos> 1mm, 5/8" ...
[03:24:25] <cradek> it does - they're native machine units
[03:24:39] <cradek> I see what you mean
[03:24:52] <cradek> that would be another approach that would work just as well
[03:24:52] <SWPadnos> does G21G10L1P1X10 mean 10mm on an inch machine?
[03:25:41] <cradek> yes
[03:25:54] <SWPadnos> oh
[03:26:00] <SWPadnos> well then I don't know :)
[03:27:47] <cradek> damn these tuples and lists
[03:27:55] <cradek> I don't understand why there are two types
[03:28:33] <cradek> a=(1,2,3)
[03:28:44] <cradek> how do I spell a[0] *= 2
[03:28:59] <cradek> not [a]
[03:29:03] <cradek> not a[:]
[03:29:25] <cradek> a=list(a)
[03:30:31] <SWPadnos> heh
[03:30:52] <SWPadnos> hey, can you do G91G10L1P1X-0.001 to shave a thou off a tool size?
[03:31:04] <cradek> no
[03:31:08] <SWPadnos> bummer
[03:31:23] <cradek> G10L2 does not act differently with G90/G91 (by ngc spec) so G10L1 doesn't either
[03:31:37] <cradek> in my research I found that some machines do, fwiw
[03:31:52] <SWPadnos> well, it's a relative size change, rather than an absolute size spec
[03:32:00] <SWPadnos> you know, sort of
[03:32:05] <cradek> yeah, sort of
[03:32:10] <cradek> I can sure see it as useful
[03:32:15] <cradek> and/or confusing :-P
[03:32:31] <SWPadnos> it would make sense to me if all three sets of codes changed how G10L1 worked
[03:32:47] <SWPadnos> units, rad/dia, and difference or absolute
[03:32:49] <cradek> I sympathize with that position
[03:33:02] <SWPadnos> and yet I'm mostly powerless to change it, so I'll stop there :)
[03:34:13] <cradek> it's so obscure you might rightfully believe that nobody has ever written that gcode, so we could probably change it if we wanted.
[03:34:35] <SWPadnos> G10L1 was only added in the last year or so, wasn't it?
[03:34:38] <SWPadnos> maybe 6 months
[03:34:40] <cradek> yes
[03:34:52] <cradek> I did that recently
[03:34:53] <SWPadnos> and it's mostly useful from MDI only, right?
[03:35:04] <cradek> I would not want G10L1 and G10L2 to be different though
[03:35:13] <SWPadnos> oh, I suppose it would be useful as a way of putting the tool table into a G-code file
[03:35:15] <cradek> AXIS uses it for tool length touch off
[03:35:18] <SWPadnos> sure
[03:35:20] <cradek> yes definitely
[03:35:39] <cradek> you give the operator the tool cart and a paper tape with the tool table...
[03:35:40] <SWPadnos> but the number of programs that do that are likely quite few
[03:35:43] <SWPadnos> heh
[03:37:38] <jmk-robot> Jymm annoys me sometimes
[03:37:48] <jmk-robot> nothing wrong with OT when the channel is quiet, but...
[03:37:50] <SWPadnos> heh
[03:38:05] <SWPadnos> yeah, I usually agree. I wonder why I'm answering
[04:00:54] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: fix tool touch off for lathe diameter mode
[06:49:14] <micges> good morning
[06:49:58] <micges> I was wonder how can be described custom events patch to make a tool change?
[06:51:21] <micges> movings are asy, just add line with end points when you wand to move there
[06:52:13] <micges> but what about hal pins ? (stop spindle, move ,unlock, flush , lock, start spindle, all as a hal pins) ?
[06:56:01] <micges> any comments are welcome
[07:15:13] <micges> (coding it now)
[08:02:13] <micges> (heh custom events path I mean)
[08:47:07] <alex_joni> depends on what level you are doing it
[08:47:25] <alex_joni> if it's in canon (where it should be), then you can call things like SPINDLE_STOP()
[08:48:41] <micges> yes in canon
[08:50:23] <micges> alex_joni: intep list are append in canon, and where is it get() ?
[08:50:29] <alex_joni> in task\
[08:50:42] <alex_joni> which looks at them, and based on the type sends them to io or motion
[08:51:29] <micges> so main case of task is always running no matter is it program, manual, estop ?
[08:51:59] <alex_joni> there are different cases based on mode
[08:52:08] <micges> I know
[08:52:37] <alex_joni> task is the one that calls the interpreter
[08:52:41] <alex_joni> which calls canon calls
[08:55:35] <micges> many layers but I can handle it :)
[08:55:37] <micges> thanks
[08:59:03] <micges> one more question: what usrmotintf.cc do ?
[08:59:46] <micges> I can handle task data flow more less but what this ^^ ?
[09:01:25] <micges> and in what module is it ? I can't find it on lsmod, halcmd show modules, ps -A ?
[09:15:55] <alex_joni> it sends some init things to motion
[09:16:01] <alex_joni> I think it gets linked into task
[09:18:27] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/Submakefile?rev=1.6
[09:18:37] <alex_joni> MILLTASKSRCS := \
[09:18:50] <alex_joni> emc/motion/usrmotintf.cc \
[09:19:13] <micges> I se
[09:19:16] <micges> e
[09:21:33] <micges> in there is funct usrmotWriteEmcmotCommand which copy command to shared memory allocated in emcsvr and which is in each servo cylce checked in command.c, right ?
[09:24:39] <alex_joni> no, emcsvr has nothing to do with the motion shared memory
[09:25:05] <alex_joni> but the update status function does copy the data from command.c to the shared memory read by motion and task
[09:25:16] <alex_joni> task then puts the data into the NML status
[09:25:20] <alex_joni> which then gets to emcsvr
[12:41:04] <BigJohnT> Is it by design that I get an error if I program a G41 G1 on the same line without any X or Y?
[12:41:05] <BigJohnT> The error is "Lenght of cutter compensation entry move is not greater than the tool radius"
[12:44:12] <BigJohnT> morning alex_joni
[12:52:42] <micges> cradek: extentions to toolchanger (tool_change_with_spindle_on, tool_change_quill_up, tool_change_at_g30) was implemented in interpreter ad move to tool change position was coded in canon, why ?
[12:58:42] <BigJohnT> I don't think he is awake yet micges :)
[12:59:41] <micges> heh ok :)
[14:03:59] <jepler> yeah, who gets up before 7AM on a saturday -- crazy talk
[14:21:58] <BigJohnT> I was up at 5am :/
[14:22:35] <BigJohnT> but didn't want to :(
[14:22:42] <jepler> as long as you didn't want to, that's OK
[14:22:50] <jepler> it's people who want to be up at 5AM I can't quite fathom
[14:23:15] <BigJohnT> no, my back was killing me from falling on the ice thursday
[14:23:54] <jepler> oh ugh
[14:25:12] <BigJohnT> mmm, I smell bacon
[14:26:21] <micges> jepler: I don't want to someone be up early or something
[14:27:15] <micges> I just send question to him and when he want(can) will answer me, as always here
[15:25:23] <cradek> micges: canon level does not know where the reference point is. also it was the interp that previously sent the spindle off message, so it had to be suppressed there. but I think quill up could have been programmed either place.
[15:25:57] <cradek> the tool change position in canon was there previously so I left it alone.
[15:27:44] <cradek> it would be nice if we had a more comprehensive solution
[15:28:48] <micges> can I acces hal from canon in any way ?
[15:29:22] <micges> indirect?
[15:30:05] <cradek> I started once to write what you want, but I did not succeed
[15:30:48] <micges> can you share what was the idea?
[15:32:09] <cradek> I think I never had a workable idea
[15:34:20] <jepler> the way the interpreter interacts with the external world is through the canon API. I don't think this should change. If the interpreter starts doing things that aren't captured in canon calls, it makes integrating the interpreter in other programs like sai and axis more difficult or impossible.
[15:35:13] <micges> I don't want to change any interface especially canon
[15:35:20] <cradek> jepler: do you remember when I tried to write the arbitrary tool change motion what problem I ran into?
[15:35:56] <jepler> cradek: no, I don't.
[15:38:34] <cradek> hmm, bigjohnt's bug is a feature I wrote on purpose (don't show rapids used for entry after a tool change)
[15:40:03] <cradek> bbl
[16:40:05] <micges> jepler: about bug SF#2457397 : in what state EMC must be while waiting for tool-prepared signal ?
[16:47:34] <jepler> tool-prepared should only be asserted by the tool changer when tool-prepare is true.
[16:48:09] <jepler> it should be asserted starting when the tool preparation is complete, until tool-prepare becomes false again. this is how iotask signals to the tool changer that it has received the tool-prepared signal
[16:52:27] <jepler> http://pastebin.ca/1329983
[16:54:10] <micges> jepler: thanks
[16:57:53] <micges> I've commented interp_conver.cc cheching in 4095 and now emc is in "waiting for motion and io" state and is almost non responsible until I setp tool-prepared
[16:58:26] <micges> I think iocontrol checking while tool change must be redone and will be wroking
[17:01:37] <jepler> the easiest way to avoid that bug you mentioned is to simply always to T# and M6 on the same line in MDI
[17:02:00] <alex_joni> I tried to fix that, but only managed to make it worse
[17:02:41] <alex_joni> I don't think it's a big problem to do T#M6 in MDI on the same line
[17:05:05] <micges> ok, its not a problem
[19:08:57] <micges> It is unwanted that iocontrol will generate motion messages ?
[19:09:41] <alex_joni> how would it do that?
[19:10:38] <micges> I don't know
[19:11:11] <alex_joni> I don't see a way for it to do that (at the moment)
[19:11:20] <micges> acces to interp list maybe ?
[19:11:34] <micges> ok its stupid
[19:11:40] <micges> nevermind
[19:11:48] <alex_joni> currently iocontrol only gets messages from task
[19:11:53] <alex_joni> there is no reverse communication
[19:11:57] <alex_joni> only status report
[19:42:15] <CIA-2> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/spy_vars_gtk.c: fix missing description of %I and %Q variables in variable window. Changed name of the vars windows - again
[23:02:32] <BigJohnT> heh, I found a feature bug :)
[23:13:37] <SWPadnos> BigJohnT, for some reason, that reminds me of the movie "Raising Arizona"
[23:13:44] <SWPadnos> "Well son, which is it?" :)
[23:14:45] <BigJohnT> LOL
[23:18:35] <alex_joni> SWPadnos: he doesn't want to share
[23:18:44] <SWPadnos> apparently not
[23:25:44] <BigJohnT> whodat?
[23:27:43] <SWPadnos> the feature bug
[23:27:51] <SWPadnos> we still don't know what it is
[23:28:00] <SWPadnos> 'cause you're not telling :)
[23:28:08] <BigJohnT> oh me?
[23:28:16] <SWPadnos> yes you
[23:28:19] <SWPadnos> (Charlie Brown)
[23:28:35] <BigJohnT> it is the one where I put in a bug report and cradek had made it so as a feature :)
[23:28:46] <SWPadnos> heh, well OK then :)
[23:28:58] <BigJohnT> but I just knew it was a bug :)
[23:31:27] <BigJohnT> now if I can just find my insurance card for the motorcycle in case it doesn't rain 8 days out of 7 next week :/