On 9 November 2012 03:46, Chris Morley <[email protected]> wrote:
> I don't understand the need for the geometry offsets to have 10,00 added to > them. > I realize this is how Fanuc has it's tool table but there is no good reason > (I can see) to follow that. > It doesn't affect whether the Gcode runs or not. I can imagine that a format like T10.12 would work (tool 10, offset 12). The big difference between Fanuc-style and LinuxCNC style tool changes is not actually in the offsets anyway. That is that the T-word causes the toolchange, not the M6 command. I am wondering if this can be accommodated in the current code-base just by altering the tool change feedback behaviour. As far as I recall the T-word changes the tool-prepare pin and puts the tool/pocket numbers on prep-number and prep-pocket. There is no reason that a lathe tool changer can't immediately act on this data, not waiting for the tool-change pin. However, The T-word does not prompt a recalculation of offsets, which requires a toolchange event in the motion queue. (which is one of the things M6 does, I think). When I started this message I was going to suggest that toggling the tool-changed pin from toolchanger code (regardless of tool-change-request status) could be used to prompt a recalculation, but I have since realised that that can't work, as the whole motion queue will be written "through" the T-word, so toggling tool-change would need to abort the queue and recalculate. and that's worse. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
