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
On 3/17/2014 8:25 AM, Sebastian Kuzminsky wrote:
> This commit was applied to both 2.5 and master, was that intentional?
>
> The usual way to do things like this would be to commit the patch to the
> oldest applicable branch (2.5 in this case), then merge that branch into
> master.
>
> Just FYI for next time ;-)
>
>
>
> On 3/16/14 16:58 , Dewey Garrett wrote:
>> loadtool.ngc uncondtionally apply G43
>>
>> thanks to user pi.r for the report
>>
>>
>> http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0334c74
>>
>> ---
>> nc_files/ngcgui_lib/utilitysubs/loadtool.ngc | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/nc_files/ngcgui_lib/utilitysubs/loadtool.ngc
>> b/nc_files/ngcgui_lib/utilitysubs/loadtool.ngc
>> index e4dca9a..c399573 100644
>> --- a/nc_files/ngcgui_lib/utilitysubs/loadtool.ngc
>> +++ b/nc_files/ngcgui_lib/utilitysubs/loadtool.ngc
>> @@ -12,8 +12,6 @@ o<l0> if [#<toolno> EQ 0]
>> m2 (quit)
>> o<l0> endif
>>
>> -o<l1> if [#5400 NE #<toolno>]
>> - T#<toolno> M6 G43
>> -o<l1> endif
>> + T#<toolno> M6 G43
>>
>> o<loadtool> endsub
>>
>> ------------------------------------------------------------------------------
>> 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-commit mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/emc-commit
>>
>
------------------------------------------------------------------------------
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
