Mach3 - weird coodinate shift with inch/mm gcode change

[magicniner]

Mach3 isn't doing anything funny, it's doing what the code you feed it tells it to.
In addition to a units command G20/G21 is there a G54 through G59 in there?
Unless you have set your zero in G54 switching to G54 through G59 will lose you your zero.
It's common for people to be operating in your machine's Absolute Co-ordinates without being aware that multiple offsets are available and to be surprised when a G54 throws them a curve ball.

[Neale]

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.

[Ger21]

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.

This would probably be classified as a bug.

[magicniner]

It's not a bug, it's simply down to the operator to get it together and work in either Metric or Imperial and set the CAD, CAM, machine and controller up accordingly.

[Neale]

My feeling is that software (and anything else that is supposed to help us) should allow us to do the job the way we want, and not impose unnecessary restrictions on us that could be avoided. Yes, we can't beat the laws of physics and some other physical constraints. There is also the valid point, as I alluded to earlier, that the software designer may have a different "world view" from a user which implies a certain way of working. I'm happy, more or less, with that as long as the implementation is consistent - which it does not appear to be in this case.

Nevertheless, Mach3 is well beyond its "best before" date so no-one is going to fix it, and fortunately there are a couple of easy workarounds in this case which mean that I do not have to manage two machine profiles or unreasonably change my way of working. Ho hum - that's life.

Gerry - out of interest, do you know what UCCNC would do in this situation? Does it recognise G20/21 and just do what you might expect?

[Ger21]

UCCNC is unitless, so it will not do anything if it sees a G20 or G21. If you want to run both metric and imperial code, you need to setup separate profiles and use the appropriate one.

[magicniner]

+1
Machine profiles, one for each set of units is definitely the way forward if for some unfathomable reason switching between systems of measurements.