Unstable PWM motor control issue

Did you re-scale the PWM for RPS?

Yeah this was the problem, the pwmgen value was being set as RPS, so 25 when I commanded 1500RPM. This wasn't high enough to reach the threshold to make the motor turn. I ended up fixing it by scaling the otuput of the PID up to RPM again. Is there any reason you wouldn't want to do it this way and divide the PWM scale by 60 instead? i thought I might lose speed resolution that way as my scale would then be 0-58 would that mean only ~60RPM resolution over a 3500RPM range? Right now my bottleneck for resolution is the Arduino as the servo library outputs it's PWM for the ESC on a 0-180 scale so ~20RPM resolution.

actually I think it would be an improvement in LinuxCNC for the encoder module to have a RPM velocity pin

Couldn't hurt if it could be easily added alongside the RPS pin, I've read a fair few forum posts on this subject and it seems to be a common mistake for people trying to implement PID. Perhaps because many configs made by newcomers are coming from stepconf which is setting your PWM with an RPM based signal. Arguably, a signal can easily be created for it by using a scale to multiply the encoder.n.velocity by 60. That's not much use when you've not figured out how things work yet though.

Use halshow to work out where the signals are getting confused.

This was a very useful suggestion. I've been using it to check the paraport pins corresponding to my inputs whilst building the machine, but it turns out it's also invaluable for debugging your config. Being able to have a peep at the values of all your signals etc. is pretty handy for getting some empirical evidence of what the changes to your config are actually doing.

So now I have the PID loop connections made successfully. I've had a play around with the tuning as suggested but I'm not happy with the results yet. With FF0 set to 1. I can hit my spindle at speed tolerance across most of the speed range. With Igain set to 0.005 I get it across the full range but there's some undershoot ~20RPM and it takes a while to get up to speed. I played around with P for a bit and around 0.7 seems to be the sweet spot resulting in the least overshoot. It quickly settles to around 20RPM over then gradually drops to approximately the commanded value. Can't seem to get that overshoot any lower and lowering the P seems to make it take longer to settle down. Curiously, with these settings, once a stable speed has been established, transitions in speed become stable within a few seconds, it's just the initial speed from stationary that takes a while to settle (~10-15 seconds). Can D do anything for me here? I notice there's a PID tuning guide here which outlines a different approach to tuning, could it be worth trying this approach?

What should I be expecting regarding how well the PID can respond to control the speed? I'm guessing far better than what I have right now.

There are a couple of things you can do to avoid overshoot

1. Bound the integral error ( With pid.n.maxerrorI )

2. Don't send a step change in RPM to the control loop
( Use limit3 to ramp the spindle speed )

Another option is to not worry about it, 10% spindle speed variations are not likely to
cause any issues if they are not changing faster that the encoder can track.
In fact, deliberate spindle speed modulation is sometimes used to reduce
chattering/resonances.

Well I've tuned things how I like.... for now. Reducing the FF0 a tad helped with the overshoot and with a smidge of D everything settles quickly. It ramps up nicely from 0, no overshoot and finds the correct speed within a couple of seconds. Speed changes, once up to speed, are slightly quicker to settle.

Another option is to not worry about it, 10% spindle speed variations are not likely to
cause any issues if they are not changing faster that the encoder can track.
In fact, deliberate spindle speed modulation is sometimes used to reduce
chattering/resonances.

I've adjusted my spindle at speed to tolerate a slightly larger rpm deviation was set at 1% so if 10 is acceptable I figured I could afford to increase it to keep programs running smoothly. Interesting fact about chatter mitigation via speed modulation. I dread to think how complicated that is to implement, I'll certainly be leaving that can of worms firmly closed. Hopefully I won't have to adjust anything to compensate for chatter aside from my poorly selected feeds and speeds.

The encoder seems to be doing a good job of tracking the speed. I did have to filter the input a bit to get it steady, could this come back to bite me when it comes to thread cutting?

Good point

github.com/LinuxCNC/linuxcnc/commit/50fb...c5ac3bf36642ce7c0247

No messing about there, Andy!