Rotary table configuration

I'm going to call this progress. All three of the monitored velocity parameters now mostly mirror each other. The one thing I had to change, which I don't understand, is the POS_MAX_OUTPUT. This was set to 15 in your file, so I copied that. Then I noticed that my velocity was being capped at 15, so I tried changing it to the same as my current MAX_VELOCITY, 110. That did the trick, but why does the POS parameter control the VEL? I also reduced the POS_P by a lot and this seems to have helped.

Ah, much nicer now. It moves at the max velocity, from my calculations based on motor RPM and gear reduction, and the velocity curves all match. Considering this is a rotary axis where units are in degrees and velocity in degrees/min (I think), how concerned should I be about the error seen in the screen shot? P-P is about 5 units, or an instantaneous variation of up to 5 degrees/min while cruising. Again, if I'm reading everything correctly here. I was able to center it around 0 using FF0 but couldn't figure out how to reduce the amplitude.

** EDIT: Above should ready degrees/SECOND not minute. Velocity is in machine units per second... which has bitten me more than once now.

I have to agree, this does seem a heck of a lot easier to get visibly smooth motion than trying to tune with only a position loop. I haven't done anything with position yet, but the stops and starts are very crisp and the cruise is smooth by human observation standards. I've also been pushing the acceleration and it seems quite happy with 3000. Maybe I'll find out this is an issue later and have to reduce it but for now I'm pretty happy with how this is going. One complete rotation takes just over 3 seconds.

I think I found that FF0, FF1, and FF2 only created instability in the Velocity loop. Might want to try with those set to 0.

As to your question above about what the POS_MAX_OUTPUT should be. It should = to the max velocity for the joint because the output of the position PID loop is the velocity command, therefore it would only make sense that it should be the same as the joints max vel.

Next you'll want to add a little D to the velocity loop to try to smooth out the noise in the velocity error

Here's where things stand as of bed time tonight.

I've made an attempt at proceeding to tune the position loop, but this seems a bit more difficult. Maybe I didn't get the velocity loop right? Sure looked good. I'm having two issues with the position loop: a) The actual position isn't reached, unless I turn up POS_P fairly high, and b) when POS_P is high it seems to cause the high frequency noise that's seen in the screen shot. Or perhaps this is coming from somewhere else. Not sure, but leaving it for tonight.

Oh, alright... one more before my eyes close on their own. I took your suggestion of removing the FFx from the velocity loop and tried (without much luck) to reduce the noise in the error with D. It seems like it's working better now when I start increasing P in the position loop. But really I'm mostly just using trial and error at this point. Need sleep.

Have you tried to reduce the vel_P a little? Try 0.5
You can take the position loop completely out of the equation (just for tuning the velocity loop) by temporarily connecting the axis.3.join-vel-cmd directly to the velocity pid command input.
(guessing at your pin and signal names for your hal file somthing like this)
at a hal command prompt type
unlinkp pid.a_pos_output
net a-vel-output axis.3.joint-vel-cmd
It also can be helpful to look at the output of the velocity loop pid in hal scope to see if it is maxing out.

Also here is a link to the thread that first inspired me to try a 2 loop set up. His configuration is much more complicated than mine (he's using gain scheduling and multiple encoder feedback).
forum.linuxcnc.org/forum/10-advanced-con...eduling?limitstart=0
It is a very informative read. (and the people involved know a lot more about what their talking about than I.)

Definitely interesting reading, but I'm not sure I'm quite there yet. Still crawling here, not yet walking.

I added the suggested debug lines to the end of my HAL file because I couldn't for the life of me figure out how to start a HAL command prompt while LinuxCNC was already running. I didn't get any errors and the positioning lost any semblance of accuracy, so I'm assuming it took.

Unfortunately I'm finding that the VEL_D I added earlier doesn't do much of anything. See next two screen shots...





Increasing VEL_D much more than I had it set causes bad things to happen...



So, let's forget about VEL_D for now and try adjusting VEL_P up and down...

Halving VEL_P results in roughly doubling pid.a_vel.error, and no improvement in the noise superimposed on the signal:



Doubling VEL_P results in .... ahem .... ya. Clearly not the direction I need to be going.



Some thoughts on where else this noise could be originating from, but not sure how to rule out:
- Power supply not supplying enough current/voltage
- High frequency noise from my mess of test wiring
- BASE_PERIOD (200000), SERVO_PERIOD(1000000) too high? Computer is a bit older but was more than respectable in its day.
- Velocity of motion used for testing too high? What percentage of MAX_VELOCITY should I be using for tuning?
- Noise is normal. There was something from PCW (perhaps from the link you sent) about velocity loops typically having a quantity of noise due to the relatively low resolution encoder.

All of this said, the parameters as of last night's final post actually work pretty good. There's no noticeable jitter in the motion, starts/stops are crisp, and there's no "hum" or "buzz" that I can detect. Am I perhaps trying to get more out of this system than it can give, or am I just not tuning things properly yet?

If what you had before was looking good enough for you then run with it.
As far as how fast to test at I don't know, I would think that somewhere in the range of speed you'd expect to use most. Most of the tuning instructions for drive tuning I've looked at only use a relatively small move at a moderately slow speed, but with a square wave input, and you are trying to get the move to match as closely as possible to the command.

One more thing that might be informative to look at is what does the output to the amp look like?
pid.a_vel.output
Just to make sure your not saturating your torque command or bouncing off the hi low (+/-10v) limits.