hmm, G7G10L1P1X1, should X be rad or dia?
for some reason, that looks like roman numerals to me
I can always count on you to help :-)
G7/G8 mean rad/dia?
yes G7 is diameter mode
ah, G10L1 is "set tool <urk>"
G10L1P1 is set the tool table entry for tool 1
I think I'd look at G7 as a distance mode (like G90/G91), not a units mode like G20/G21
so I would expect X to be radius (assuming that's the
"normal" definition of X with G10L1Px)
G10 is "offsets" so it should be radius
but what do i know
g10 units change with g20/g21 mode...
g10 does not change with g90/g91
what modal group is G7/8?
it's new! :)
is this even in a spec somewhere?
I think it's a new group actually
hm then i'd just say you cant have it on the same line
diameter mode can go to hell
since you could have mm/inch or absoute/relative diameters/radii
fenn: there's a reference implementation... too bad it's not complete yet
what's the reference implementation?
there's no agreement on how any of this crap works, so it's up to us to try to make our implementation sane
sounds like circular logic
forget I asked
cradek, I think the tool offset should always be a radius
in the tool table, it is always saved as a radius (just like the tool table and var file is always in native units)
unless there's a different code (G10L3 or some such) that says you're specifying a diameter
sure, so I think the principle of least confusion is to use the number that will end up in the tool table
"I programmed a 0.5, and all I saw was 0.25 in the tool table" ...
would you make the same argument for g20/g21? if so I'm pretty sure we disagree there
well, that's an existing tool table problem
I think I'm coming around to the other side actually
I think the tool table should have units in it
1mm, 5/8" ...
it does - they're native machine units
I see what you mean
that would be another approach that would work just as well
does G21G10L1P1X10 mean 10mm on an inch machine?
well then I don't know :)
damn these tuples and lists
I don't understand why there are two types
how do I spell a *= 2
hey, can you do G91G10L1P1X-0.001 to shave a thou off a tool size?
G10L2 does not act differently with G90/G91 (by ngc spec) so G10L1 doesn't either
in my research I found that some machines do, fwiw
well, it's a relative size change, rather than an absolute size spec
you know, sort of
yeah, sort of
I can sure see it as useful
and/or confusing :-P
it would make sense to me if all three sets of codes changed how G10L1 worked
units, rad/dia, and difference or absolute
I sympathize with that position
and yet I'm mostly powerless to change it, so I'll stop there :)
it's so obscure you might rightfully believe that nobody has ever written that gcode, so we could probably change it if we wanted.
G10L1 was only added in the last year or so, wasn't it?
maybe 6 months
I did that recently
and it's mostly useful from MDI only, right?
I would not want G10L1 and G10L2 to be different though
oh, I suppose it would be useful as a way of putting the tool table into a G-code file
AXIS uses it for tool length touch off
you give the operator the tool cart and a paper tape with the tool table...
but the number of programs that do that are likely quite few
Jymm annoys me sometimes
nothing wrong with OT when the channel is quiet, but...
yeah, I usually agree. I wonder why I'm answering
EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: fix tool touch off for lathe diameter mode
I was wonder how can be described custom events patch to make a tool change?
movings are asy, just add line with end points when you wand to move there
but what about hal pins ? (stop spindle, move ,unlock, flush , lock, start spindle, all as a hal pins) ?
any comments are welcome
(coding it now)
(heh custom events path I mean)
depends on what level you are doing it
if it's in canon (where it should be), then you can call things like SPINDLE_STOP()
yes in canon
alex_joni: intep list are append in canon, and where is it get() ?
which looks at them, and based on the type sends them to io or motion
so main case of task is always running no matter is it program, manual, estop ?
there are different cases based on mode
task is the one that calls the interpreter
which calls canon calls
many layers but I can handle it :)
one more question: what usrmotintf.cc do ?
I can handle task data flow more less but what this ^^ ?
and in what module is it ? I can't find it on lsmod, halcmd show modules, ps -A ?
it sends some init things to motion
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
MILLTASKSRCS := \
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 ?
no, emcsvr has nothing to do with the motion shared memory
but the update status function does copy the data from command.c to the shared memory read by motion and task
task then puts the data into the NML status
which then gets to emcsvr
Is it by design that I get an error if I program a G41 G1 on the same line without any X or Y?
The error is "Lenght of cutter compensation entry move is not greater than the tool radius"
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 ?
I don't think he is awake yet micges :)
heh ok :)
yeah, who gets up before 7AM on a saturday -- crazy talk
I was up at 5am :/
but didn't want to :(
as long as you didn't want to, that's OK
it's people who want to be up at 5AM I can't quite fathom
no, my back was killing me from falling on the ice thursday
mmm, I smell bacon
jepler: I don't want to someone be up early or something
I just send question to him and when he want(can) will answer me, as always here
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.
the tool change position in canon was there previously so I left it alone.
it would be nice if we had a more comprehensive solution
can I acces hal from canon in any way ?
I started once to write what you want, but I did not succeed
can you share what was the idea?
I think I never had a workable idea
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.
I don't want to change any interface especially canon
jepler: do you remember when I tried to write the arbitrary tool change motion what problem I ran into?
cradek: no, I don't.
hmm, bigjohnt's bug is a feature I wrote on purpose (don't show rapids used for entry after a tool change)
jepler: about bug SF#2457397 : in what state EMC must be while waiting for tool-prepared signal ?
tool-prepared should only be asserted by the tool changer when tool-prepare is true.
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
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
I think iocontrol checking while tool change must be redone and will be wroking
the easiest way to avoid that bug you mentioned is to simply always to T# and M6 on the same line in MDI
I tried to fix that, but only managed to make it worse
I don't think it's a big problem to do T#M6 in MDI on the same line
ok, its not a problem
It is unwanted that iocontrol will generate motion messages ?
how would it do that?
I don't know
I don't see a way for it to do that (at the moment)
acces to interp list maybe ?
ok its stupid
currently iocontrol only gets messages from task
there is no reverse communication
only status report
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
heh, I found a feature bug :)
BigJohnT, for some reason, that reminds me of the movie "Raising Arizona"
"Well son, which is it?" :)
SWPadnos: he doesn't want to share
the feature bug
we still don't know what it is
'cause you're not telling :)
it is the one where I put in a bug report and cradek had made it so as a feature :)
heh, well OK then :)
but I just knew it was a bug :)
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 :/