Retrofit of Precix 5x10 CNC

Awesome, thanks Todd, ya, probably didn't fix that from when I was first setting it up.

It's definitely an encoder problem. With LinuxCNC open and drives not powered, if I manually push the Y axis I can see the DRO change. Same on Z, but not on X, so I am guessing my X encoder lost connection mid run. I am going through trying to check connections now.

Yes, much smaller following error limits should be used so even a small commanded
move will result in a following error if the encoder position does not "follow" the move,
this would likely have prevented your runaways

Do you think it may be an encoder cable seperating as it bends through the flexible raceway...have a look at my username.

Thanks PCW!

I will get those changed, but if the cable lost connection, then would anything have prevented that?

Thanks!

Got your email too, and I will see about getting some spare parts.
With my broken belt, the guy I got the CNC had a spare so I was able to get up and running.

That older servo concerns me, might have to look at getting a replacement. Might be nice to have one on the shelf...

Thanks,
Randy

A non-working encoder in a velocity mode servo can lead to
a runaway situation but typically only slow runaway (drift)

With lost feedback a static axis could drift without the controller noticing
but this would only be at a quite low speed. As soon as the controller
commanded a motion larger than the following error, the loss of encoder
feedback or erroneous feedback should cause an immediate following error
and disable the drives.

If a motion smaller than the following error limit was commanded, you will get
a slow runway with a maximum velocity proportional to the PIDs P term
times the commanded motion.

(this will typically be quite a low velocity with reasonable ferror limits)

This is why it is so important to have reasonable ferror limits...

Thanks for clarifying that PCW, I will get those fixed!

Hey guys, Had several incidents of an out of control X axis. Twice during homing the X axis ran much faster than my normal homing speed and before I could kill it slammed into stops. Once breaking a tool holder in my ATC. Each time I thought I had it figured out...

Once as I left the machine powered but wasn't doing anything on it for about an hour (had a visitor) and as we talked it just kicked on and went to the + side limit of X. Not just creeping but about 20in/min or faster.

Each time I checked my encoder to make sure it was reporting the values, however this last time I have no X axis encoder response.

So at first I thought I had this figured out because there was a bad looking connection to the X axis encoder and I changed that. It appears that wasn't the problem. It was difficult to figure out, because it would behave for a couple weeks without any issues.

Anyone have any suggestions on debugging? This motor on my X isnt like the other ones, it appears older. So maybe the Y and Z have been replaced. I am going to look to see if I can find an affordable replacement motor similar to the Y.

I included my HAL file and I did update the ferror values as you suggested, do you think the tuning appears to be accurate?

Thanks again for all your help!

 

As far as tuning goes, that is checked with halscope

From your existing tuning, it looks like you are using torque mode drives
Its a bit harder to prevent runaway with torque mode drives on encoder failure
but its still possible by monitoring the PID output

Have you looked inside the encoder for possible loose connections, or other problems?