Lagunmatic 3516-SX Retrofit

Thank you Peter!

I had to take a break from trying to figure out the spindle/ATC and just cut something today. I've had this machine now for 2 years and haven't made any computer-controlled cuts and it's been eating away at me.

The cuts aren't great - I need to relevel the machine, tighten the X-axis gibs, and spend more time tuning the servos. Feeds/speeds were back of the envelope and clearly too much for the little 3/16" HSS tool in the pocket :laugh:

But to me, today, this is a trophy. Really appreciate everybody's help and I'm feeling motivated - leaving for IMTS tomorrow and can't wait to get back to the machine next weekend.

Re-tuned XYZ axes and am pretty happy with where they are now. Still believe the X gibs needs to be tightened because I hear a thud when changing directions from X+ to X- (tightening the gibs moves it in the X+ direction).

Thinking about the spindle position PID - is it possible that running my VFD in vector mode is causing trouble with the Linux control loop?

When I was running the part in the last post I heard some variation in my spindle speed so I need to look into the VFD parameters there as well.

The main issue I am facing with the spindle position PID right now is that the spindle gets relatively close, usually overshooting, and the the output velocity becomes to small to register movement at the spindle.

With the PID values below, which seem odd, I can reliably orient the spindle but it will sometimes take 10+ seconds because as the commanded velocity creeps up to ~70RPM which is about the minimum for my spindle to move.

So the PID works in theory, but the responsiveness is abysmal.

giz wrote: commanded velocity creeps up to ~70RPM which is about the minimum for my spindle to move.
So the PID works in theory, but the responsiveness is abysmal.

You could look at using the inverse-deadband component, but lincurve might be more adaptable.

A transfer curve where 0 = 0, 1rpm = 70 rpm and 100rpm = 100 rpm, for example, would help a lot with responsiveness without I-gain windup getting out of hand before the spindle starts to move.

So, X = -100, 1, 0, 1 100 and Y = -100, -70, 0, 70, 100 as a first attempt:

linuxcnc.org/docs/devel/html/man/man9/lincurve.9.html

(I wrote lincurve after seeing exactly this sort of problem solved many times with a lookup table in my day job)

Thanks Andy - this does seem to help but man, tuning this spindle seems near impossible.

I have a pretty good handle on halscope now and I have been using it to plot spindle command, feedback, and error (and adjusting PID values based on my observations). It's been extremely difficult to get a PID response that does not oscillate forever. I've found some numbers that seem to work but take quite awhile to converge:

P= 0.125
I= 0.3
0.003

I know these are arbitrary but you can see I have lowered them drastically since implemented lincurve.

I'm at the point now where I'm starting to wonder if braking with the VFD or a mechanical brake is the only way I'll be able to get fast response out of this. Seems bizarre this hasn't been handled already in the past????

I think you might be seeing I-term windup if it oscillates. Does it still oscillate with an I-term of zero?