Maslow Home Maslow Community Garden Newsletter

Ground Control not using correct Z height


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.


This could be happening because the motor is having a hard time moving the z-axis. Does it seem like everything is moving freely?

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:

  1. 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.
  2. 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.
  3. 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?

That sounds like an issue to me. I haven’t seen that before. Are you running the code on an arduino Mega?

Yes, using a Mega.

1 Like

@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(): 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.

Don’t have Maslow here so can’t test.

Hmmmm interesting. Axis read does seem to return the true position at that time and not the desired end position:

float  Axis::read(){
    //returns the true axis position

Do you see how that would be causing the error above?

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 :slight_smile: into this convo.

1 Like

I created an issue on github for what I think might be the cause.

1 Like

Can you post the gcode? I don’t think the issue I found is causing this but need the gcode to test it.

I’m sorry for the spamming of messages. Is this accuracy issue only near the 0.8 inch depth point or did you see it on earlier passes?

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

David Lang

Created a pull request which fixes this.

1 Like