Hi On Dienstag, 7. April 2020, 18:07:09 CEST andy pugh wrote: > But, very often, the tool change process is handled by HAL components > and G-code remaps, and in that case it is useful for LinuxCNC to help > out ...
Sure! I thought about implementation of a "complicated" atc, like a chaotic storage system. From my point of view, you have 3 motion axis: locate the gripper to a slot (or a slot to the gripper), move tool from atc and spindle out, turn around and move the tools in in changed order. Only the location of the slot relative to the gripper needs to be a dynamic motion of different length. All other atc-motions may be triggered by (virtual) relais, as the length of the motion is always fixed. Yes, it would be fine for the atc, to use motion from linuxcnc, but then you have to use "virtual axis" and another queue between motion and atc (atc- motions don't need the help of task manager). > with remembering where each tool is, as neither HAL nor G-code are > well suited to persistent data storage. I think, the job of persitent data storage should not be responsability of Hal, but either linuxcnc or atc-module. Motion already has a nml-queue, so why not use hal-pins to turn of task- manager, send nml-commands from atc to motion during tool change and then turn task-manager on again after tool change? Reinhard _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
