I’ve noticed the same gray crud buildup as well, and have been cutting primarily MDF. I’ve got a stiff plastic bristle brush that I use to clean the wheels and can remove it from the rails with a paper towel, but it always comes back.
Ran some more checks today.
I set a new x y z 0 position, and marked the spot. Then i jogged the X and Y axis around for a minute or two, little steps (0.1) inches, long ones at 1 inch per step, and then hit the return to 0, and it always came back to the same spot.
I suspect it only shows up when im cutting, or after a long time cutting. Not sure how i can test that, i am getting frustrated with this.
The thing that throws me off is that while its cutting from the left to the right its all straight and fine, no skipped steps. But once the carriage goes from the top on the Y axis back to the bottom the Y to start the next pass, its instantly off a full 5 mm.
Any advise is welcome.
Which stepper motors do you have?
Are you comfortable working with a Volt meter in tight spots?
How do you have the wire for the router run? If it’s inside the drag chain, try taking it out and running it on the outside. It’s a stab in the dark, but maybe there’s interference from such high current draw similar to what happened with the regular 24V spindles. Also, if you used shielded wires for the steppers maybe you should try to ground them.
@LarryM I have the NEMA23 steppers, all my parts came with a fully spec’ed out 1000mm XCarve kit. Im not even comfortable running a Volt meter in large areas
@RobertA_Rieke I have the wire run as per instructions, in the drag chain. I am not sure if the Dewalt would cause the issues, i just did some more tests (i attached videos to each section):
-I did some air cuts, running the dewalt spindle on regular speed (and another one with spindle off), and positioning it on 0 0 0. Then i marked 0 again and ran the job that i ran the past days. I had it run for a few minutes, then cancelled the job and had it return to 0. It always made it back to the exact same spot.
Video1 Video2 Video3 Video 4 (The squeeking from time to time is when the Z axis moves up and down)
-I took a slow motion video from it moving from the farthest Y back to 0, and couldn’t see any steps being skipped:
-I took a video here that shows you my belt setup, and the sound it makes when i move the carriage without powering the motors:
-I also tuned the Pots according to the video that got posted here 2 days ago.
-If somebody wants to try the carving, let me know and I upload it. It’s made for a 1/8th ball mill, and the dewalt. You need to set 0 0 0 on top of stock, bottom left corner. Wood needs to be 16x28x1 inch.
It will make multiple passes, and when the second pass starts, you can see the issue already because it will be off.
I have looked at video1 over and over and over and over again.
Here is what I have noticed. It appears that the sound that is not “smooth” only occurs when the router is moved up or down on the Z axis and that sound seems normal to me. Can you set up a file to move the X axis without moving the Z and see if you still get the noise?
Also, I don’t know if it’s because I am viewing the video over the internet or not, but it seems that your X axis V wheels are not rolling all of the time. I see some spots where it doesn’t roll, or the video is dropping frames. I tried to download the video to play in from my disk, but I wasn’t able to do that.
The sound that it makes when you are moving the Y axis by hand is normal. When you move the X axis by hand I do hear something that is a little off.
Do you know how to dump out the grbl parameters (using the $$ command)?
@LarryM Thanks for checking on the videos! Yeah the squeeky sound is only when the Z axis moves up and down, so that is normal.
I think Dropbox is mangling the video a little so its stuttering a little bit and dropping frames. I sat yesterday next to the machine for a long time watching the vwheels to see if they are all turning, and they are all turning at all times. I was hoping too it would be as easy as tightening a nut or so
And i have not dumped the parameters yet, but i can do that when i get back home if i know how to do that. Is it just issuing the $$ command via the command option in UGCS?
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…
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:
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
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:
- Home your machine
- Jog your machine to the location that you want to be the G28 position
- 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).
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:
- the communication link is dropping characters, and/or
- 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.
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.