Quoted verbatim as Dave got a bounce, so it might not have made it to the list as a whole:
On Fri, 10 Apr 2020 at 22:46, David Bagby <[email protected]> wrote: > > > On 4/10/2020 4:25 AM, andy pugh wrote: > > > <snip> > > > It is already an INI file option. I am just proposing to make it default to > > on. > > > > There is already an annoying inconsistency in behaviour with this. > > Tool touch-off in Axis (for example jog to the top of the work, tool > > touch-off and set z to zero, then the DRO will show Z -0) If you do > > the same think in Touchy (after setting the "workpiece" option in > > preferences then you need to manually issue the G43 yourself to see > > the DRO read 0 for Z. > > > > Nearly every lathe already defaults to automatically applying the tool > > offset. I think that LinuxCNC is unusual in requiring G43 for lathe > > tool changes. > > > > Has anyone here ever deliberately coded a tool change without a G43? > > If so, what was the reason? > > I've mostly lurked here for many years, but seldom post. Congrats, > between being stuck at home, and the topic under discussion, I felt the > need to stop lurking for a moment or two '-) > > I'd like to express some concerns over the idea of turning on "auto G43 > by default". > > My views are mill centric as that's what I have experience with, I've > less experience with CNC lathes, so I'm not sure any opinion I have re > lathes is worth much. > > While it is true (in my experience) that many gcode programs are written > to use G43 TLO values, "many" is not the same as "100% of existing gcode > programs". > > 1) I am concerned that changing the default state of G43 after an M6 > would be a significant, incompatible change to the semantics of the > state machine which is a gcode program. > > Today, An M6 changes a tool, it does not alter a TLO value. Having the > TLO value magically change to "match" the newly mounted tool, is a huge > change to the default state of a gcode program. Doing this would be > introducing a non-backward compatible change wrt to existing gcode > programs. I consider that a strong reason NOT to make the default state > for g43 after a tool change become "on" which = "a magically found TLO > value is set and applied". > > 2) Note that I said "match" in quotes in the preceding paragraph. I can > see how one might think that this change would have no impact, but just > be a convenience - but I disagree. That approach seems (at least to me) > to assume that there is always a 1:1 (or at least an implicitly known) > mapping between tool # being mounted and the tool's TLO value. I submit > that this is not always a valid assumption. > > (BTW, one of the reasons I've liked the extended tool table proposals of > the last few years is that would be more general and would not require > this type of implicit relationship. ) > > An example which comes to mind is a slitting saw being used in a > vertical mill. There is one physical tool for this scenario, but two > different TLO values may typically be in use. One value typically > corresponds to the top edge of the saw blade, the other to the bottom > edge of the blade. This leads to programs with maybe one tool change > (to mount the tool, though even that may not be required within the > gcode program) and possibly multiple G43 invocations to apply different > TLO values. Why should one or the other (or some other value, as the > example could be generalized to n TLO values for a tool) be the one > auto-magically selected "to be THE TLO value" at M6 time? > > 3) I have one system (happens not to be a LCNC system, but I don't think > that maters for the discussion) where there is an option on every tool > change to have the system measure the physical tool length (PTL or TL) > as part of the tool change. This value is stored for later use - most > often to calculate a TLO value (based on the PTL value ) to apply. > > There is no need to apply a G43 TLO value as part of the M6 - in fact > that would be annoying (or worse). I have gcode programs which I use to > just cycle thru all the tools in the changer in order to get their PTLs > measured. I sometimes do a block of M6 to get tools measured at the > start of a program. What I've done is (re)Measure all the tools PTLs. I > have NOT applied any TLO values for any of the tools. > > Returning to the "measure all the tools PTLs example": when that gcode > section is done, with the proposed change, LCNC would now have an active > TLO value being used - which is a significant difference from what > happens today. This could be the cause of tool crashes as LCNC would > now be using a new, different, incompatible model for gcode program > state. Existing programs now break. > > It gets more complicated - TL and TLO are different values, used for > different purposes. > > a) The PTL is a constant (with a repeatable tool holder), but the > TLO value is not. A TLO value depends on what TLO scheme is used within > (assumed inside of) the gcode program... > > 3 TLO approach examples: > > 1) TLO = TL - Common if measuring TLs off line before the tools > are taken to the machine. TLO values should always be + in this approach > (I don't have an negative physical length tools in my tool crib). > > 2) TLO from touching to Z0 - this (should) result in a TLO > value which is negative - as it's the distance a tool tip has to move > from MC 0 to be at WC 0. Note that this also makes the TLO value > dependent on the WC 0 having been set (i.e. changing WC offsets in > validates TLO values in this scheme). That's another challenge, it's > not safe to assume the WC0 has been set before any M6. Example: A > program could mount a tool (via M6) which is a probe and be intending to > use the probe to find and set WC 0. > > 3) Master tool approaches (an approach I use often) - in this > approach the TLO values are relative to the PTL of a master tool. The > value could be either + or - values. > > My point is that there are many TLO schemes in use out in the wild, > making assumptions about the scheme in use, and/or the mapping of T# to > TLO value # etc., in order to change the default actions of G43 is > dangerous. As in "likely to result in tool crashes" dangerous. > > My 2 cents worth - > > The current situation where an individual user (or shop) can make the > decision to alter G43 default semantics (by turning on the INI value) is > OK. That's up to the shop owner and they can make that choice for > themselves and their existing investments in gcode. > > It's a different situation when LCNC makes such a change to expected, > default semantics. Doing so is effectively making the decision for all > existing LCNC users who ever upgrade to the new LCNC version (or > later). Since this would be an incompatible semantic change to M6 (as > it's M6 that would magically apply a G43 action which is not in the > gcode program), I consider this to be an undesirable change. > > Dave Bagby > > -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
