That's an interesting point, and a great reason to not require that a tool have exactly one offset. I think there may be a solution that addresses all of these concerns:
1. A tool with no offset doesn't make sense 2. A single physical tool (saw top / bottom, face mill inserts) can have more than one offset 3. Manually switching tool offsets with G43 Hxxx is a workaround for (2), but then the relationship between the various offsets isn't obvious in the tool table. Apologies if this had already been thought of, but I think we can solve this by requiring a tool offset to always be applied, but allowing "virtual" tools, so that more than one tool number can point to the same physical tool. This way you don't need to apply arbitrary tool offsets, and can avoid the risk of crashes due to mismatched offsets. To keep it simple, we could assume that virtual tool number = physical tool number by default, so tools with just one tip (e.g. end mills, drills) would not need any extra work to set up. Furthermore, you could eliminate the M6 (since "changing" a tool doesn't necessarily imply a physical tool change). For the slitting saw example, your code would look like this (T11 = saw bottom, T12 = saw top). ... cutting ... T11 (physically load saw into spindle and apply offset 11, equivalent to M6 T11 G43 today) ....cutting... T12 (no tool change, tool in spindle, apply offset 12, equivalent to G43 H12) ... cutting ... This is a lot like how Fanuc does lathe tool changes, where the T word triggers a tool change and applies the corresponding offset(s). If the T word was remappable, then system integrators could create whatever custom tool change routine required, as long as it fulfilled the contract. Obviously this would be a breaking change, but we could make legacy behavior vs "new" tool change controllable based on a feature flag. -Rob On Fri, Apr 10, 2020, 6:06 PM andy pugh <[email protected]> wrote: > 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 > _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
