New here. Just got my Maslow up and running and making my first cuts. Mostly good so far, but I’ve noticed weird Z behavior in Ground Control. The Z value that Ground Control sets is not the value that my gcode asks for.
Here’s a pic of the Ground Control output during processing.
You can see that the gcode asked for Z-0.8 but what I got was Z-0.736. With different code that also asks for Z-0.8 I’ve seen even larger discrepancies.
What am I doing wrong?
This is a metalmaslow; firmware/Ground Control version 1.26.
With the motor disconnected, I can easily turn the z-axis screw by hand, and it doesn’t look or sound like the motor is struggling.
Three more clues:
I turned on debugging and now see the “Movement loop failed to complete before interrupt” error message, but I don’t yet understand the code well enough to know exactly what that means.
If I use the manual z-axis controls, it seems to move by the correct amount. However, I do sometimes still get the “Movement loop failed” error message.
The very last thing my .nc file does is move Z to +0.25in, and that works! Earlier in the file, every movement in Z (up or down) fails to achieve the correct Z value. Is that just luck? Or is there some reason that Z movement followed immediately by XY movement causes this issue?
@bar The original G2 gcode does not have Z in it. G2 X-37.93360 Y-5.515 I43.2022 J-129.306
In Firmware GCode.cpp in G2(): Z1=zAxis.read(). Is this reading the current position of the Z-Axis, whilst it is still in motion, and not the desired end position of Z-axis as set by gcode?
Later Z2 asks for Z from G2 gcode but its not there so it defaults to Z1.
This is the key to the problem. For whatever reason, the move is not being completed before the time runs out… and therefore the z-axis never reaches the appropriate depth.
I suspect that the steps being computed in the G2 command, when z-axis moves are included, aren’t being calculated correctly so it doesn’t finish on time. I think (and I could be wrong) @blurfl added this ability to the firmware (z-axis moves during arcs)… so tagging him into this convo.
I think this isn’t that the move isn’t completed, but that the calculations that
happen each time through the loop took more than the 5ms allocated before the
next loop. If this only happens occasionally, that shouldn’t matter.
and in any case, that shouldn’t cause incorrect movement at a large scale, just
less accurate movement at the sub-mm level as the motor speeds would only be
adjusted every 10ms instead of every 5ms