Z Axis Not Fully Retracting Before Moving

This repeatedly happened to me tonight:

Note the error on the right hand side. I drilled the hole first and then attempted to cut the profile. For some reason when retracting the z-axis the machine would skip some of the total movement and start working its way over to the next position. The depth of the z-axis at this point would be less than the required depth for the next cut, so it wasn’t even taking a complete shortcut.

The relevant g-code is:
G1 Z-0.75 F35
X-0.6872 Y-0.0042
Z0.2 F30

G0 X-0.1116 Y0
G1 Z0.2 F35
Y0.1039 F15
G3 X-0.1138 Y0.1314 I-0.175

On my final test, I cut a nearly identical piece with the following code and it didn’t happen:
G1 Z-0.75 F45
X-0.6872 Y-0.0042
Z0.2 F60

G0 X-0.1616 Y0
G1 Z0.2 F20
G3 X-0.1631 Y0.1235 I-0.125

I am rather stumped. It doesn’t look like anything in the g-code did it, which makes me think it is an intermittent issue. I realize that the M9 code is probably not supported, but I thought I saw a note in Ground Control ignoring it.

The only other relevant information is that this issue is occuring at the juncture of two different “operations” in Fusion360.

looking at the code, it looks like the coordinated move does not take into
account the Z axis, so if you are doing something where the Z axis takes longer
to move than the x/y axis, it doesn’t wait for the Z to stop moving before going
to the next step.

If you have a movement that’s only z axis, it will wait, but if there is any x/y
movement it won’t.


Great description of the issue @dlang.

Would one of you guys be willing to make a firmware issue for it?

Attaching a few lines if Gcode that consistently don’t work would make my life really easy :smile:

I created #266, I did my best to describe what I think @dlang is saying. I only have a surface level understanding of g-code.

1 Like

@krkeegan, there’s a link to a good gcode programming description here (I linked to the page that links to the programming just in case you want to consume way too much time looking at another machine controller). LinuxCNC contains a lot of stuff that’s not in the Maslow firmware (like variable substitution and subroutines) but the basic moves are the same. 3D printing gcode references might be helpful, but they take a number of liberties with the standard. This is the real thing ™. There’s good Mach3/4 references too, but despite knowing the original developer (through his Gearotic gear and other goodies software and forum) I’ve never used Mach. Mach and LinuxCNC (formerly EMC) both started with the NIST enhanced Machine Tool Controller, which is what made hobbyist CNC possible. G code is a direct decendent of the Gerber format used for PCB manufacturing, coincidentally I worked on a shop floor system written in Pick back in the early 90s at a PCB house and was offered a clapped out Excellon drill/router if I’d haul it off. Turned it down, no way to move the several ton chunk of granite inside it, nowhere to put or power it, plus it didn’t work. Likely a big mistake.

Sorry for the length. Old moose are prone to history and too much explanation (some of it correct) hoping all you young whipper snappers will learn something from our mistakes :slight_smile:

If you really want to dig into the actual specifications search for RS-274X. There’s also efforts to replace gcode with another language/format, but none of them have really caught on.


Thank you, I actually stumbled on that link


Previously, I agree it is a good resource.

EDIT (2017-07-25): On closer inspection, I think this was caused by an error in the interpretation of the G3 code and has nothing to do with the z-axis.

I continue to have issues with this, here is a cut from tonight:

As you can see there are a bunch of shallow cuts connecting the various z plunges.

But I think it also produced the frightening cut on the left. That is a full depth cut (.75 inches) from about the 10:30 position to the 8:30 position. It took about 6-7 seconds to do that before I was able to stop the machine.

The relevant g-code is:

  1. G0 X9.175 Y-0.05
  2. G1 Z-0.75
  3. G1 Y0
  4. G17 G3 X6.6621 Y6.3085 I-9.175
  5. G1 Z-0.6875
  6. G3 X6.3085 Y6.6621 I-6.6621 J-6.3085
  7. G1 Z-0.75
  8. G3 X-6.3085 I-6.3085 J-6.6621
  9. G1 Z-0.6875
  10. G3 X-6.6621 Y6.3085 I6.3085 J-6.6621
  11. G1 Z-0.75
  12. G3 Y-6.3085 I6.6621 J-6.3085
  13. G1 Z-0.6875
  14. G3 X-6.3085 Y-6.6621 I6.6621 J6.3085
  15. G1 Z-0.75
  16. G3 X6.3085 I6.3085 J6.6621
  17. G1 Z-0.6875
  18. G3 X6.6621 Y-6.3085 I-6.3085 J6.6621
  19. G1 Z-0.75
  20. G3 X9.175 Y0 I-6.6621 J6.3085
  21. G1 Y0.025
  22. G19 G3 Y0.05 Z-0.725 K0.025
  23. G1 Z0.2
  24. G17

It seemed to skip line 12 entirely. If there is a log of anything I would be happy to produce it. When this happened the location indicator in g-code showed one of the indicators quickly following the correct line while the other indicator followed the line you see on the wood.

Also, I am sure other have found this, but this is an online gcode simulator that helps visualize your gcode:


1 Like

OK, I submitted a pull request that solves the initial problem of the zaxis not fully retracting.

Last night’s deep cut is still a bit of a mystery.


Thanks for the link to the G-Code Visualizer. I added it to the Wiki and created a page for G Code and MaslowCNC to document the MaslowCNC instruction set and collect useful G Code related information.


Alright, I edited post #7 above, I believe this is unrelated to the z-axis issues.

I am still having major issues with the zaxis.

Below is a video I took demonstrating the issue. This is completely repeatable, the error start around the same proximity every time.

  1. Upload Firmware (I assume this resets something)
  2. Run the this gcode Sled abreviated.nc (3.1 KB)
  3. Somewhere around line 88 the problem will become apparent

Here is a video of the issue:


On the right is a prior sled I tried to cut. The current sled lacks the router to make it easier to hear.

Notice how at the start all axes sound nice and smooth.

Around 6:50 it gets really bad. All of the axes are firing sporadically and insufficiently. Because of the sluggishness, the z-axis can no longer keep up at this point. You can see the cuts that would occur on the right hand side because of this.

It seems like this is some sort of buffer or container of some sort that is filling up. Maybe there are too many data points for the PID function to calculate in the limited amount of time?

This problem seems to happen when I am heavily using the zaxis. I believe if I were to move the sled around in only the x-y direction a lot, the error goes away.

You can also see, that even after the stop the home command still runs very sluggishly.

1 Like

Thanks fo giving me a great starting place with the file that causes the issue repeatedly. I’m going to try to replicate this right now.

Two questions:

Which firmware/ground control versions are you using?

Which motor controller shield version are you using?

I am on the most current version of master for both. Basically .81 plus a few things.

As for shield version. I was not a beta tester, I hope that is enough. Otherwise I will have to look tonight.

1 Like

That’s everything I need to know. Thank you!

I’m seeing the same behavior you are and I’m looking into what is causing it right now

The firmware is running near the limit of available ram. Are any of those things in the firmware? I’ve caused myself issues adding print statements to ‘look around’ in the firmware while it’s running. Now I limit the test changes I make to try to avoid grief.

No, I don’t have anything custom. I just meant that master has only slight improvements over .81.

1 Like

I think this issue has to do with memory fragmentation on the heap. That’s why we’re seeing it get worse as the file runs

That far exceeds my skill set in programming, so hopefully you have a good idea on possible solutions.

In other words a memory leak?