Jump to content
OMRON Forums

Cascade Loop Tuning


Brian Kelly
 Share

Recommended Posts

Hello

I had a few questions related to cascade loop tuning. We have a force over position cascade configuration where the force loop values are integrated before input to the inner loop. The system works pretty well but I am always looking to see if it can be improved. In the case when the inner loop receives commanded input from the outer loop only, does the PMAC still compute inner loop velocity and acceleration values? I am wondering if the velocity and acceleration feed forward components of the inner loop still play a role in the response?

 

In terms of operation we run in two scenarios 1) a cascaded axis is programmed to maintain a static value e.g. zero force (in our application this will demand the actuator moves, including direction reversals) and 2) the axis is programmed to follow a trajectory (e.g. ramp or nonlinear) force profile. I had always thought that in scenario 1, good disturbance rejection and hence square wave tuning was most important where as in scenario 2 good tracking response and for example, ramp input tuning, is most important. I was just wondering if that thinking was correct? Should I optimize tuning of the inner loop first according to the task? Just wondering if anyone had any experience or suggestions as to how to tune and optimize performance for each scenario.

Thanks

Link to comment
Share on other sites

  • Replies 4
  • Created
  • Last Reply

Top Posters In This Topic

The feedforward terms for a motor act on the net commanded positions, and so react to the sum of the calculated trajectory and master position from whatever source. So your cascaded command from your force loop will affect the feedforward of the inner position loop.

 

The nice thing about having separate feedback and feedforward terms is that they effectively split the tracking and disturbance rejection functions. (Controls texts call this 2-degree-of-freedom control.) So the feedback terms are responsible for disturbance rejection, and interactive tuning for these typically uses the "step response" square-wave tuning.

 

The feedforward terms are responsible for trajectory tracking. (If you got the feedforward exactly right and there were no disturbances, you wouldn't need feedback!) We find that our "parabolic move" tuning is much better than ramp tuning, because the parabolic move has continuously varying profiles in both velocity and acceleration that allow you to easily see what is causing your tracking errors. Do the step feedback tuning first, and make sure the integrator is off (Ixx34=1) during moves when you are doing the parabolic move tuning for feedforward.

Link to comment
Share on other sites

The feedforward terms for a motor act on the net commanded positions, and so react to the sum of the calculated trajectory and master position from whatever source. So your cascaded command from your force loop will affect the feedforward of the inner position loop.

 

The nice thing about having separate feedback and feedforward terms is that they effectively split the tracking and disturbance rejection functions. (Controls texts call this 2-degree-of-freedom control.) So the feedback terms are responsible for disturbance rejection, and interactive tuning for these typically uses the "step response" square-wave tuning.

 

The feedforward terms are responsible for trajectory tracking. (If you got the feedforward exactly right and there were no disturbances, you wouldn't need feedback!) We find that our "parabolic move" tuning is much better than ramp tuning, because the parabolic move has continuously varying profiles in both velocity and acceleration that allow you to easily see what is causing your tracking errors. Do the step feedback tuning first, and make sure the integrator is off (Ixx34=1) during moves when you are doing the parabolic move tuning for feedforward.

Link to comment
Share on other sites

Curt

Thank you for your response. Overall the feed forward features with this controller are better than what I had used before and I am trying to apply them for best response. Is the preference for not using integral gain during tracking type moves primarily because it introduces lag into the overall response?

 

Also while tuning the outer loop response I was adjusting inner loop parameters as well and inadvertently set the velocity feed forward term to zero, at which point the system immediately became oscillatory. I am curious as why that happened. I understand that every application is different and there are many details not specified so that may be difficult to answer but if anything obvious comes to mind I would appreciate your thoughts.

 

Thanks again. Best

Link to comment
Share on other sites

Brian:

 

I should have been clearer. My preference is to turn off the integrator during the feedforward-tuning moves themselves so you can see the pattern of the tracking errors clearly without the integrator trying to drive them to zero. This allows you to optimize the feedforward gains.

 

BUT, and I forgot to mention this, once you have gotten the feedforward gains well tuned, my preference is to turn the integrator back on during moves to improve the tracking a little more.

 

I view the integrator as the "last line of defense", and think as much as possible should be done before it is used.

 

It's an intereresting report on the feedforward. In a single loop, feedforward does not affect stability, but in the cascaded format it is actually part of the overall feedback loop. Exactly why this happens in your configuration would depend on the dynamics of the system.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...