Post-M6 - restore X,Y ?

I have a rack-based toolchanger/toolsetter at the back of my CNC router.  My custom M6 gcode saves the X,Y location at the start, and moves back there at the end (at max Z, of course).  Often the next thing that happens is a rapid to a different X,Y.  I'm wondering if there's a safe way to not restore the position after the M6, or if there's some magic to restore it only if the next move is anything other than a G0XnYn move (i.e. G1 or G0Zn)?

There is no magic as far as I know....
Is this not something you can deal with in the post-processor?
Like Ssetting a global before the M6, e.g. #<_restore_xy> = 0, and have your M6 read that flag to decide whether to restore?

Linuxcnc architecture will fight you hard on this, no real way to know the future move type after an M6, preview does it, but is fragile, it would be a waste of time implementing something like that IMO

Yeah, I didn't think there would be any magic, but I figured I'd ask. My files come from various sources so "do it in post" is not reliable enough unless EVERY post does a G0XY before any GZ.

djdelorie wrote:

or if there's some magic to restore it only if the next move is anything other than a G0XnYn move (i.e. G1 or G0Zn)?

You could consider adding the required magic with a Gcode filter that is applied when files are opened...

I could do that, but keeping track of the old Z might be tricky, especially if subroutines are involved.
I was also thinking that wrapping the "G0" and "G1" gcodes in a short python script (or even gcode wrapper) might work, but it would take more time than I waste waiting for the machine
I guess what I was originally asking was "does everyone else do it this way too?"

I don't think moving back to the original position after an M6 is standard practice, all post should have safe move inserted after a tool change, this is not something dealt with on the machine side IMO
If your post expects the tool change to happen and the machine to not have moved and does not give you a way to implement safety moves to re-approach the work-piece after a tool change, this is just bad design of the CAM/Post the fix should be there IMO

Two thoughts: first, what does the default "tool change at specified location" do ?  If it's been not returning all along for everyone, I suppose I could do the same
Second, I suppose I could have my tool change logic create a "no-go" zone under the spindle at the end of the change (using M68) and have some hal logic trigger a stop if the spindle enters that zone before it moves XY away from its existing position...
 

The built-in LinuxCNC tool change (TOOL_CHANGE_AT_G30, TOOL_CHANGE_POSITION, manual pause) does not restore X,Y. The machine stays at the tool change position and the program commands the next move.

The reason other users don't hit this problem is that they fix it where it belongs, in the CAM post or with a pre-run G-code filter that normalizes tool change behavior. Building the safety net into the M6 macro is the non-standard part, and the complexity you are hitting now is the natural consequence of that. The look-ahead problem, the M68 idea, the HAL logic, these are all workarounds layered on top of the first workaround. The root issue is inconsistent G-code from your various sources, and that is where the fix belongs.

If that is not practical, rodw's filter is the cleanest option: scan forward from each M6 at file load, and only insert a reposition if you see a Z-only move before any XY move.

Your no-go zone idea is actually conceptually sound, the mechanism was just wrong. You can do this properly in HAL with mux2 and soft limits.

Add a second set of limits to your INI next to the existing ones, something like MAX_LIMIT_WORK and MIN_LIMIT_WORK, set them to exclude the tool change zone. MAX_LIMIT and MIN_LIMIT stay as the full machine envelope.

In HAL, setp the two mux2 inputs using the [JOINT_N]MAX_LIMIT and [JOINT_N]MAX_LIMIT_WORK bracket syntax, and net the mux2 output to ini.N.max_limit which drives the actual soft limit. The select input is program-is-running AND NOT motion.tool-change. Repeat for min limits and each axis that needs it.

When the select is true the mux feeds the WORK limits, cutting off the tool change zone. When false, for any reason including faults or mid-tool-change stops, the full limits are active and you get normal travel back automatically. No special recovery needed.

I like that idea better. I might write a custom HAL component to do the logic though, as my "no-go" zone is a bit too complicated for discrete HAL components to be "easier" (my valid work area is not a rectangle), and I might think about adding pins for "allow access" that I can set/clear in my M6 handler.
My paranoia here is that, when M6 finishes, the spindle is usually positioned over something expensive. A rapid on Z at that point would make expensive sounds.