I’ve recently noticed that on my Nomad3, I tend to lose my X zero over very long jobs. It only seems to happen between operations, so I don’t think I’m losing steps. I could use some extra brains out there to try to figure out the cause. Here’s a scenario…
Verify all X,Y,Z zeroes
Face part on side A to 12.3 mm
Flip and face part on side B to 12.0 mm (guaranteeing parallel sides)
Bore 6.03 mm holes through stock at (0,0) and (0,127) to create registration points
Insert 6 mm studs at locations (0,0) and (0,127) on Nomad3 bed
Fit workpiece holes over studs (tight fit) so that the Y axis (X=0) line of symmetry is established
Ramp down a rectangular perimeter for 9.0 mm in Z that is 25.0 mm wide in Y, and centered relative to my registration holes
**** SOMETHING HAPPENS ****
Flip part about Y axis, and refit to registration pins
Ramp down the same rectangular perimeter for 3.1 mm in Z to cut out remainder of my dimensioned blank
At this point, the seam created by my two perimeter cuts is shifted by 0.2 mm, meaning that my Y zero changed by 0.1 mm. Not a huge deal, but noticeable, and problem on this job. Later similar operations showed the same type of shift, but at a misalignment of 1.05 mm - a whopping 0.525 mm shift in my zero.
As I said, for any single operation, the perimeter is consistent, so I’m fairly confident I’m not just losing steps. I’m also ramping from the top down, so there’s consistent pressure in X and Y directions - any lost steps would be in Z.
Since I only notice this on longer jobs, I’m wondering if there’s an issue in initialization after disconnecting from the cutter, and coming back later to run again. At one point, there was a power failure between ops so the Nomad3 lost power, and I had to reinitialize. At another point, I needed to move the laptop that was running CC, so I had to disconnect and reconnect between ops.
Has anyone seen such a huge (0.5 mm) change in your X zero after disconnecting and reconnecting from the Nomad3? Or can you think of something else I’m overlooking?
I just ran these cycles without any power interruption or reconnection of the machine, and I got a shift of my X zero again. It moved 0.15 mm this time, and again, only in X.
After running the ops, I used the Rapid Position command in CM to send the carriage to X,Y = (0,0) and my cutter is visibly shifted in the X direction. It’s actually at (0.15,0), but believes it’s at (0,0).
I’m pretty confident that I’m not losing steps, because my walls that were cut down in 0.1 mm layers are all perfectly vertical. If I had lost steps, I’d see a shift in the layers at each point a step is lost.
I have a 6mm threaded dowel pin located at (0,0). If I touch the right side, and then the left, I measure +4.737mm and -4.437 (via CM display) … a difference of 0.3mm, so each is off by 0.15 mm.
I can also send the carriage to (0,0) and it’s visibly shifted from the center of that pin.
Finally, that piece is supposed to have a 25.00 mm width after that step, and it does (+/- 0.03) via my calipers). But the distance from the “centered” hole’s edge to the side of the workpiece is 19.35 on one side, and 19.65 on the other - again, a difference of 0.3mm, indicating two errors of 0.15 each.
The only thing I can think of is that I interrupted the program at one point, because I wanted to change my G code to use smaller stepdown. Then I restarted it. Perhaps somewhere in that process, X got rezeroed. But Y and Z remained consistent, so I think it’s unlikely.
I had no crashes, nor chatter. Just got a new zero at some point.
I’m looking at the “Rapid Motion” command as a possible culprit. Stepper motors lose a lot of power the faster they spin. Too aggressive of an acceleration rate can cause lost steps also.
Interesting - I was thinking the same. I just rezeroed, and manually trammed the carriage around at high rate, all over the X,Y plane, just to see if I could induce an error. I sent it back to (0,0), and alas - it seems to be still zeroed.
I don’t have any intentional rapids in my G code, but it’s obviously calculating some on its own between profiles in one job. Any idea how I could limit the speed of these rapids, either in Fusion360, or (preferably) in CM?
My fastest movements are 1000 mm/min, and the manual tramming in CM reports to be moving at 1500 mm/min. But if I send “Rapid to Current X,Y” then it moves at about 4700 mm/min (diagonally). Seems like I should be able to replicate the error by a combination of manual movments, and fast returns, but so far, no. Also, if it was just during jogging, it seems like someone would have noticed this before now.
The only time it seems to lose its zero is during or between ops of a job. I suppose I’ll run a ghost job, with no stock, to test the theory that is has nothing to do with lost steps due to tool load. But that will take a few noisy hours to test…
There are Grbl settings to change acceleration rates, and maximum travel speed, Perhaps one of the gerbil wranglers can chime in with where and how to change those settings.
I have a clue now. I ran many ops over the last day, and never lost the X zero, until I broke a cutter.
I just restarted my last job, and when prompted to install Tool #1, I swapped in a new cutter for the old broken one. Then I let the job start as normal, and even though it should have been cutting air for a while (until catching up to the problem spot in teh G code) it started digging in to the side wall. I stopped the job, checked my X, and it’s off by 0.487 mm.
My Y and Z zeroes still seem fine.
Now, I understand that a crash could disrupt the position of an open loop system. But it was making a diagonal movement when it crashed (I happened to be watching) and Y is still on the money, while X is off by nearly half a mm. Plus, it seems like the Nomad3 should have been able to re-find the zero since it trammed around to the limit switches when starting the new job and loading the cutter.
I tried earlier to abort and restart a job, but that didn’t disrupt my X zero. But breaking a cutter somehow did this time.
Did you power cycle/initialize the machine then or just reran the job ?
Did it really ? or do you mean it probed the tool length sensor. I don’t think the machine homes upon starting a job, but only upon “initializing”? Just checking the wording here since you are correct that a homing/initialization should have cleared any lost steps from the tool break.
By the way it’s not impossible that even though the cut was diagonal when the tool break happened, the machine only lost steps on X. I don’t know if the force threshold to start skipping steps is identical on X and Y ?
When I restarted, I simply hit Pause and then Stop when the cutter broke. At that point, the carriage went all the way to the right, and the table came forward. This is what I meant when I said it trammed around to the limit switches.
Then, I hit Start, without even reloading the NC file. The machine asked me to insert Tool #1 as it normally does (but I replaced the broken stub with a new cutter) and at that point it measured the tool length.
I had thought about the screws on X and Y not beign identical (as you mentioned) so maybe it’s more prone to skipping in X only. X has one screw, whereas Y has two. What I hadn’t considered is the way the spindle is mounted. It seems like it would be easier to move in X, because it only has to twist slightly around the two mounting bolts. There’s a huge interface plane keeping it from moving in Y, so maybe that’s the difference.
I don’t think I broke a cutter the last time I noticed an offset - in fact I’m almost certain. But maybe I didn’t notice it bog down in a cut (in plastic) and apply enough pressure to twist the spindle and cause the offset.
Not sure if I can tighten those bolts any, but I’ll try after this current job is finished.
I don’t think the machine homes upon starting a job, but only upon “initializing”
IIRC it does a full initialisation if the job doesn’t complete “normally”.
I can believe that homing may not result in physical zero being identical every time.
Yes, any instance where the machine may have lost steps means that the machine state is no longer guaranteed to match the software state, so one must re-initialize/home the machine in order to ensure that they match.
OK - maybe this is what I was missing then. I assumed that X and Y were verifed when it goes through its “dance” to check the tool length when swapping cutters. If not, then at least that provides a possible scenario to explain what I experienced.
I can believe that’s what happened when I broke a cutter in 6061 last time - I was standing there, and saw the machine try to take a huge cut due to an error in G code. It managed to make this same cut previously in HDPE without breaking, but maybe it still lost steps there, and I didn’t realize it since it wasn’t so catastrophic. If that happened, I suppose it could explain all cases.
I’ll follow this line of thinking, and report back. Hopefully I have all crashes out of my program now, so it should be smooth sailing for production once I tweak my final op.
Thanks to all for the feedback, and helping me think through this!