Spindle orient PID tuning [re-solved, yay]

UPDATE - See the last post in this thread where I throw in the towel

I'm trying to implement spindle orientation for my ATC build.  Need a simple homing function.

I've found about 6 or so 'working' examples dating back to 2010 in the forum and have tried using them as seed-corn to modify my working HAL file.  No joy, however...  too many errors during startup to count.

I think the main problem, aside from my ignorance and inexperience, is that all of the examples are using some configuration fundamentally different than mine - or the comments are in German.  Or both. 

Or the author uses "names=x" instead of "counts=x" which makes it hard for me to read, and even harder to incorporate in to my working HAL file.

Or the author uses the net [signal] [pin] [pin] [pin] line format, which is also extremely hard for me to follow.  I seem to be able to follow:
net [signal1] <= [out-pin]
net [signal1] => [in-pin1]
net [signal1] => [in-pin2]
but not the 'usual' line format.  Dyslexia, perhaps.

Meaning I spend about an hour or so cleaning up each example so it's readable (to me) before realizing there are PWM signals (and no CW/CCW function), or some other scheme which is incompatable with my setup.

Some implementations create two PID functions - one for velocity, one for position - and mux2 between them.  Other configs seem to take a different approach.  And most of the examples seem to be riddled with spelling errors or in-progress comments like "Dont know why this is in here, I'll leave it for now..."

Does anyone have a working HAL file (plus INI if needed) with spindle orientation for a 7i76e & 0-10V command (bog-standard VFD)?

Yes, I know LCNC takes work.  But I haven't internalized the logic and relationships between all the components... so I really need a working config to see/follow before it all clicks.

Or if someone is bored and wants to just fix my files, that'd be sweet;)

Thanks,
Ralph

Progres report:
Found an example and was able to incorporate it in to my working HAL file.  It's based on this thread (thanks):
forum.linuxcnc.org/10-advanced-configura...le-lock-brake#225863

and the orient diagram Andy posted very recently (thanks Andy, I never would have figured out how to get CW/CCW without the abs component)

Spindle starts/stops properly in velocity mode.
G33.1 works fine, so the index signal is present and being seen by LCNC

M19 is also working, but badly.  When I command M19 P0 (or P1/P2), the spindle will oscillate back and forth until it times out.  Looks like the PID tune is way off as the oscillations get larger and larger with each cycle.

The [TUNE] section from the example wasn't so hot for my setup:
P = 6000
I = 300
D = 90
FF0 = 0
FF1 = 0
FF2 = 0
BIAS = 0
DEADBAND = 0
MAX_OUTPUT = 800

Changing these to lower values (or 0) helped, but didn't stop the oscillations.

Anyone have a suggestion for starting PID settings?  All I really need is to have it stop in a repeatable position; I can adjust the offset later in the INI file to line it up with the ATC.

Thanks,
Ralph

Thanks Andy, I was starting to get desparate for some feedback on this.

The VFD is a vector drive (Automation Direct GS-3) with encoder FB to the VFD and Lcnc. Encoder signal split using the Mesa quad splitter.

Motor is a 2-pole (3600rpm) Mitsubishi - belt drive 1:1.

Spindle is controlled open loop by Lcnc and the VFD holds commanded speed quite nicely.  I can go as low as I want on RPM - this thing will chug along at 10rpm if I want.

No problem getting the spindle to move regardless of PID values.  Always does (mostly) the same thing - wags back and forth.  With higher settings it'll move a couple of rotations in each direction, and with lower P and lots of D it will move about 1/2 turn or a bit less in each direction.

I've gone from P=1000 down to P=0.1, and the same for I & D.  Up and down for all three and various combinations:  all P, all I, and all D.

I'm not remotely familiar with halscope, but I did confirm that there is an index signal... However, it doesn't look like a steady blip; looks intermittent and random.  But that could certainly be due to the halscope settings.

My ignorance is monumental: what is inverse deadband?  Would that be DEADBAND=(negative integer)?

Still fiddling with the PID settings; seems like lots of D is making it better, but it never settles.  Acting like it's not actually servoing - there doesn't seem to be any change in the error or pid output whenever the index is triggered.

I'm used to poorly tuned servos reaching a target and then reacting to the target - even if they do it badly.  This thing is just wagging back and forth and sometimes doesn't even rotate enough to reach the index signal.

Does the halscope shot below make any sense?  Is there some setting or hal connection missing?
 

The halshow screenshot was taken after the orient timed out and everything stopped.  Was included mostly to show settings that generated the halscope trace.

(note - I have commented out the [TUNE] sections in the INI and HAL file.  All values are in HAL for now to ease tuning - can just change values in halshow on the fly instead of re-starting LCNC at every change)

I'll plot command/fb/error just as soon as I get home this evening.  Thanks again for the guidance.

-R

Significant progress this afternoon.

It occurred to me that maybe orient was fighting the VFD.  The VFD was programmed with some analog input gain and offset to try to get the commanded spindle speed closer actual speed.  Previously, I was not very successful using PID for velocity control (seemed like the VFD was fighting LCNC), so I just set a command offset in the drive and it was all working pretty well.

Earlier today I thought that the command offset might have been contributing to the issue and it turns out that was the case.  Once I cleared out the analog gain/offset in the VDF the orient PID settings started to have an actual effect.

Now I'm at the point of tuning the PID, but at least it's responding like it's supposed to.  I'll keep fiddling with it for a bit.

-Ralph

Here's the best I've achieved so far.  Orient completes (in tolerance) about 50% of the time within 5 seconds.  Otherwise it fails, either a by a little or a lot.  Giving it more time doesn't seem to help.

I was wrong about the lowest spindle speed...60rpm is as low as it can go at steady state and not get 'clunky.'  The analog offset/gain thing I did to the VFD earlier settled it down, but it didn't turn it in to a brushless servo.

 

So close now.  Orient is nailing it about 8 out of 10 times within 2 seconds when I run a little M3 S1000 G4 P2 M5 M19 testing program.  Seems like once in a while it'll get close (within a couple degrees), stop, then jump and hunt until orient times out and errors.

I've disabled the orient-lock 'spindle brake' function from the example as it was causing the spindle to dither +/- 2-5 degrees once orient-complete was asserted.

Could use some suggestions on:
1. Getting it to be 100% reliable within a resonable time (2 seconds or less)
2. Speeding up the process.  Don't want to wait so long at each tool change.
3. Reducing dither to re-enable the spindle-brake function.  Encoder is a 1024-line (4096ppr) and the dither is more like +/-50 counts.
4. Do the PID settings look insane?  I've read all I can about FF0/1/2, but not sure how or if they'd help here.
5. Something I should be doing different in halscope to help someone analyze the spindle response?

PID settings and halscope attached for anyone who might be following.

-Ralph