Problems on the CNCs

Space Teams CNC
41

I would try slowing the Z down to under 50ipm.

There are limiters set in the controllers. As you have figured out, the settings are stored in the controller, and can be changed by anyone. I don’t believe there is a way to lock the settings. They were set to safe speeds previously, but I do believe this is the first I’ve heard of Z speed trouble.

I imagine what might be happening: with the higher Z plunge rate, it could potentially cause the belt to skip a tooth while running. This may not happen all the time, and could be something affected by the specific material being cut. Maybe a hard spot, maybe a bit slip, maybe something else.

I’d slow the speed down and try that. I do appreciate you working through this and reporting back your findings.

Note to all:
One thing to keep in mind. We are a bit of a unique case for most machines. Not very many users put machinery through what a makerspace will. We have multiple users, with multiple projects, all with different specifics for the machines. Something like a jointer, probably handles that fine. Anything with as many user defined variables as a CNC will always see more potential for problems. We aren’t a production shop running the same set of jobs week end and out, and tuning the machine to handle that. Even calling for tech support can be a bit troublesome, as they usually start with “what were you cutting and how?” Keeping the troubleshooting conversation here positive and productive helps us all, and in most cases teaches us more about the machines.

2 Likes
42

I have replacement collets I’ll deliver tomorrow. Ive noticed quite a few missing lately.

43

James, that’s a great next test. Will try next week and will follow up.

Thanks everyone for all the help and ideas! I sure do appreciate it!

Cheers,
Zack

1 Like
44

Fix your G-code. Depending upon the quality of the G-code parser, you may have Z882 moves followed by a Z0.1ish move. “;” comments in the middle of a command are not standardized.

See: line 282 for example.

The fact that I caught this using the first G-code viewer I popped up (https://ncviewer.com/) strongly suggests that you should NOT be writing your own G-code. Please stop.

Write a plugin for Fusion 360 in Python or a Gadget for VCarve as they will generate correct G-Code.

45

You can lookup RichAuto A11 or RichAuto A1X (refers to the A1 family of controllers) on youtube, and hunt down the manuals. It’s a common, off the shelf controller. Very little of the setup is specific to the Laguna machine, so there a lot of videos on how to use it, both on Laguna and other machines. You can also find docs about the specific gcode for RichAutos if you’re generating your own. Actually the format over the wire between the pendant and the controller board is just PWM, it’s not even serial. It sends PWM pulses out, and the driver board is just there for isolation & amplification. All the logic & processing is done in the pendant.

I also feel for ya. I liked the old machine more myself. The Laguna is better for people that are strictly following the ordinary use case. However, I don’t think the Lagunas are as good for people that are leaving the basic use case. I understand why the hackerspace doesn’t want to modify the machines during the warranty, so I ended up buying an old cnc router and converting it to LinuxCNC.

Re the Z-slippage… How thick of material are you working with? Is it possible it slipped while plunging, and that caused it to get off? Lower Z feed rates would probably help this problem. Endmills are generally better at cutting on their sides then they are at plunging, so IIRC your Z feed rate should be much lower then your X/Y feed rate.

46

@zackg I’m glad to hear you bought your own machine and set it up the way you prefer.

I disagree with your assesment of the Laguna’s, and don’t feel the need to have sympathy for anyone using them. They are a valuable resource for the membership at large, and with their purchase we doubled the availability of machines.

Every machine to come through the doors has and will have problems. This post has been a fairly good example of members helping each other troubleshoot problems. There is no reason to “feel” for any of us.

2 Likes
47

No need to be so defensive. As I said, it’s excellent for the basic use case, which is what 98% of the people at the shop are doing, which is excellent for the membership at large. But for a handful of users, it doesn’t support their needed cases… and he’s trying to design a g-code generator. That’s not a normal use case at the shop. So, why is it so wrong to feel for him in this situation?

And I did my best to add my bit to help out, and pointing out the exact model is probably useful if he’s trying to find the manual for gcode generation, along with details of how the machine works.

1 Like
48

@zackg, thank you for the model reference on the RichAuto. I have downloaded the manual and have found it quite interesting to see where the boundary is between the controller processing and the motor controllers. Plus there’s several features that I didn’t know about.

@jamesfreeman – thank you also for all the thoughtful help. My plan is to slow down all the Z operations dramatically as you suggested and see what happens. Also thank you for the suggestions that resolved all the other bullet points.

I very much appreciate all the help here and I’m fully aware that my use case is highly unusual. For what its worth I feel very lucky to have access to this equipment here in Austin and it has helped me immensely with my project. Thanks again!

Zack

3 Likes
49

I have made some progress on sorting out this Z gremlin.

I took @jamesfreeman 's advice and tried slowing down the plunge speed, that did not help.

But, I watched it like a hawk and, as @dannym predicted, the failures happen on the up-stroke which makes good sense given the physics as he described.

I can hear the failures happening: there’s a momentary kind of zip or grind sound that is distinctive. I assume this is a belt or gear slipping.

The upstrokes in my cuts were G0 (rapid movement, unspecified feed rate) and so I changed them to G1 (linear move) with a specified feed rate of 30 in / minute and that got me through several of my elaborate cuts which I was very happy with!

But being the anal-retentive engineer that I am, I couldn’t leave it there. So, I wrote a stress-test I call “Z stage push ups” which is: “G0 up and G0 down 0.25 inches repeated 50 times with an occasional move along X back and forth” and I reproduced the problem several times even in is very simple setup.

My test is: I put a small piece of wood on the stage and Z set to the top and then move it a few inches to the side. Then my code runs G0 up to 0.25 inches and G0 back down to 0.0 over and over 50 times and then moves horizontally back over to the block and back away from it and repeat. If there’s a Z slip at some point, the stage will move back over and BUMP the block from the side instead of just missing the top of it as usual.

Video of test passing

So I ran four extended tests like that:

  1. No failures in 20 minutes

(Changed test to go to G0 0.25 instead of 0.5 as in test 1).

  1. Failed in 10 minutes.
    Video after failure
    After this failure I manually moved the z stage back to the top of the block and as you can see in this picture instead of the correct Z reading 0, it reads 3mm.

  2. Failed in 1.5 minutes
    This time Z stage was off by 2.5mm.

  3. No failure in 30 minutes.

As you can see, it is infuriatingly inconsistent but I did reproduce it twice in the simplest possible g code imaginable.

So, for now, I’m back to being productive in that I’ve managed to make progress by reducing the speed of the Z retract to 30in/min – but to be fair I’m not actually confident yet that this has fixed anything as my successful sample size is small (2) and thus I have not actually proven that slower = better (I might just have gotten lucky).

Regardless of my work around, I have proven beyond a shadow of a doubt that there’s a real problem that is rare but extremely frustrating when it destroys a cut (or worse) after 20+ minutes.

Zack

50

You may be able to specify the F argument to limit the z-rapid speed. Look at some of the generated gcode from vcarve to see if it passes in a F value into one of the Z motions.

52

A stepper stall often makes a grinding sound, but it’s purely magnetic cogging, there’s nothing grinding.

Close! What you need to do is look up the Z axis’ programmed max speed, and use that, AND use enough travel room to accelerate to that speed. 0.25" isn’t going to be enough.

Steppers have the max torque capability roll off as RPM increases. The controller has a fixed acceleration in its setup, this will be the same regardless of distance or velocity. When you try the same accel (or decel) at higher velocity, that’s the first place you’d find the torque load exceeding the motor’s torque capability, i.e. a stall.

A stall at-speed does not indicate a problem with a motor or driver. It’s binding- linear guides or leadscrew. Both run on circuits of ball bearings with no inner race- they roll directly over the rail surfaces that you see gathering a lot of dust. They have swipers on the ends of the truck/nut, but they’re not perfect. Dust contamination will jam the bearings even with ample oil present.

53

That’s all very interesting @dannym.

FWIW, of course I chose G0 for both my work and my tests because it leaves the speed parameter up to the machine. I was/am assuming that the machine is supposed to be calibrated to know what its own “rapid” movement should be.

54

My bad, you’re right, speed will be maxed out by G0. But it does need enough runway to reach max speed and come to a stop again- so, more than 0.25".

55

What lubrication schedule are we using for these?

56

I notices the 1/4 collet and collet nut were both dirty and had chips in the threads and the slits in the collet. I used a straight pin from the sewing room to cleans them out and they worked like new. The collet was really bad so I could see why its clamping ability was compromised.

57

I think Zack Simpson sent something out on this - but just to clarify his findings… His gcode was asking the machine to raise the z clearing height at the max speed the machine would allow, assuming (rightly, I think) that the machine knew its own limits and wouldn’t rise so fast that it compromised its own stability. He discovered that he can reliably reproduce the z drift problem by doing that, over and over. So he decided to change his gcode to specify a slower z height rise and the problem has gone away for him.

Obviously - I might have misunderstood and he can correct me, but that’s what I walked away with. I use Fusion and use the Amana factory speeds for everything - and am not having problems.

58

Doug has this exactly correct.

Since I guess this thread is still alive I’ll summarize from the first posting.

(1) I’ve learned to slow down the manual movements on the controller. That reduced a lot of frustrations.

(2) & (3) Switched to using internal memory and a dedicated personal USB drive. A major improvement. See discussion about the UI workflow.

(4) I was using G0 to move the Z stage upwards. I built a stress test (see the videos mentioned in the thread) and determined that indeed a simple up and down motion at full speed (G0) would eventually and randomly cause the Z drive to “skip a tooth” (or a belt slip or whatever, I don’t know the mechanism). I changed my code to use only G1 commands and I specify a slow feed rate on the up stroke. Since then I haven’t had the issue but I can’t say with 100% confidence that I’ve vanquished the problem, but I certainly have reduced it.

(5) There was talk of getting a longer cable for the z puck on the large CNC. I don’t know if that happened as I’ve returned to exclusively using the small CNC.

Cheers everyone!
Zack S

2 Likes