Hi, I tried to send the following email to the developers list, but I then received the next list digest and my email was not in it - so I think my post email never got to the list. (are posts to the list moderated? If so, who would I contact to check this out?)
In any case, while I try to figure out why my message did not get through, I thought I'd send my thoughts to you directly. Please feel free to re-post my email as appropriate. Dave -------- Original Message -------- Subject: Re: [Emc-developers] g43 after tool-table touch-off? Date: Thu, 04 Oct 2012 10:26:57 -0700 From: David Bagby <[email protected]> Reply-To: [email protected] To: [email protected] Hi all, While I've monitored this list for a couple of years, I think this is the first time that I've offered some direct input - Please excuse the delay in my input - I get the dev list emails as daily digests. Re "Shouldn't Axis issue a g43 automatically when the user touches off to the tool table?", I'd like to say that I think this is not a preferred action. This is a question that I've seen arise multiple times, - While it is *one* common usage pattern to measure a tool and then (immediately) use the newly measured value as the TLO (Tool Length Offset), these are two separate events and they should not be automatically coupled in time. The first event is measuring a tool, and that creates a new value in a tool table (as you have to save the value somewhere and that's what the tool table is for). However, it is not true that the change of a tool table entry should cause the CNC control to magically apply that value as the active TLO. Creating any TLO value and applying a specific TLO value to position calculations made by the CNC control are inherently decoupled in time. (a tool table stores values so that they can be used later in time - after they are established in the tool table). Doing a "auto G43" would cause the CNC control to arbitrarily change from the current state to a G43 Hx state... that then becomes the the source of problems. I'll offer the following food for thought: 1) automatically changing the active TLO in the way suggested causes the state of the CNC control to become inconsistent with the state that the g-code program has specified. Suppose that the control is in a G49 state (TLO inactive) - now a tool measurement will be changing the state to G43 Hx. This would create an undesirable cross coupling between two actions that are expected (under generally accepted/expected GCode semantics) to be independent. In G-code the G43 preparatory word is used to apply a specific TLO value (where the TLO value is typically specified by a H word in the same block as the G43). The Gcode language semantics are that TLO values are applied when the G43 block is executed. If I as a g-code programmer put the control in a G49 state, it should stay in the G49 modal state until the gcode explicitly changes it. Consider this pseudo gcode: G49 <measure a tool operation> .... gcode semantics say that the control state is G49 at this point.... Doing an "implicit" g43 H<tool # just measured> as part of a tool measurement process effectively causes the execution of a G43 that is not part of the loaded gcode program - thus resulting in the control being in a different state than what the gcode programmer expects. I consider that to not be a good idea. Here's another usage example that a "auto G43" would break: If you are using a master tool approach to TLO values (where each tool's TLO is relative to the physical length of a master tool), it's common to measure a whole set of tools once and store the values in the tool table as you make the measurements. It would be very awkward to have the state changing form G49 to G43 and the active TLO value changing as each tool was measured. 2) Considering the above, I'd also prefer not to see this "auto-G43" as a configuration option. While at first glance having a option may seem innocuous (maybe it's just me but) I see the creation of such an option as an "optional auto-magic g-code state conflict option" - and thus I perceive it as negative rather than neutral feature. Dave On 10/4/2012 9:03 AM, [email protected] wrote: > Message: 8 Date: Thu, 4 Oct 2012 18:03:23 +0200 From: Michael Haberler > <[email protected]> Subject: Re: [Emc-developers] g43 after > tool-table touch-off? To: EMC developers > <[email protected]> Message-ID: > <[email protected]> Content-Type: > text/plain; charset=us-ascii Am 04.10.2012 um 17:54 schrieb Sebastian > Kuzminsky: >> >Shouldn't touch-off to the tool table issue a g43, to make linuxcnc use the >> >new tool length offset? >> > >> >Let me clarify. I use Axis. When I touch off, Axis pops up a window that >> >lets me enter the new coordinate for the selected axis, and that window has >> >a pull-down that lets me select where to apply this new offset. The >> >choices in the pull-down are the various coordinate systems (g54, g55, >> >etc), or the tool table. If i touch off to the currently selected >> >coordinate system, the DRO immediately changes to reflect the new offset. >> > >> >But if I touch off to the tool table, the DRO does not change. Inspecting >> >the tool table shows the new offset is there. Switching to the MDI tab >> >(f5) and running g43 causes the DRO to update to the correct value. >> > >> >Shouldn't Axis issue a g43 automatically when the user touches off to the >> >tool table? > I made that configurable. > > seehttp://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/rs274ngc/interp_convert.cc;h=822927180a04b8cf0efa9feac112f7a4b9693d78;hb=98a947383e8a63f5eccceb29010fb20692fa9822#l3037 > > - Michael > ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
