Spindle orient PID tuning [re-solved, yay]

While not back to square 1, orient is starting to aggravate me.

It's not repeatable.  I can run an M19 orient command four times in a row, and it doesn't respond the same way twice.  I set up a halscope to see if that helped make sense of what's happening.. but it isn't helping me understand the seemingly random responses.

I've got a simple little program to run the spindle for a couple seconds, stop it, then orient.  I'm giving it 3 seconds to orient before it throws an error.

Multiple tests with the same lincurve & deadband values result in wildly different results.  It usually orients the first or second time if I tweak an input value, but after that it's hopeless.  Or it will fail four times in a row... then it nails the orient in less than a second.

Adding a little (relatively) I-term seems to have helped, but it's not what I'd call reliable.

Multiple screen captures attached - all are with the same settings.  First one nailed it, remainder failed.
 

My take on this is discard lincurve and fix the orient component so it outputs
a followable motion command (add orient velocity and acceleration constraints)
That way the PID heavy lifting will be done by FF1 like a standard velocity mode
servo. Step command inputs and integral terms don't get along very well

PCW - thanks for giving this some thought.

I'm happy to trial a different config, but I'm at a loss regarding "add orient velocity and acceleration constraints"

I posted a non-lincurve setup earlier in this thread that was kind-of working(ish).  Do you have an example of a 'standard' orient config with some suggested values?

Pretty much need my hand held through this one.
 

I think the main issue using a PID to control a VFD for position control
is that the VFD is quite slow to react so feedback control is difficult,

Control should be improved with feed-forward (specifically FF1 =1 since the VFD
should have a linear and predictable speed vs command relation)
but effective feed-forward requires a actual motion profile not just a step in position

A limit2 component after the orient component would constrain the velocity and acceleration. but would likely need to be bypassed when not doing the final orient move (The limit 2 component would do the move from the random
start position to the orient position)

PCW wrote:

I think the main issue using a PID to control a VFD for position control
is that the VFD is quite slow to react so feedback control is difficult,

Control should be improved with feed-forward (specifically FF1 =1 since the VFD
should have a linear and predictable speed vs command relation)
but effective feed-forward requires a actual motion profile not just a step in position

A limit2 component after the orient component would constrain the velocity and acceleration. but would likely need to be bypassed when not doing the final orient move (The limit 2 component would do the move from the random
start position to the orient position)
 

I understand the first part.

Don't understand your second part.  I have yet to wrap my brain around feed forward, despite reading multiple explanations.

And limit2 goes between orient.0.command and pid.o.command, or between pid.o.output and mux2.0.in? (mux is used for spindle or orient)

I'm reading the MAN page on limit2, but I don't really get the limit2.N.load pin.  Is that a 'bypass' switch of sorts?

How do I bypass the limit2 after the move from random start?

Suggestions on limit2.N.min, .max, and .maxv?

yes,
limit2.N.load
is a bypass / function ignore "pass through" pin

I am not sure when (what criteria) would toggle this

maybe a near component (it will stop the wiggle)

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

(following this with some interest but no knowledge .... so take the above regarding the "near" as maybe wrong!)