dro and gcode don't match

[spinningwood]

While trying to fix another issue I happend to notice that the dro doesn't match the gcode when I stop the program during a run.  They are all off by a small amount.  A search of the web only turned up a suggestion to check backlash settings.  I have backlash compensation turned off so I don't think that's my problem.

I did some air runs of old jobs and now see that those files had dro / gcode mismatch as well.  The pieces cut fine, but I cut artwork not jet engine components and I don't measure the finished project. 

Is this normal behavior for Mach?  Is a setting(s) I should be checking?

Thanks.

Ed

[alenz]

Ed,
It may be due to the resolution of your system. For instance my controller is ½ step and with 4tpi lead screws each step is 0.000625 inch. So if the G-code is in 4 or 5 decimal places it is unlikely that Mach can drive to that exact position. Mach will drive to and display the step that is the nearest to the commanded G-code. For example if I step in 0.001 increments the DRO will show steps such as .0000, .0006, .0019, .0025, .0037, .0050…. etc.  As you suspect it’s quite likely normal and not a poblem.
Al

[spinningwood]

Hi Al - Thanks.  That sounds like a reasonable explanation.  I'm going to single step through a job when I get a chance and see if that's what looks like is going on.


Ed

[spinningwood]

Looks like you were right on with your answer Al.  I learned something new as well by single stepping through a job.  When you stop a job the gcode stops at the next line to be executed, not the last line that executed.  Everyone else probably already knew that, but I didn't. 

When I compared the DROs to the line before where it stops, the gcode and DRO are either right on or off by a tiny amount.  Exactly like you would expect based on resolution limits.

So much to learn with Mach!  Good thing I enjoy learning new things.  Mach keeps me really happy in that respect.

Thanks again for the help.

Ed

[alenz]