Repeatable Drifing Mystery

Hi,

I have an issue that's very repeatable. Hopefully someone will recognize the issue.

I first found the issue when trying to carve a long detailed 3D bit of text. As time went on the Z would begin drifting either up or down and the piece would be ruined. The drift was exactly the same every time I ran the same program. If I ran a slightly different program the drifting would manifest itself differently (more or less exaggerated, or sometimes the opposite direction), but again if I re-run this new file I will get the exact same drifting results.

To troubleshoot I wrote a simple bit of G-code to move the router back and forth ~25 times, then return to the 0 position. After running back and forth it was 0.35mm off. The Mach3 DRO says I'm back at 0, but my dial indicator shows that it clearly is not. I can repete this exact same failure on all three axis.

Here's a quick video showing what I did:
https://www.dropbox.com/s/yft4xvsby7...14631.mp4?dl=0

If I double the number of back and forth cycles to 50, the drift doubled from 0.35 to 0.7mm of error.

If I change the distance traveled during the 25 cycles the results might change, but only 2 different resulting error values would arise (when holding everything constant and only varying the distance traveled). For example, in one bit of g-code I was traveling out to -1.761 and back, the error was +0.35. Then I tried traveling to -1.762 and the error was -0.03mm. I kept changing the value slightly, but the outcome was always either +0.35 or -0.03mm.

Next I tried holding the travel distance constant, but varying the max motor acceleration. This again changed the results, but I couldn't find a correlating pattern. I varied the max accel between 3 in/s/s and 30 in/s/s. Sometimes the error was large, sometimes it was small, or the opposite directiong. Again for a given configuration I could run the same test over and over again and get the same drift.

Next I tried holding travel distance and feed acceleration constant and varying feedrate. Again sometimes I would get a -.03 drift, other times I would get +0.35. There was no correlating pattern. Both high and low speeds produced one of the two errors seemingly at random. But again, if I didn't change any variables and just re-ran the exact same config multiple times, it produced the exact same error.

I'm 99% sure I do not have any mechanical issues. If I had to guess there's some sort of software rounding issue between Mach 3's commands and the number of steps a motor moves. Any ideas would be greatly appreciated.

Set-up:
Mach 3
G-code simply written by hand in txt file to go back and forth (G0, x1, x1.5, x1, x1.5....x0)
Gatton CNC machine (home build plywood rig)
Javi Box CNC controls (STB4100 with custom-programmed proprietary PROM)
DM542 Drivers
NEMA 23 motors

What steps have you taken to ensure that there are no steps being lost?I would be tempted to run the program in fresh air and measure the tool position at the end to see if it is correct.

I'm thinking it is missing steps somehow, but not sure how to verify this, or what's causing this missed steps. Do you have a recommendation on what I should measure or test out?

I'm not sure what you mean by running in fresh air. Whenever I run the program I get the same results.

Quote:

---

Originally Posted by jhorn22

I'm not sure what you mean by running in fresh air.

---

He means run the program with your z set above the work piece and run the program without actually cutting anything.

Got it. Yes, that's exactly what I have been doing. I run the code with my router turned off and just floating up above the table and I get a drifting error every time.

Does anyone have issues running mach 3 on a laptop with windows 10? Think that might be causing issues?

A curious mixture of an old piece of control software on a current operating system.The received wisdom used to be that a desktop machine was a better idea.People do seem to be running Arduino based systems using Windows 10.You could do worse than asking the question on the Mach3 section of this forum.

The graphics in the game are still good today, owing to their simplicity. Geometry dash's name comes from the fact that they're just a bunch of shapes. The music is where the game really shines. Every level has a unique song that makes you want to keep playing just to hear it again and again.

Quote:

---

Originally Posted by routalot

A curious mixture of an old piece of control software on a current operating system.The received wisdom used to be that a desktop machine was a better idea.People do seem to be running Arduino based systems using Windows 10.You could do worse than asking the question on the Mach3 section of this forum.

---

The main structural difference between Grbl and Mach 3 (and 4) is that motion planning is done in the controller for Grbl and the PC for Mach. So, if something is disrupting the PC, Mach can suffer. In Grbl, the sender just pushes G Codes to the controller so it doesn't need to be fully real time and a pretty meager PC can be used. There are people that use RasPis for the sender.

What microstep resolution do you have the drive set on? Or how many steps do you need to send into the driver to move a mm?


Sent from my iPhone using Tapatalk

Quote:

---

Originally Posted by Dean448

What microstep resolution do you have the drive set on? Or how many steps do you need to send into the driver to move a mm?


Sent from my iPhone using Tapatalk

---

The motor is set to 12800 steps per inch. So that's roughly 504 steps per mm.

I'm a very long way from being an expert on steppers but I do wonder why you choose to use so many microsteps.It would appear to imply that you must have the ability to generate vast numbers of clean pulses.

Quote:

---

Originally Posted by routalot

I'm a very long way from being an expert on steppers but I do wonder why you choose to use so many microsteps.It would appear to imply that you must have the ability to generate vast numbers of clean pulses.

---

i think that number of steps is the mach 3 settings and not the micro steps from the driver. that's why the number seems so high. seems to be around 2000 steps per motor rev for a driver setting but it just depends on what the lead of the drive system is? imperial and metric are different in mach 3 when it comes to the settings.

I doubt that the problem is from the software & electronics, but one way to prove that would be to put pulses into your stepper driver by some other method. Arduino like microcomputers or use a single axis controller like Sainsmart sold thru Amazon. Either way you program it to move so far then change direction and repeat. Take your controller, computer and Mach out of the system.

I believe you may be seeing the disadvantages of building a cnc router out of wood.


Sent from my iPhone using Tapatalk

Quote:

---

Originally Posted by machinedude

i think that number of steps is the mach 3 settings and not the micro steps from the driver. that's why the number seems so high. seems to be around 2000 steps per motor rev for a driver setting but it just depends on what the lead of the drive system is? imperial and metric are different in mach 3 when it comes to the settings.

---

Not knowing the screw pitch and microstep settings on your drivers, it is impossible to say if you have too many microsteps. Your mach settings are simply a reflection of the machine and driver configuration. Personally, I try to go no higher than 1:8. The fact that your Z is losing or gaining over time indicates lost steps to me. There are a number of possible causes to that and you should work through each one. It is quite possib your laptop is the culprit as there are a number of reports of people moving up to a more powerful machine for mach 3 and solving their lost step problems. I'd start by "slimming down" your Windows machine. Turn off everything that might be taking machine cycles. Power saving is the first place I'd look.

Another possibility is noise causing random steps but I'm a bit skeptical of that since it only happens to the Z axis (right?).

FWIW, a wood based CNC machine can work fine though perhaps not as accurately and repeatable as a metal one.

No, the issue is actually on all three axis. Running the same code with the same motor settings in any of the 3 axis will generate the exact same amount of drift.
I do like the idea of turning off as much of the background windows garbage as possible. I'll see if that makes a difference.

I would concur that building a wood chassis for my CNC is not going to give perfectly accurate results. The strange thing is that the drift is so accurately repeatable. For example, I can jog a full 40 inches back and forth one time and my machine is pretty much dead on, but If I move back and forth 1 inch 40 times there's a measurable error.

I ran another experiment that I thought was pretty interesting a night or two ago:
Test1) set router to move between 1 and 1.761 back and forth 25 times then return to 0. The resulting error was 0.3mm
Test 2) set router to move between 1 and 1.762 back and forth 25 times then return to 0. The resulting error was 0.0mm, the drift was completely gone
Test 3) set router to move between 1.001 and 1.762 back and forth 25 times then return to 0. The resulting error was 0.3mm, the drift came back

It's almost like some travel commands start accumulating an error factor, and others do not.

Weather your using belts, gears, acme or threaded rod are you trying to remove backlash? Not normally a problem in Z though.
I know of nothing in Mach 3 that would cause an axis to drift.


Sent from my iPhone using Tapatalk

...are you using 3 or 4 place decimal (inch) Format or 2 or 3 place decimals (mm) with Mach3 ?

a .0005 error times 25 is about .3mm