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