Ground Control not using correct Z height

Hi,

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.
z
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.

Thanks!

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

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

I think I may be experiencing this same problem with my z axis. The sled position in webcontrol reads 4.87mm when gcode is 5mm. When it raises to transverse it doesn’t meet the measurement either.

Looking at your post in GitHub and comparing it to the lines in holey 51.27 it seems like your fix didn’t make it to that version.

I’m not savy in this area, could someone take a look.

There is a difference, the problem was originally reported while running ground control, I’m running webcontrol .94

Snip-it from GitHub below.

"Originally reported in forum Ground Control not using correct Z height

I think I have found the problem but looking through change history I can’t understand what was going on. Axis::read() is reporting the current encoder position whilst it is still moving and not the last target dimension set by Axis::write() or Axis::set().

I thought that gcode is executed sequentially and waits until motors have stopped moving from previous command? It looks like the next Gcode command can start processing before this (even using fakeServo).

There is Axis::setpoint() which seems to return the last target dimension but I have no idea why its is named setpoint and it does not appear to be used anywhere.

If you change GCode.cpp line 778 from
float Z1 = zAxis.read();
to
float Z1 = zAxis.setpoint();

You will see that Z does reach target dimension. Before this change, testing with fakeServo, the Z stopped at -7.96 for me. Afterwards it stops at -8 as expected. Using physical equipment will probably make the discrepancy worse."

This is a firmware fix that needs to be incorporated into the 1.xx and 51.xx series firmware. Not sure when I’ll have time to look at it, but I’ll add it to my list for holey firmware improvements / items to verify.

1 Like

So I did find an issue?

I’m not sure yet. You are on the right track. It looks like it was addressed as a pull request, and it closed, but the proof will be what the line reads in the firmware version we are using. My quick read of the issue shows the discussion mentioned this was important and someone should test it, but there was no confirming message that anyone did in fact test it or that it was pulled in to the code base.

1 Like

Thanks for looking into it. I hope this helps correct my issues. My z has been driving me crazy.

Also found this part within GitHub (that place is a maze to me). The files seem to have more than just a few changes.

Tried to link the files changed tab…guess it didn’t work