Program glitched half way through…

Ok. Its been a few minutes, but @jamesfreeman gave me some guidance this morning on flattening a piece of mesquite. I’m on the small CNC.

my program is using a 2 in bit with a 40% step over cutting at a 0.05 depth each pass. My board is secured and for 3 passes (of 5) it’s working fine. Halfway through the fourth pass the machine stops moving and two seconds later it starts again but it’s going off board (and destroys my clamp thing before I stop it).

it seems as if it lost its coordinates or hallucinated new coordinates.

anyone seen this before?

yes. Just today. first set of runs resulted in 1 good unit (on right).

Next two shown failed, unsalvageable. Final one (not pictured) only failed on the last three of the drilled holes, so I just cut the outline manually.

These were not long running jobs at all. No idea on the solution.

Steve

Bummer.

I’ve consulted ChatGPT so take this with a grain of salt or two, but it says that this is a classic problem with when the bit heats up. In my case I was flattening mesquite (a hard wood) and ChatGPT suggested that on the fourth pass the bit would be heating up and that might cause it to glitch. It suggested in your MDF case that might be a similar culprit. “Bit heats up, MDF dust cakes on cutter, drag increases → torque spikes → skip occurs suddenly”

One suggestion was to run the program in air (z+0.5) and see if it completes.

Another suggestion is to decrease the stepover to 20% and decrease the depth to 0.03 per pass. Basically attempting to slow down the heating of the bit.

I might try these unless one of our expert humans has less hallucinatory ideas.

Side question: ChatGPT suggested a second possibility around static build up. Anyone know if our controller is grounded? “MDF dust = extremely static. Laguna IQ + USB = well-known trouble combo if ungrounded” … wondering.

I’ll post back with more data when I get back to Asmbly.

Cheers.

Will

I haven’t seen this problem myself, but we’ve had other glitches like early stop/cancels: Small Cnc stopped prematurely

I had the Y-axis change, mid-tool path, with no stoppage, today. First, I ran the same tool path twice, and the second was way off of the first one. I planed the board before I took a picture. I thought the problem was related to the fact that I was using g-code generated for the big CNC on the small CNC, so I generated the correct g-code and tried again. The first two tool paths seemed to work fine, but not the third.

In the upper left, the tool path was the green area, but the orange area was carved. I thought that the Y-axis (which was off by 13), changed between toolpaths, but then I realized that it cleaned out the shape in the green circle (lower left, early in the tool path), but was high in clearing out the shape in the orange circle (lower right, later in the tool path).

The y-axis jumped over 2 inches, mid-run, this time. Green is the original y-axis, red is the new.

Will the new controller be installed any time soon?

EDIT: The controller has decided to spare itself from my further wrath by refusing to read multiple USB sticks after multiple reboots.

Does the movement still feel gritty when you’re jogging?

Not that I noticed. It’s moving slower, but I think that’s just a settings issue.

I have a controller for that machine that I can try next week, that might help identify where the issue lies.

““Bit heats up, MDF dust cakes on cutter, drag increases → torque spikes → skip occurs suddenly”"

That really doesn’t make sense. If the bit heats up, you will see burn marks on the work.

If the bit is badly overloaded, in most cases the bit breaks first. If the bit doesn’t break, what would happen is the axis will try to move but the motor stalls. Those are open-loop stepper motor systems, they aren’t wired up to detect faults.

Once a stepper motor stalls, it generally remains stalled until the commanded speed of the motor drops to zero (hitting a corner or reversing). The axis will have lost its absolute position though, and further cutting will be offset and it is likely the stepper will drive the axis into the axis’s hard stops at some point. In some configurations, there are limit switches indicating when it overtravels, but usually not. In open-loop systems, the spindle doesn’t stop, so you’d likely see it gouge out a lot at the stop point, and likely some burning.

If it’s got a dual-motor axis like the big Laguna (not the small), it’s somewhat different. First off, the dual-motor axis is less likely to directly stall both since it’s got powerful drives built into it. Instead, it could stall one, the gantry racks out of sync, and it may be able to just skew the axis a bit before the working motor drags the stalled one back up to speed. Or it may rack hard enough to bind the axis and the other motor stalls too.

You would look for burning in the material. I don’t see any here.

Or, if the bit was overloading, you’d see bad cut quality then an obvious spot where the cut quality gets really bad, then a gouged-out burned spot where it stopped, and likely the offset will start right there. If it was cutting diagonally, one axis will keep moving past that point while the other is stalled, so the cut line will be become parallel to the working axis. The motor will recover but everything will be offset after that. If it’s cutting purely along the X or Y and stalled that, then it would just stop short with a bit gouge, burn, But it could also retract before changing directions, in that case the would not show it leading off in the wrong direction, but it would still be pretty obvious where the cut stopped short of the end of the line, ran at a standstill and rubbed/burned the cut.

The motor can do the same sort of stall if the axis has a mechanical problem- a linear bearing or the ballnut is contaminated and jams, or a bolt backs out somewhere and jams the axis.

If the Z is going to stall, it almost always does so on the lift, and would be due to the axis being dirty. It may leave less evidence at the point it fails, but stalling on lift always offsets downward leading to gouging the work and often the bed.

There is a slightly different case where a loose motor coupler slips, where the symptoms look similar but there’s some telltale signs that might occur there.

But honestly I don’t see evidence of that here. Steve’s photo doesn’t show the bit getting stuck mid-cut. The description is that the Z offset upwards, so that generally rules out all mechanical problems with the Z. It has to originate in the drive’s step/dir signals or before. And it appears the offset happens between runs- that points to a problem in the controller.

Frank’s photo shows offset in X or Y, which is a totally different problem. The orange hole is very possibly a stall point. The working axis kept moving in a straight line but the design doesn’t go far from there. There are no burn marks so the bit isn’t worn or overloaded. This could be RPM set too low, but more likely there’s a mechanical problem (gunked-up axis jamming the ballscrew or linear bearing) or electrical problem in the step/dir signals. It is unlikely the controller caused this one (possible, but unlikely).

Well, I’ve been trying to say for a long time that these need to be converted to LinuxCNC. It is a vastly more user-friendly experience in so many ways and you can add a lot of safety checks to prevent the exact problems that have occurred. It’s much easier to diagnose problems within it and replace components. Also can run a heck of a lot faster.

You can also change to close-loop steppers (they’ve been standard for years) which gives absolute fault detection to immediately halt the system if the motor stalls due to overloading, mechanical jam, or drive fault. Or, just, actually wire in the looser fault detection safeties that already exists on open-loop drives.

I’ve been told this is straight-up forbidden to even talk about. Honestly, this has been painful to watch.

1 Like

Looking at my failed parts again, it looks like the controller simply skipped some lines in the program and just continued on.

On the sample on the left it should have completed the perimeter path then cut out the “grid” pattern. but in this case it did 3 sides of the rectangle then skipped the left side (-y movement) and started in on the grid above the full rectangle path that should have enclosed the whole part.

Second one completed the rectangle but then skipped +y movement and repeated the grid cutout on the bottom 1/2.

For the the first failure, I was adjusting the VFD spindle speed when It happened, but the other failures the speed was not adjusted mid program.

Thanks for the extra info, we are looking into the problem. Were you using the provided usb’s?

Interesting. I was using the small CNC a couple of weeks ago and suddenly it just cut a groove straight across the middle of my piece ruining it. I assumed I had screwed something up with the GCode and it was operator error. Seeing all of these reports has me thinking there is something off with this machine. I was back last weekend and used the large machine and everythign went perfectly.

I had the large CNC plunge about twice as deep as the tool path specified. The Vectric preview was fine. The weird thing was that it only did it on the first half of the tool path. Luckily, it was the cleanup path on a vcarve inlay plug, so it didn’t matter, and it did not cut through to the spoil board.

Hi James. No. this was my own USB. I have been using it for every run I’ve ever done on both the Laguna s. Can’t recall a problem like this on either before.

I am a very strong supporter of copying the file onto the control before running it. Especially on longer complicated files.

2 Likes

I spent a little time on the Laguna IQ CNC yesterday and had some issues with the USB drive disconnecting from the controller with just the smallest bit of movement of the controller. I would then wiggle the USB drive and sometimes it would reconnect and another time the controller wouldn’t recognize it at all no mater what I did. The LED light on the drive would not light up. I even tried using a different USB drive and that wouldn’t light up either. I power cycled the CNC and then it would read the USB drive again.

To me this reinforces the idea that the file should be copied onto the controller and not run from the USB. To those not knowing how to do that, the steps are:
Put the USB drive into the controller, select the Menu button, scroll down to “Operate File” and hit OK on the controller. Scroll down to “Copy File” and hit OK. Select “UDISK File” and the files on the USB drive will be listed. Select the gcode file you want to load onto the controller and hit OK You will then get a message saying “The file is copyed successfully”.

Running a job from internal memory:

Select the Run/Pause button. Select work file, scroll down to “Internal File” and press OK. Scroll through the list of files on the controller, highlight your file and select OK.

If we have another controller then I would be willing to volunteer some time to help getting it installed. Would just need a little more info and guidance on what we have.

Thanks for those instructions. I’ve never done it, before, and will have to try it out.

I assume that it’s just as easy to delete the file when you’re done?

Deleting files is in the same menu area of “Operate File” and is just one or two after the “Copy File” entry you use for loading the gcode into the controller.

1 Like