Configuring VFD spindle + encoder + mesa 5i25/7i77

I've been running my bridgeport clone without spindle feedback for a while but I finally figured out a way to connect an encoder so I'm trying to set that up.

I use a 5i25/7i77 to control everything and a Huanyang VFD to drive the spindle.

I have the encoder connected and working correctly (I think). Pin hm2_5i25.0.encoder.03.velocity
appears to show correct units per second. (ie if I set spindle speed to 3000, it reads about 18000)

The VFD is on hm2_5i25.0.7i77.0.1.analogout5

and my spindle is scaled like:
#********************
# Spindle
#********************
[SPINDLE_9]
OUTPUT_SCALE = 5000.0
OUTPUT_MIN_LIMIT = 0
OUTPUT_MAX_LIMIT = 5000.0
ENCODER_SCALE = 4

The rest of my config is here :

I'm stuggling to understand is how to setup the rest of hal to get the closed loop control working.

I've studied linuxcnc.org/docs/html/examples/spindle....pindle_feedback]this at length but so far I'm still foggy.

Why would I only use encoder phase A?

BTW, I really wish someone would do an in-depth, comprehensive and well produced youtube series on hal.

Have you tried running pncconf to create a sample config with spindle feedback?

By default, pncconf creates a closed loop spindle control (with PID component wired to close the loop) but with PID terms set so the actual control is open loop (FF0=1, all other terms 0) This set of PID terms simply copies the input commanded spindle speed to the PID output. To change this to closed loop you add some (non Zero) P and I term.

If your encoder has A and B, then by all means use both, The example using A only is probably intended for a simple slotted wheel encoder/parallel port confg for threading only

I built a fresh config using pncconf. That was probably a useful exercise anyway. My existing config having at least several years of kruft.

Configuring the spindle motor in pncconf, I can launch the 'Open Loop Test' dialog and one revolution of the spindle = 1 on the spindle encoder position. Likewise velocity seems to be correctly reporting RPS += 200RPM as I set.

But when I actually start the spindle in linuxcnc, It starts and then runs away, continuously ramping up until I stop it.

Spindle-vel-fb-rps shows the speed but it just ignores it.

Any advice is, as always, very much appreciated.
New config is here: github.com/sliptonic/alternatemillconfig

sliptonic wrote: I have the encoder connected and working correctly (I think). Pin hm2_5i25.0.encoder.03.velocity
appears to show correct units per second. (ie if I set spindle speed to 3000, it reads about 18000)

That seems to be the wrong way round. 3000rpm is 50 rps.

I think that your ENCODER_SCALE is wrong.

sliptonic wrote: But when I actually start the spindle in linuxcnc, It starts and then runs away, continuously ramping up until I stop it.
Spindle-vel-fb-rps shows the speed but it just ignores it.

Make sure that the spindle pid is using consistent units (rps or rpm) on both command and feedback.
Check if the PID is winding up in the negative direction. It is quite likely that negative PID output gives positive spindle speed, and that is a recipe for a runaway.

The PID uses the signal spindle-vel-fb-rpm-abs for feedback. However, watching this, it never changes. It stays at 0. spindle-vel-fb-rps, however, changes.

So, what drives that spindle-velocity-fb signal?
(Also, it might not be a good idea to use an absolute feedback, what happens in the negative speed area?)

It's linked directly to the encoder
github.com/sliptonic/alternatemillconfig...ndlecontrol.hal#L289

re: absolute feedback:
This config is straight out of pncconf. I'll hand-edit if necessary but in that case, I'm surprised pncconf would generate a bad config.

Completely different signals.

In fact spindle-vel-fb-rpm-abs does not appear anywhere else in the HAL file, so it has no driver.

Here's a (very mild) criticism of this forum: I never know what to do in this situation.

On the one hand, the solution to my problem appears to be hand editing the hal and continuing to test,post,get feedback, etc. That's fine with me and eventually, I'll arrive at a solution because you guys are awesome at providing support.

On the other hand, this particular issue appears to point to a bug in pncconf. It's generating a bogus config. Am I supposed to report that bug? IS it a bug? Is it known? Does anyone care about that?

I don't know what's expected and I feel like I'm letting the community down. After all, I'm not doing anything to prevent the next guy from having the exact same issue and making you guys go through the same support hassle again.

There should be a better way to close the loop on these kinds of issues.