caxis.comp - problems

phillc54 wrote:

I didn't do an exhaustive search on GH, but axis.py was the only file I found with similar max_vel settings based on [AXIS] TYPE.

PNCconf & Stepconf don't include an [AXIS] TYPE line in generated INI files.

Ok, back on track with caxis.comp.  Still struggling, but the speed clamping issue is gone (thanks again Phil).

Spindle commands work fine.

PID tuning is, as usual, driving me nuts.

Right now I've got the values as such:
P = 0.23
I = 0
D = 0.01
FF0 = 0
FF1 = 0.00125
FF2 = 0.00002
FF3 = 0
maxoutput = 0
deadband = 0.1
stepgen max_vel = 100
stepgen max_accel = 2000
[AXIS] / [JOINT] max_vel = 3600
[AXIS] / [JOINT] max_accel = 3600
[DISPLAY] max_angular_vel = 3600
[TRAJ] max_angular_vel = 7200

If the deadband is set lower, it behaves oddly.  A B90 or B179 command works fine and settles quickly.  But a B180 or greater result in the axis reaching position and then after a brief pause it keeps going all the way around and pausing again at B180.  No faulting, but it'll keep repeating that until I stop it.  Strange.

The FF1 value is suggesting (to me) that something is still wrong with various scaling or values.

Haven't really be able to get the f-error better than below without it going unstable.

 
 

Minor addendum...

Any I-term results in unstable, wild moves.  Increasing P or D results in huge f-error increase.

With deadband = 0.1, it'll stay put at B180.  But B270 results in the pause-and-keep-going routine.

If I set deadband to 0.09, it'll sit there for a minute or two and do a single flip.  Then do it again a minute later.

A back and forth program B0-B180 seems to work fine with the above PID values, but B0-B270 causes this:

 

does your drive have a deadband ? can you see if the encoder is giving you a bit twitch in hal show ? what the count value see what it's doing when this occurs. I have seen some issues with twitch. I am still working on a different way to control the c axis, but it's going to take a while.

Encoder counts are stable with no input command.

Encoder is 2500ppr, so 10k post-quad.  That's 27.11 counts per degree.

If pid deadband is degrees (not sure about that), then 0.1 degree should be ~2 counts.

I'll bump it up to 0.2, but that still doesn't explain why it doesn't try to servo back or just dither a bit instead of freaking out and whipping around another rev.

According to the documentation the pid comp has an autotuning feature. I've never used it though:

This component has a built in auto tune mode. It works by setting up a limit cycle to characterize the process. This is called the Relay method and described in the 1984 Automation paper Automatic Tuning of Simple Regulators with Specifications on Phase and Amplitude Margins by Karl Johan Ãström and Tore Hägglund (doi:10.1016/0005-1098(84)90014-1), lup.lub.lu.se/search/ws/files/6340936/8509157.pdf. Using this method, Pgain/Igain/Dgain or Pgain/Igain/FF1 can be determined using the Ziegler-Nichols algorithm. When using FF1 tuning, scaling must be set so that output is in user units per second.During auto tuning, the command input should not change. The limit cycle is setup around the commanded position. No initial tuning values are required to start auto tuning. Only tune-cycles, tune-effort and tune-mode need be set before starting auto tuning. Note that setting tune-mode to true disable the control loop. When auto tuning completes, the tuning parameters will be set, the output set to bias and the controller still be disabled. If running from LinuxCNC, the FERROR setting for the axis being tuned may need to be loosened up, as it must be larger than the limit cycle amplitude in order to avoid a following error.To perform auto tuning, take the following steps. Move the axis to be tuned somewhere near the center of it’s travel. Set tune-cycles (the default value should be fine in most cases) and tune-mode. Set tune-effort to a small value. Set enable to true. Set tune-mode to true. Set tune-start to true. If no oscillation occurs, or the oscillation is too small, slowly increase tune-effort. Set tune-start to true. If no oscillation occurs, or the oscillation is too small, slowly increase tune-effort Auto tuning can be aborted at any time by setting enable or tune-mode to false.  

Can you see the position cmd and position actual in degreees ??? See if anything odf there. Set a hal scope trugger for the index pulse, see if it's got noisy signal ? If index was triggered i could see it dumping the known position and rolling over unexpectedly

@Tommy,
Re-reading the PID manual, deadband should be set slightly greater than 1/2 count to stop hunting.  Your example is (I suspect) referencing a linear axis where you've got a very high count-per-unit (like thousands of counts per mm or inch).  Just like my X/Z axes with 1um encoders where I've got ~25400 counts/inch.

My subspindle is a direct-drive rotary axis where units = degrees.  So I've got ~27 counts per degree; significantly coarser feedback per unit.

The encoder signal is output from the drive, and I've got it set as high a resolution as possible.

@Aciera,
I tried the PID autotune a couple times on my Z-axis a while ago and the results were just dumb.  While I may give it a try, I haven't read a single report on the forum where someone was pleased with the results.

@smc.collins,
I have the pos-cmd and pos-fb up in halshow, but haven't yet scoped them.  Nothing odd or way off during a programmed back-and-forth move.  It homes to index fine and the counts/position/velocity all look like they should even when it flips out.  Doesn't lose track of where it is.


I'm going to try connecting it like an open-loop stepper tonight - connect stepgen pos-fb to pid.b.feedback and joint motor-pos-fb.  That should help me see if my issue is with the PID or not.