Circles and Z axis problem

I started testing gcode files and created some test shape sin LibreCAD, then converted with DXF2Gcode. The files display OK in ground control, but they do not seem to run correctly.

  1. Z axis moves seem to be ignored
  2. Circles do not fully cut.

One of the files is here:

The resulting ‘cut’ is here:

The circle isn’t fully cut and the pencil doesn’t raise for the moves between shapes. The Z moves are in the gcode file, as far as I can see.

I’m using a spring loaded pencil instead of a router bit as it’s quieter, cleaner and uses up less wood. The holder is a spring dropped into a cut off Sharpie, which woorks pretty well for anyone else who is looking for a way to do this. (Cut off sharpies dry out quickly).

I video’d the run and it looks like some rounding or sign problems, maybe:

I’ve had a search and can’t see anything similar. I’m on 0.85, which was the latest code last time I looked.

The current is 0.90 on firmware and GroundControl. Could you try those and report back?

  • Just in case… There have been issues with single files downloaded per ‘rightclick’ from GitHub. Not sure if that is solved, so I always download the .zip from the green button.
1 Like

I’m able to replicate the same behavior on my machine and I’ve opened an issue for the behavior here:

Hopefully I can get it tracked down quickly, I’ll let you know when I do.

Ah, it’s good that you can see the problem too, if you see what I mean. At least I’m not going bonkers.


Does GroundControl have an option to give manual GCODES? For testing purposes.

In this case i would first test if the Z-axis actually moves when pressing the Z buttons in GroundControl

You put them in a macro, unless Bar changed something recently.

If not a command line would be a nice addition…


Here’s a weird new bit of info. This file won’t reload automatically if GC is closed, but if you move to a new location press “define home” then open the file it’s in the right spot.

Very strange. I’m going to keep investigating

Not sure if double posting on GitHub and here is ethical. Will do it anyway :wink:

Would need someone to confirm this finding:
In the test file the sled teleports from X 35.418 Y 55.809 to X 63.702 Y 84.094.
If I replace the double blank spaces in line 18 with a single blank space, the teleportation does not take place. So instead of (blank is symbolized as ^):
G2 X^^63.702 Y^^84.094 I^^14.142 J^^14.142
G2 X^63.702 Y^84.094 I^14.142 J^14.142
CAMotics simulates the circle cut well with double blanks.

Edit: A ‘quickfix’ that works is to open the file in FreeCad and export it as gcode (post processor none). Takes all the spaces out of xyz.


Interestingly I could replicate the file open issue and eliminate it. I edited all double blanks in the code and the error is gone for me. Looks like an evaluation, if this is valid gcode and GroundContol decides to call it invalid and open and cut it anyway.


I’m not sure that multiple spaces are allowed in g-code

Per LinuxCNC’s docs spaces are ignored everywhere except inside comments. X 1 2 3 . 4 5 6 is the same as X123.456 or X123 . 456, etc.

I’ve seen other references that says spaces are stripped out so an example line compacts to G1X123.4Y234.5Z2.3 no matter how many spaces you put in it.

RS-274X is the definitive reference, but my standardeze is pretty rusty. It says you can only use spaces inside strings, but seems to define strings as the basic command building block. Search and you shall find the standards document


GroundControl has logic to deal with unwanted single spaces but did not expect runs. I’ve opened a PR in GC with a line to replace space runs with a single space to address, leaving the logic unchanged. Testing would be appreciated :slight_smile:


Tested and found you did a great job! The PR solves the issue with the file location not stored and the teleportation of the sled. :star_struck:


Old guy here, what’s a PR?


Pull Request I would say. Guess this will be merged soon.


Thanks for the rapid test @Gero. I enjoy your new profile picture :slight_smile:

1 Like

How quick we forget, or maybe it’s just old-timers. Thanks!

1 Like

I bid 1963 and you? IT since the first HP that could be called a PC :roll_eyes:
Edit 1: Our background sounds from your posts similar and different at the same time. Spock would say: Interesting!
Sorry, getting offtopick now.

1 Like

Way OT :slight_smile: Newcomer. First Fortran class (F IV taught from old mimeographed F II sheets) in Spring 1969, 7am before high school. Never actually got to run anything since time on the promised 360/67 at Wayne State (Detroit…) never actually materialized, although I wrote the shortest (by one line) average 10 number program in the class. Actually ran my first program in the summer of '69 on Michigan Tech’s 360/44. Oldest actual machine used was (I think) an SDS 910 that somebody had scrapped and given to the MTU EE department. Learned to punch binary programs in Flexowriter tapes by hand for that one