Problems on the CNCs

Space Teams CNC
1

I’ve been experiencing a number of problems on both Laguna CNCs.

At first I was blaming them on my own gcode but I’ve now experienced enough of them to say confidently that the problems are not just my own problems. Furthermore, I’ve experienced some of these while Doug Squires was with me and we sanity checked each other to confirm that the problems were with the machine/controllers.

  1. The controllers on both machines are difficult to use (speed control in particular is very cumbersome). This is an inconvenience but not critical. That said, I suspect that those controllers are nothing more than serial devices that are emitting gcode. There’s probably good replacements for them.

  2. The USB file-reader has serious problems. I’ve only noticed this on the large machine, but it happens every time I use it – I load a file onto the USB stick. I load the file and start cutting. Maybe I cancel and want to reset. Then, seemingly for no reason, the controller can no longer find files on the USB stick that it was just reading a few seconds ago. Occasionally pressing cancel and trying again works but usually I resort to a full reboot of the controller and even then often the reboot isn’t enough and I have to reboot again or even three times. This is particularly annoying in that the controller gives untrustworthy messages about the state of the home setting. It generally seems to remember the home position but the controller will always ask if you really want to continue without a set home.

  3. I’ve seen both the large and small machines terminate prematurely for no apparent reason. There is no way for the devices to show status so I have no way of knowing what error faults might have been triggered. Maybe I’m seeing this often because my cuts involve a lot of detailed instructions (i.e. long gcode files comprising many small movements). But really, I have no idea why it happens sometimes and not others.

  4. I’ve seen both machines dramatically lose track of z. In the most extreme case while using the smaller machine I had a run that suddenly decided in the middle of a run that the Z=0 plane was about 3 inches higher than it was just a few seconds before. This can not be explained by a tool slipping – the program was clearly running much higher. Furthermore, it can not be explained by a bug in my gcode as I re-ran the same exact file (after resetting z) on the same material and it ran to completion without incident.

  5. The spoil board on the large machine in the “A” section has been sufficiently carved-into that it can no longer pull a sufficient vacuum to stabilize work. This is expected and it would be easy to accommodate for between resurfacings by simply using the further vacuum sections (like the E) except for the fact that the z-puck doesn’t have a long-enough cord meaning that I have to resort to manual Z; however, manual Z is particularly problematic for me because my cuts involve tool changes and the precision of the paper method is tricky. Maybe there’s a way to attach a longer cable to the z puck?

2

This is definitely annoying and I have experienced it. The easiest solution should be to mount the puck to the toolhead rather than the front of the machine, it just needs to be grounded, so this should be possible.

3

Hey @zack.simpson

Sorry to hear you’ve had trouble with the CNC machines. To address your questions:

1: Are you referring to speed control while jogging the machine our while running a file? Are there other concerns you have? The controllers can actually do more than we teach in the intro class, and a few advanced techniques make them easier to use. Of course there will all be options of replacing controllers. We aren’t currently seeking that, as these machines are still under warranty. Also, changing controllers would likely cause the need to retrain all current members. As with any tool purchase, the desire to find a good fit, within budget and develop a education program are all considered in making the purchase. With just a diverse skill level at Asmbly, no one tool will ever be perfect for all members.

2: I have seen the USB issue more with the Swift. At first I suspected it was the cheap USB drives we were using, but it seems to have gotten worse. I’ve spoken with Laguna about the problem. One thing they suggested was copying files to the internal storage of the controller and running the program from there. We are also likely going to submit a warranty claim for replacement, as he agreed that the problem seems more likely to be the physical reader.

  1. This could be from the size of your file being run from the usb drive. Again, I would suggest trying running the file after copying it to the internal memory of the controller.

  2. I’ve only heard of the Z problem once or twice, and never on the Large machine. I have a few running theories about what could be happening, but there isn’t a great way to test it. Laguna did ask me to verify the belt tension and set screw tension on the small machine for the Z axis, which I did this week. He mentioned that jobs with lots of 3d cuts that are run to fast can cause this, but I’m not sure of your job type (sounded like maybe he was suggesting Z motor skipping).

  3. The spoilboard on the large machine is absolutely in bad shape. It seems to have taken quite the beating since the last time I resurfaced it. I plan to replace the board this week, material availability permitting. @Allzman helped me surface the IQ spoilboard as that one was pretty bad as well. The mdf is now closer to the aluminum T tracks than I like, so I’ll work on getting new boards cut and installed. I’m hoping Laguna has some ready mode files for cutting them, otherwise we’ll design them. Shouldn’t be hard, just takes time.
    The Z puck is a simple ground circuit. The wire can be extended simply, but I’m concerned about having a bunch of extra wire hanging on the front of the machine, trip hazard or it may just generally get abused.

4

I imagine the hardest part of doing this would be re routing the ground circuit through the cable chain. Then just having a connector and mount on the gantry. All should be doable.

5

It is actually suprisingly simple to convert these machines to LinuxCNC, and there’s every good reason to do so.

It is a bit more complicated, but entirely feasible to do this as a “dual boot” system. You can run it blindly with the RichAuto controller, or run off the LinuxCNC terminal with full features, visibility, and control.

The integration was much shallower than I initially assumed. I can do a board that literally takes a few minutes to hook up or return to its original state if something isn’t working right. But the idea would be essentially a simple manual hard switch outside to switch the pins over to the RichAuto harness or LinuxCNC.

It would not necessarily need any extra cabling between the control center and machine. It really does need a second gantry homing sensor to fix the accuracy problems, but the accuracy buff would only apply while booting under LinuxCNC.

1 Like
6

A quick note* on #5:
Your material thickness is what it is and the bed height is what it is. You could set z zero in F then move to E and cut over there.

You may want to experiment with zeroing to the bed surface rather than material surface.

7

I see in some forums that a combination of Mach4 and a PMDX control board for these is looked upon favorably with great results. Danny’s solution might be a bit less complicated to get going and certainly adds some great improvements. I think we’ll find that operating the rotary would be a lot easier with a more robust controller.

I watched two separate users struggle yesterday with the old controllers. One was left in absolute mode, and one in 8x,8y,8z mode which I don’t even know what that does but it was adding an offset. We might want to add to the cheat sheet or a sign with instructions how to reset the controllers to the “normal” 1X,1Y,1Z state.

8

LinuxCNC vs Mach4 is no question- LinuxCNC wins hands down.

It’s very well supported, fantastically well developed and featured, and very open to customizations.

If I’m allowed to put on LinuxCNC, the wireless MPG jogwheel, wireless Z-probe toolsetter, G-code/panel control of spindle rpm, error-free independent gantry homing, are coming right back. And we can control the vac pumps too.

I did already start drafting the PCB to do that upgrade.

9

I’d be happy to learn LinuxCNC and help out with installation, testing, revising instructions and classes, and assist whomever instructs the eventual class. I think we can meet the goal of not impacting existing users, any material downtime, or doing anything not completely reversible. Thanks for your ideas Danny!

10

Many of our users still know LinuxCNC, it was our standard for CNC routing for over 10 years and worked really well. There’s been a lot of people wanting that back.

11

This has been discussed before, and I’ll re state it now. The controller will NOT be changed or modified while we are under the warranty period. This is not up for discussion.

If there are questions regarding using the current controllers, I’m happy to help with them. The is no difference between using 1x,1y,1z and 8x,8y,8z as far as function goes. Changing the numerical value simply changes the work origin set. In other words you can set up to 8 work origins at a time and scroll between them, think production work.

The Ax, Ay, Az indicates the machine is in Absolute coordinate mode. This tells you were the spindle is relative to the machine homing.

Most of the time, these variables are changed by mistake, from a mis keystroke on the controllers.

If you’d like to learn more about the advanced features of these controllers, I encourage you youtube videos of them, or I’d be happy to meet up and show you.

Again, the controllers will NOT be modified or changed while the machines are under warranty.

4 Likes
12

This isn’t necessarily going to work depending on the state of the spoilboard, in particular how flat it is able to pull your material. Any amount of warp will cause the material to not be pulled flush in a damaged A section, so you can’t get an accurate reading in E.

13

I disagree with this STRONGLY. If the problem can be fixed by switching to LinuxCNC, we need to send these machines back to Laguna and get something that doesn’t suck. The whole point of buying a “brand name” is for it to be a turnkey thing that the manufacturer has some level of responsibility to keep running.

However, USB sucks. Period. Windows, Linux, OS X doesn’t matter.

  1. You really don’t want to run programs from USB. USB communications are differential but USB insertion detection is not. Industrial environments are notorious for generating transients that cause hiccups on USB.

  2. Termination and Z loss seem like communication over/underruns. USB again is likely the culprit–especially in the face of transients. USB 2.0 can nominally read 48MB/s, but that is only if the program is being sane. With a lot of gcode for a high volume of small movements, you can easily overrun a program doing something idiotic on file I/O (like unbuffered read to CR/LF rather than mmap() of an entire file). In addition, you could get something like a file indexer or anti-virus running that will bog your USB bus to a crawl. Finally, at some point your USB stick will likely hiccup to buffer if it is running flat out for a while.

Dumping the program to internal SSD and running from there bypasses any problems caused by USB. It may not fix all the issues, but it will help narrow down what is going on.

2 Likes
14

Hey James - I can’t remember the menu on the controller… is the path to copying from the usb to controller memory pretty self-explanatory? And I’m guessing that since we’re talking about memory I shouldn’t worry about jamming up the controller with my gcode artifacts - turning off the machine should wipe it?

15

I’ll check the path to saving tonight, and report back.

16

Hey everyone – I have some updates…

First, thanks for all the activity on this thread. I appreciate the good problem solving going on here…

Today I used the small CNC extensively and learned a few things. I’m referring back to my original posting with (x) points.

(1). With some fiddling around I found I could change the speed of the manual step. Oh, that makes a lot of difference. I moved it down to 2000 from 6000. I’m not sure if these settings persist over a reboot or not. But anyway, as far as I’m concerned, other than being fiddly, this address my (1).

(2). As suggested, copying to the internal memory from the USB makes a big difference. It is extremely fiddly. To answer Doug’s question above – YES – you have to delete the files that are on the controller. Indeed it won’t let you overwrite a file that is already on the controller. So the procedure is "Menu – File (that’s not the exact menu option, but something like that) – Del – Internal – {choose file} – Ok – Ok again (to close the “you did it” message}. Then repeat that using Copy – Udisk – {Select file}. After copying all my files, I pressed cancel until I was back to the main screen and unplugged the USB just to get it out of the picture. Then when you run you select the files from the “internal” rather than “UDisk” and everything seems a lot happier.

As a point of comparison, before I fully figured out the Del/Copy/Remove USB workflow I tried to run via the USB as per usual (as suggested on the laminated cards.) And, indeed, again it couldn’t find the USB and again it locked up the controller so again I resorted to a reboot.

This is where I got into TROUBLE! On the large CNC I was able to skip the re-homing after that forced reboot. So I tried the same thing again today on the small CNC and then – OH NO(!!) – Z crash (!!) I almost started a fire before I could hit the emergency stop. So, lesson is: YOU MUST re-home after a reboot and therefore it is basically critical that you use the internal storage because otherwise you’re rebooting and re-homing a lot and might forget (for me, that’s A LOT because I’m running a lot of little experiments).

(3) I didn’t have enough experiments today to say definitively, but I had no weird terminations while running off the internal storage. So, maybe that’s it. Will keep at it and report back.

(4) Like (3), I didn’t see any radical Z changes. But I didn’t do enough work to say authoritatively that using internal storage eliminated that particular demon.

(5) I was on the small CNC today so (5) was irrelevant.

I did discover a new (6) however…

(6) I was running on a pretty square board (or so I thought) and I was testing some operations that come back along the un-cut top surface to graze it with the intention to clear off fuzzy blow-outs left from previous cut. Oddly I found the z on at high X was different than the Z at low X by about a millimeter. Then I thought about this for a while and realized that there’s three possible explanations… (a) My board isn’t perfectly flat. This seems unlikely to me given it is an industrial machined object. (b) the small CNC gantry isn’t dead parallel to the work surface or (c) there’s some very subtle Z slip. I’m pretty sure it isn’t (c) because it was repeatable. I assume the way to tell if it is (a) or (b) is to use a sufficiently large gauge block. Do we have one in the shop somewhere? In the meantime, I realized that on my future cuts I need to perform a full surfacing operation on the top of my boards – ie not assume that the top is parallel to the gantry plane. Regardless of which hypothesis (a or b) is true, I think that will solve my problem.

Zack

1 Like
17

I’m glad to see we’re figuring out workarounds for the issues.

One question to add to the mix: is it worth looking into any form of power isolation / conditioning? While I won’t claim any specific experience or expertise there, I find @buzmeg’s hypothesis at least plausible that transient power issues could cause USB hiccups. Is it at all feasible to isolate the power source for the controller from other potentially-noisy devices?

Personally, I’d much prefer a workflow where I don’t rely on a cheap USB stick or a controller that might not be able to reliably read from it. If manual copies to memory are the answer, so be it, but that workflow does sound pretty klunky and error-prone. Whatever we might be able to do to streamline things and improve reliability sounds very much worth considering.

18

Devils advocate here, I’ve not had a single issue with either machine reading my usb sticks

The only issue I’ve ever had was when I discovered that the controller on the swift had been reset somehow after the makers market

2 Likes
19

This is highly dependent upon the design of the system, but, in general, the power isolation tends to be a tougher and more expensive problem than you expect.

The issue is generally how you connect the computer to the controller board to the motors. This doesn’t get solved by getting a better UPS, for example.

Most systems do not isolate the controller board very well from the computer. Unless the communication between those two is either Ethernet (transformer isolated) or CAN (galvanically isolated), you will get ground transients that you simply can’t get rid of.

All this should probably prompt a question to Laguna as to how they deal with USB being garbagey. I’m surprised there isn’t a setting of “Suck the whole USB file into RAM memory before starting to use it.” somewhere in the software.

20

Andrew said:

‘’’
I’m surprised there isn’t a setting of “Suck the whole USB file into RAM memory before starting to use it.” somewhere in the software.
‘’’

There is. That’s what (2) above is referring to (although technically it I suspect it goes into SD as opposed to RAM) – it has a very fiddly UI but it did seem to help a lot. I’m going to the shop today and I’ll document the workflow better for others.

Zack