Problems on the CNCs

@buzmeg Thank you for the insight on the USB. I think you hot it nail on the head. It seems smaller g code files run fine on the USB, and even larger ones have as well. But relying on that connection to be perfect throughout the whole cut could be asking a lot. Even just bumping the controller with the usb in it could cause an issue. Laguna did confirm this when I asked, saying best practice is to run files from internal memory.

@zack.simpson I’m glad to hear the internal memory is working better. From what I’ve researched, it is the better way to run a file. Thanks for testing things out. I’ll see if we can get a cheat sheet made for the process to copy to internal.
6: There are lots of things that can lead to this. Anytime you are looking for very precise top surface, you should surface the material after it’s mounted to the spoilboard. Even store bought material, in my case most of the time, isn’t very true. Hold down methods, humidity, spoilboard conditions and other factors can all make the surface not completely flat. Surfacing the material after it is mounted to the spoilboard will ensure it is true to the spindle at that time.

Thanks for posting your follow ups to the problems, it helps us all.

Laguna has sent us another controller after reporting the problems with the USB reading on the large machine. I’m going to try a few things out before swapping the old one out.

One thing I have noticed, both controllers have bent screws were the cable connects to it. I know I have, but this indicates the controllers have been dropped. A habit I’ve been trying to get better about: after homing the work piece, I replace the controller in its holder and run my jobs while it’s secured there. Which reminds me, a holder for the IQ still needs to be added to the work table.

1 Like

Today’s summary: Better, but still a major problem.

Another few hours on the small CNC, using my now perfected workflow of copying files to the controller. I also added a top surfacing path as suggested which resolves my (6) from yesterday.

Thus, it seemed as if ALL my problems were now resolved until…

*** CRASH! ***

The “Z Gremlin” wherein the machine decides in the middle of a run that Z is in a different place. This time it decided that Z had shifted down deep inside my work (last time it went up, thankfully) and thus not only was the project destroyed (no worries, was a test) but so was the end-mill and – again – I nearly started a fire. I hit emergency shutdown amid much smoke!

I am 100% positive that this “Z Gremlin” is not my GCode. Not only did I scan it carefully but also it ran the same code with no issues at other times. It is also is not the USB since I was running it off internal file storage at the time.

I’ve now seen this “Z Gremlin” twice with 100% confidence on the small CNC and I’d say with at about 50% confidence that I’ve also seen it on the large. (Reduced confidence on large CNC because of other possible confounding variables that might have confused me at the time).

So. Here’s where I’m at… IMHO the “Z Gremlin” not only renders the CNC useless for my cuts but also dangerous. I’m going to have to stop experimentation until we can figure this out.

Meanwhile, I’ve documented the process of using the internal drive on the controllers for others. It is so much more stable that I’d highly recommend that we change the laminated cards to use this procedure…

ADJUSTING controller manual speed

  • Press yellow cancel until you get to “ManualParam” screen
  • Scroll down to “XFast” (using Up/1, Down/5 buttons) and hit “Run/Pause”
  • Type the speed with the keypad digits (2000 is good). In this mode, Run/pause acts like a backspace key
  • Hit green OK
  • Repeat for YFast, ZFast options
    These changes survive reboot. So as of right now on the small CNC, you’re going to get my settings at 2000.

DELETING files from the controller internal store

  • Hit yellow cancel until you are on the coords page 1X, 1y 1z etc
  • Hit menu button
  • Scroll to “Operate file”
  • Hit green OK
  • Scroll to “Del file”
  • Hit green OK
  • Hit ok to select “Internal file” (the only option)
  • Scroll to the file you want to remove. (Note, you will not be able to copy a file of the same name without deleting the one on the controller first; ie there is no “overwrite” option)
  • Hit green OK
  • Repeat for all the files you want to delete

COPYING files from the USB to the controller internal storage

  • Insert the USB
  • Wait about 10 seconds (On a USB with a LED you will see the LED flash; when it is steady, it is mounted)
  • Hit menu button
  • Scroll to “Operate file”
  • Hit green OK
  • Scroll to “Copy file”
  • Hit green OK
  • Hit green OK again to select “UDisk File” (the only option)
  • Scroll to file to copy
  • Hit green OK
  • Hit green OK again to clear the “Information” screen that says “copyed[sic] successfully”
  • Press yellow cancel 4 times to get back to main screen
  • Remove the USB drive

START your run

  • Hit run/pause
  • Scroll to “Internal file”
  • Hit green OK
  • Scroll to your file
  • Hit green OK

You are now ready to start as usual.

1 Like

Can you post your file?

This is a top-datum that descends into the work -12.70 mm (and scans above the work 3.17mm).

FWIW - It’s only happened to me once and only on the small machine…. But I’ve had the drifting Z happen to me with fusion generated g-code (sadly I don’t have the file anymore).

Well, I have a lot of ways I could answer that, but keep in mind the forum has hard rules about criticizing the Laguna equipment, I value my membership and participation here very much

Laguna did not make that controller. It’s a Chinese controller called RichAuto. It’s not very well documented or supported by the mfg, and minimally integrated with the machine. The LinuxCNC option is intended to remedy that, and do so much more, but dual-boot is feasible if you really want to use RichAuto.

But the problem with the Z is not likely the controller, motor, USB, or electrical noise. Either the rail or leadscrew is mechanically jamming, or the shaft coupling is slipping.

This almost always comes from a Z axis stall due to binding up, or coupler slippage, and will almost always occur on the Z-up due to having to lift against gravity in that direction. This machine was not built with closed-loop motors, nor was the fault detection hooked up to anything, so the machine will go out of sync with where the controller thinks it is if that happens. Since it commanded a Z-up and the machine stalls or slips, the axis will be lower than the controller thinks it is.

A similar effect will happen if the user’s bit is not in the collet tightly, and pulls out. However, that would be readily apparent upon close inspection that the bit has extended itself out of the collet, so I’d start looking for z-axis mechanical failure first.

That’s an inaccurate statement and given how in-depth you and I have spoken about posts for which you have been moderated, you should very well know that. If you need a refresher on what’s not OK, please reach out directly or refer to the email threads we’ve exchanged around these issues.

Danny’s theory of Z slipping sounds plausible to me.

The collet was definitely tight. I had made a significant effort to tightened it when I put it on and it was still very tight after I let everything cool down and then dismounted my sad, scorched bit.


If it were Z slipping due to load I would expect it to be almost always in a single direction, not both. At this point, it feels like something is intermittently losing control.

It seems like this only occurs after quite a while (define that–10 minutes? an hour? 2 hours?). It would be interesting if you could check and see if the Z setting is already a little off in the middle of the run before things go really bad. It could be that the Z axis is losing a couple of steps here and there until eventually the load causes it to slip wholesale.

If it can lose Z immediately, I’d guess loose or broken wire. It could be a a bad power transistor or something wrong with the motor (quite a few people have stalled that motor, no?–that puts a lot of load on both the windings and the power transistors). If it takes a while, I’d guess problem in the controller–possibly overheating in the controller (you did mention that you have a lot of little movements).

Does the controller board have heatsinks with fans? Have we blown them out any time recently? Our environment is notoriously bad for sticky dust.

The load on Z-up is substantially higher than on Z-down, but the motor’s max torque capability is the same clockwise and counterclockwise. So when you slip or stall, it will always be on the Z-up. It could only stall on the Z-down if it was binding really bad, in which case it would already be stalling on every Z-up. That is, with a binding axis, you’re going to see the stall on Z-up and the problem is going to be noticed before it gets so bad that it stalls on Z-down too. It would probably be binding constantly on Z-up before it’s going to stall on Z-down.

Stepper motors do not “lose steps” bit by bit. When the torque load exceeds the motor’s max torque, it enters a stall state that will not recover until the motor speed command reaches zero again. So it will lose a large amount all at once, there’s almost no case where it can lose just a step or two due to overloading.

If a machine is creeping around losing steps little by little, that points to an integration problem where the controller’s active edge on step/dir does not match the driver. Or the coupler is slipping.

Stepper motors do lose torque at higher temps, and they do heat up while on. The old drivers created a constant heat when on regardless of load or motion, but anything made in the last 10 years folds back the current if there’s no step command for a few moments.

So, it’s not very simple to test, it takes about 15 min of back-and-forth motion to reach its max operating temp. The nature of the stepper drive is that the heat generation and max temp don’t actually change with speed, acceleration, or load- just that it stays in motion and avoids the drive falling back to idle (no motion commands).

I would mostly rule out a loose connection, bad drive, or problem with the drive overheating. It’s not impossible but these symptoms don’t point to that at all. They can fail, but they will not do this, that will cause notably different symptoms. I’ve seen this quite a few times- binding linear rail, binding leadscrew, or the coupling is slipping.

What software are you using to generate gcode @zack.simpson?

I wrote it myself. It is nothing but a whole bunch of G00 and G01 commands. It is a lot of tiny movements however, so that might support the heating theory.

I’ve been following this thread and I really don’t think there is a machine issue.

I just ran a project twice with 9 operations (through cuts, pockets, helical bores, spiral 3D, and contours) using 3 bit changes. No issues whatsoever with cut depth or USB. I’ve used both IQ and Swift a lot in recent weeks without issues. All using toolpaths and gcode generated in Fusion 360.

From my experience, Z height issues are 99% user error in the toolpathing and/or not tightening the collet enough. It’s also a good idea to re-check collet tightness after aggressive cuts.

I strongly advise against writing gcode from scratch as it significantly increases the likelihood of errors. All it takes is a misplaced period or inverted number. Use VCarve or Fusion 360 for CAM.

I’ll also note that many industrial grade CNCs use a pendent controller, often with USB, instead of a computer. Most USB data throughput issues that used to plague older machines have since been resolved. Industrial machines that use a computer typically have an isolated purpose built system (not windows or linux). I initially thought I would hate the pendent but now I prefer it as there is less that can go wrong vs introducing an intermediary computer system.

Charles, let me clarify… I didn’t HAND write it myself – I wrote the code that generates it. I have multiple automated sanity checks in place that the Z positions are correct; in addition to that I scanned the file myself to make sure. I also attached the file above and you can check for yourself. In addition to those sanity checks, I have a better one – I have run the same file without incident – so that falsifies the theory that the gcode is wrong.

Like Charles, I have also run many successful operations on those machines. Yet randomly, twice now, Z has failed catastrophically. I absolutely agree with Charles that “99% of issues are user error” and since I’m a professional engineer of 35 years I have been assuming what any good engineer would – that everything is my fault – which has lead me to check, double check, and unit-test all that code so I’m well past that point now.

There is a “gremlin” that causes random changes in Z. I have no idea if it is the controller or mechanical but I think Danny’s mechanical reasoning seems the mostly likely culprit to me.


I’m not 100% saying there are no mechanical issues, just that I’ve been using both machines extensively and have not experienced the same problems. I’m more concerned that this thread is devolving into “let’s rebuild the machines,” which should not be the solution for numerous reasons.

I will note that both 1/4 collets are getting pretty warn and need to be wrenched down very tight and should be checked frequently. I recently had one slip on me after running multiple parts without issue. It still kept cutting but it was a few mm lower than when it started.

So I understand correctly, you wrote your own program that creates Gcode? Why not use VCarve or Fusion? I’m not questioning your technical abilities, it just seems safer from a programming standpoint to use an industry standard CAM software that has a post processor designed specifically by Laguna for their CNCs.

1 Like

I had also noted the 1/4" collet is getting loose and took particular care to make sure that everything was extra tight in my last run. As mentioned above, I double checked the bit tightness after the latest crash when I extracted the tool and it was still mounted solidly.

Charles, to your last question (a totally reasonable one!): numerous reasons that aren’t relevant to this thread but basically because I need particularly “fine” control for my long-term objectives. (I’m not trying to create a single cut but rather develop an algorithm for a class of related cuts.) Feel free to look over the gcode posted above; there is nothing odd about it – it starts the spindle, moves around with G0 and G1 at fairly slow feed rates and then stops the spindle.


Belts, set screws and tension were check. No obvious problems found.

@zack.simpson What is your plunge speed into the material. I’m fairly novice when it comes to gcode, but it seems like some of your plunges are 100ipm?

All of the plunge lines look similar to this:

G01 Z-5.080 F2540.000

Which translates to “Linear move to Z = -5.080 mm at Feed rate of 2540.000 mm/minute”

Which as you say, is 100 inches per minute. I had previously tested at a variety of speeds and this seemed fine but I can easily slow it down and re-test.

Are there any docs that specifically state limits on these rates from Laguna? (I’d be surprised if their firmware didn’t have built-in limiters, after all, from their POV GCode can’t be trusted and one would typically put limiters into the firmware at the point where you’re driving the motors.)