On Monday 17 March 2014 17:23:05 David Bagby did opine: > Hi, > Seb's email happened to draw my attention to this patch. > IMHO, the loadtool code already had a bug in it, and this patch will > make the bug happen 100% of the time that loadtool is used. > > I understand that T#==H# is a common gcode convention. The key word here > is "convention"... > I am concerned that when the control system promotes one particular > convention into an embedded, defined behavior, programs that use a > different convention stop working as expected. > > I'm sensitive to this topic as I've dealt a lot with another PC based > control system that made the mistake of "helping" in this way and it has > caused me a significant amount of customer support time over the last 5 > years. > I'm hoping that LCNC will not make the same mistakes based on "good > intentions but bad assumptions". > > Background: > It s often useful to have multiple Tool length offsets that get applied > to a single physical tool when needed. > Simple example: A slitting saw - one tool (the saw), with an offset for > one edge of the blade and another offset for the other edge of the > blade. IMHO any code **within LCNC** that assumes (or enforces) T# == > H# is a bad idea. > > 1) Invalid assumptions: > While it is a common **convention** in simple gcode to assume that the > tool length offset index is the same as the tool number, it is only a > convention; one that is not always valid. > As a convention, the scope of the convention is limited to being within > a specific gcode program. > A LCNC utility routine should not be promoting such a convention into a > universal expected CNC control behavior. > Doing so is technically incorrect and creates down stream technical > problems (see below). > > Assumption a) T#==H# > The T#==H# relationship is not required by any language definition of > gcode that I am aware of (including LCNC's variant of gcode). > > Assumption b) G43 is the "only" way to set TLO compensation. > There is more than one way to set a tool length offset. While I've > seldom seen it used, there is G44 in addition to G43.... > (Which I admit I've not tried to use with LCNC, does LCNC support G44?) > > 2) T#==H# Convention promotion creates gcode program state violation: > Loadtool (pre patch) was conditionally turning on TLO compensation when > (IMHO) it should not. Alas, doing it all the time makes things worse > rather than better. > > Mounting of a tool, and the application of TLO compensation are two > different and **independent** states in gcode. > It's perfectly valid to move a spindle around after a tool change and > before TLO comp (G43) is activated. > The real problem is that if one writes a program to gcode spec, then the > program does NOT expect G43 to be set as a side effect of a tool change > (M6). > > When loadtool emits a G43 all the time (which is what the patch does), > then it makes the system set a gcode state that was not called for in > the gcode program itself. Effectively loadtool is redefining gcode > semantics and I think that is a bad thing to be doing. > > The gocde state of a program should be controlled by the program > (according to the control language the program is written in: in this > case, gcode). > Other parts of the CNC control package should not "help" behind the back > of the gcode program. This "helping" is technically incorrect: it puts > the CNC control into a state that is inconsistent with what the gcode > program called for and expects. > > Consider this simple gcode program outline: > G54 G49 (a simple init state line) > T5 M6 (get tool 5 mounted) > (at this point the gocde expects T5 is mounted and G49 is the current > TLO compensation state) > ... > ...code moves tool around in Work coordinates... > > G43 H123 (program apples the TLO that the program wants, which is not > the value in H5!). > > > Now then, if instead of the straight M6, the tool change was done via > loadtool, the state after the tool change will not be G49, it will be > G43 with an assumed (and unknown to the program) TLO value applied..... > In fact neither the operator not the program may have set a value into > H5 ( as the program was not intending to use H register 5 for the TLO > value) - > ... that section of code that moves the spindle around is likely to > create an unpleasant tool crash. > > > 3) G43 without H word > I note that the current loadtool has: > if [#5400 NE #<toolno>] > T#<toolno> M6 G43 > o<l1> endif > > I note that this is emitting a G43 without an H word. That too, is an > indication that something additional is (possibly) wrong. > A G43 without a H word should (IMHO) be a syntax error - as it is > ambiguous as to what TLO offset should be applied. > I realize that there is a "default" at work here; "if H word is omitted, > use H# == current tool number". > Frankly, I think that is also a bug (for the reasons sited above), but > I'll leave that as a separate topic - one which (IMHO) should be fixed > in the gcode interpreter. > Note I do see a difference here: This is a case where the gcode program > explicitly emitted a G43 without an H word. I can (soft of) understand > an argument that says "when a gcode program explicitly does that, rather > than create a syntax error, we default this way". This is defining what > happens when the H word argument is omitted. OK, it's not what I would > personally prefer, but I understand the argument. > > Notice that this is NOT the same as "automatically doing a G43 without H > word whenever the gocde emits a M6 - which is what loadtool is doing. > > > My conclusion: > While I can see how this T3==H# convention can come to be "expected" by > naive users that may not have learned the finer aspects of gcode > semantics, I do not think we should let this convention promote itself > at the cost of creating incorrect technical behavior within the LCNC > control system. > > If someone always wants a G43 after an M6, then that can be put in the > gcode (either by hand or via CAM post processor). > But the T3==H# convention does NOT belong embedded in LCNC itself as it > is in conflict with defined gcode semantics. > > I think that the promotion of a gcode programming convention (t# == H3) > to an embedded LCNC behavior when loading a tool is in conflict with the > definition of gcode that LCNC implements. > > Therefore, I think this patch should be reverted. > > Further, a better patch would be the "opposite" - we should NOT let > loadtool emit any G43 commands. > I'd submit the patch to remove the G43 emission from loadtool. > > Before I do, I figured I'd start a discussion as I know this can be a > subtle point re gcode state and "Automatic G43". > > So, this is my opinion, are there others.... ? > > Dave [snip]
This is not anything that I have ever played with. Why? Because I do the majority of my TLO's via a probing touch, and set the corresponding G55-56- etc co-ordinate system. With the lack of a precision tool length to my morse tapered collet set, setting a tool length in the table is a total waste of time even for collared tools, so I only set the tool radii or diameter. There are quite a few ways to skin this cat in LinuxCNC, but marrying the TLO setting of G43 into the tool table value just because you did a tool change is not a universally good idea. If you want to use it, and have the tool mounting precision to make it work, then put the G43 as the next operation after loading the new tool, before lowering it to go back to work. Now, if someone wants to play with the tool table, I can see a lot of advantageous utility in making the tool pocket number into a string, like ".250in end mill", "3mm end mill" or "5/16in drill" or "Num68 drill", something along those lines. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
