Loosing Steps on X Axis - Stuttering in X- Direction but smooth on X+

I watched the video of you moving the machine by hand with the power off. That is a normal sound. Stepper motors by there very design make noise when you rotate them by hand. With the belting hooked up you can rotate them much faster and that is the sound you will get from them. All OK there.

edit. Just watched video 3 Keep a close eye on the top left V wheel as the carrage moves back and forth. You will see that wheel stop turning and slide on the rail for a short distance. You may want to check your V wheels again looks like there may be some miss adjustment there.

@DavidSohlstrom Hi David,

you are right, i checked the original video too and it seems like that top left wheel gets stuck for a second before it keeps moving. I will check later if i can reproduce it. The more interesting questions will be what causes it to get stuck there…


Hi Larry,

here is the output:

**** Connected to COM6 @ 115200 baud ****

Grbl 0.9j [’$’ for help]
[’$H’|’$X’ to unlock]

$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=40.000 (x, step/mm)
$101=40.000 (y, step/mm)
$102=188.976 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=790.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=100.000 (z max travel, mm)

I also tried the job again, and its off still.

This time, even more than usual and its off already after about 4 minutes minutes:

0 before the carving:

After return to 0 after the carving:

It now seems to carve it sideways but still parallel:

Thanks, Oliver.

Sometimes the $1 parameter is not set right, which can cause positioning errors. Your parameters look good.

I’m still trying to figure out what I’m hearing when you move the X axis by hand. The Y axis sounds right, but the X axis doesn’t.

Can you get me a video with more of the X axis movement by hand and do it rail to rail. The current video only has a short amount of movement along X and I just can’t isolate what I’m hearing. The speed that you were moving it was fine.

How do you return to zero after the carve?

I read through your post again to see if I could get a better idea of what’s happening. You said that you had the current limit potentiometer at about 70 percent. That may be too high.

Since you said no to the voltmeter, try setting your X axis potentiometer like this one.

@LarryM I set the pots like in the picture, but same issue :frowning:
After the carving i return to the zero position using the ‘return to zero’ button in UGCS.
I also made a new video with the X axis. Since its hard to get to i was not able to move it as smoothly as i would have liked to, but hopefully its enough to see and hear.
It seems to me though that it only gets offset if its actually cutting since i tried moving it back and forth via the jogging function also to the extremes in all directions and it always came back to 0 fine.

Once i start cutting though, it is offset after 2 minutes already (or maybe even sooner, hard to tell).

I tested jogging too with the dewalt running, and even then it makes it back to 0 fine.

EDIT: I tested another job that does a raster carving like the other job but this one was doing the raster carving on the Y axis instead of the X axis, and even 20 minutes, it was still aligned fine and returned to 0 0 0 without issues.

I wonder if somebody here is willing to test the job that i am trying. it requires a 1/8 ball mill, and its set for x=16 y=28 inch z=1 inch hardwood. It doesn’t go deep every pass and also not the whole 16 inch wide (i think only 10 or so on X) but the 0 0 0 needs to be set on top of stock in the bottom left corner.

The file can be found here Download ZIP. I ran it with UGCS 2.0 and it runs fine.

EDIT2: Here is a slow motion video of cutting the file above. One weird thing is that in the first 10 seconds it cuts on x+, the all of a sudden goes x-, the x+ again. it does that only in the first move. When i run the file through a simulator like OpenSCAM or so, it doesnt show those moves. So maybe UGCS is causing the issue?
Slow Mo Video

Thanks for the new video. What I hear in this video is that the movement along the X axis is not smooth like it is on the Y axis. It seems like there are several places along the X axis where the carriage seems to drag. Instead of giving off a continuous tone as the Y axis does the X axis has a modulated sound to it.

[Edit] - I just re-read your message and didn’t notice that you had said that you couldn’t move it as smoothly, so that might have been what I was hearing.

The “Return to Zero” button in UGS is a different issue. It doesn’t work like most people think.

“Return to Zero” in UGS uses the G28 command which works with Machine co-ordinates. When you press this button the machine will move to Work Space 0,0 and then move to the G28 position.

Copied from one of my other answers:

If you HOME your machine and jog the spindle to X5 Y5 Z-5 then press the “Reset Zero” button your Work Zero is now located at Machine 5,5,-5.

If you HOME your machine after doing this then the Work Position will be -5,-5,5 because you set your Work Zero at 5,5,-5.

Be careful if you try to use the “Return to Zero” button because it doesn’t act like you would expect. The “Return to Zero” button uses the G28 command which works with Machine Position and that location must be set with a G28.1 command.

If you have not set the G28.1 position then it could be pointing anywhere. Once set it doesn’t change unless you enter another G28.1 command.

To set your G28 position:

  1. Home your machine
  2. Jog your machine to the location that you want to be the G28 position
  3. Enter the command G28.1

After you have done this pressing the “Return to Zero” button will take you to the Work Zero Position and then move to the G28 position.

Hope this is clear. If not I’ll try again.

Which version of UGS are you using?

I took a quick look at the new video and your G code file. There is a problem here, but I haven’t had enough time to look it over to try and determine where the failure is. Maybe I can look at it some more later this afternoon. (Edit : 9/24/2015 11:40).

1 Like


Hi Larry!

Yeah the X axis was hard to move since it was hard to reach over the whole distance over the the carriage to pull it towards me. It runs as smooth as the Y axis otherwise.

I am using 2.0.9 for UGS (definetely 2.x).

Thanks again Larry and looking forward to hear about if you find anything wrong with the gcode file.

Oliver, looking at the video I see two instances where the router backs up (moves -X) as you mentioned. This movement is not in the G code file.

I can think of two scenarios where this could happen:

  1. the communication link is dropping characters, and/or
  2. UGS is screwing up.

The last release of UGS that is a stable release is 1.0.8, so you are running an alpha/beta version of the program. You said at one point in this thread that UGS 2.0 runs it fine.

If that is the case, go back to UGS 2.0 and if it runs well then stay with it.

There have been reports of UGS failing with large files. This file is almost a million lines long. That may be a problem.

I tried to run your file as a simulation in UGS 1.0.8 and UGS hung.

Thanks Larry!

I will try to run it with 1.0.8 again to see if that makes a difference.
Maybe i also get to change the laptop that it is connected to so i can also rule out that PC.

Thanks again for looking into that, i really appreciate it!


I also tried to run the code in a simulation program I have and it froze the program. I think Larry M is right this code is just to big for the software you are running.



I would agree regarding the size, however i have the same issue with smaller files as well, such as this one:

This one runs all the paths fine, except for the second pass of the round cutout in the middle of the object. Pass 1 is fine, once it goes down in pass 2, its off again these exact 5mm as always.

Boy, this one is really tough. What program did you use to generate the G code?


I used carve with their X carve export plugin from inventables using the project from the vcarve project site.


OK I DLed that file and it ran on my simulation program. It is 90K+ lines of code and it is all done in very short straight lines. The whole carve is made up of all curves there is not a straight line in the project.
Here is a screen shot of the finished carve. Carve time is 1 hr 40 min. I can see no problems with the code Green is G1 moves and Red is G0 rapid moves. There are 2 G0 moves to the middle of the center part of the carve 1 for the first layer and again for the 2 layer. There are also G0 moves after the 2nd layer but you are not getting to that point before the problem crops up.

I have an idea that that 2nd G0 move to the center is where the problem is cropping up.

The G0 move that I think is the problem is at line number 46669


Which simulation program did you use?

I downloaded the clock files from Vetric.

Got to get some sleep. I’ll check them out tomorrow.

I use Gwizard Editor. http://www.cnccookbook.com/CCGWizardE.html?utm_expid=2217679-99.UHSQuwm0Qv6aRbRE9NQ16w.0&utm_referrer=https%3A%2F%2Fwww.google.com%2F

It is a very handy tool for making sure your code is doing what you expect it to do.

It is to bad that Vcarve does not deal with curves like other CAM programs do. It breaks curves up into thousands of little short straight lines. This is hard on a machine.



In case the file you are using has problems I regenerated some of the files to see if that would make a difference. If you have the bits this was designed for then you might give it a try to see if this does any better.

Start with .txt and .bmp files.
DevineBack11x19.zip (408.7 KB)

Thanks, David.

I think I read somewhere that grbl might not handle arcs as well as one would like. Maybe that’s why they use line segments.