I freely admit that I fell into that classic IT trap, which is that there is often a disconnect between what the software writer thought the world looks like, and what the user expects. Sometimes these are the same thing, and all goes beautifully. In this case, though, my interpretation of G20/21 from both Mach3 and LinuxCNC documentation led me to expect different behaviour from what Mach3 actually does.

My interpretation - G20/21 say "all the coordinates in the rest of this gcode file are in in/mm units and interpret them that way." Doesn't sound difficult to me - in simple terms, anything following one of XYZABCIJK gets divided by/multiplied by (depending on native units and what's being read) 25.4. Then carry on using those values, but leave the GUI unchanged. I was expecting Mach3 to continue to display in mm, while reading incoming data in inches and converting it.

What I actually saw was Mach3 reading a G20 command, saying "This user now wants me to completely move away from my previously-defined mm state and work and display in inches" - so it changes the DRO coordinates, feed rates, etc. What it does not appear to do is convert the work offsets (G54 table, etc) from mm to in, which would have maintained the work coordinate zero, which seems to me like an inconsistency but I expect that there is a reason for it. This was not the behaviour that I expected. I'm not saying that it's wrong, just not what I would have expected. However, this is also why setting the work coordinate origin after loading gcode will work.

In my case, the simple solution is to make sure I tick the right box in F360 or Vectric Vcarve, my gcode generators of choice, and only ever produce mm unit gcode as this is infinitely easier than having to manage two profiles (and keeping macros in step, etc), maybe having to reload profiles as I move between different gcode files.

Gerry - I note that you have answered this question elsewhere years ago, but as I mentioned, until I realised why this was happening, I couldn't google successfully for the answer! It took me a little time to note that the gcode was in inches not mm, as I hadn't even considered that this might have been the problem.

Nick - not really a work offset issue, I think (except as noted above) as exactly the same model produces correct gcode with all the same setup and CAM parameters with only the mm box ticked instead of in. I'm fairly happy with the G54, etc, set of values as I have hand-edited these before when combining multiple gcode files to machine a batch of objects, all of which had the same (0,0) origin when their gcode was created. By using multiple work coord offsets set manually to suit my machining jig and adding a judicious G54, G55, etc, in the gcode, it all worked fine.

Thanks for the comments, guys.