Feedforward control algorithm help

[kamenges]

Originally posted by Peter Nachtwey:

You must remember that it is easy to calculate derivatives just by differentiating the position polynomial as many time as is necessary.

In many of the systems I deal with I only have what I have. That usually means I can get at the position and velocity references pretty easily. I'm pretty lucky if I can get at the accleration reference. I don't have a chance to get at jerk. If I want the acceleration reference I need to do a per scan difference to get it. If I can time that to the profile generator I'm probably OK. If not it will get real noisy. In those cases I'll use what I have available and see where it gets me. Just because I can't implement everything doesn't mean I should implement nothing.

Originally posted by Peter Nachtwey:

You must remember that the Command or serial feed forward is for the whole closed loop transfer function.

So you were referring to the command feed forward example, not the parallel feed forward example. In the parallel feed forward example the plant is only really concerned about the second order feed forward. There is no third order gain. However, I suppose the command should still be fourth order to avoid exciting the closed loop pole just due to the command.

Keith

 

[Peter Nachtwey]

Just because I can't implement everything doesn't mean I should implement nothing.

That is very right. Everything you do helps.

So you were referring to the command feed forward example, not the parallel feed forward example. In the parallel feed forward example the plant is only really concerned about the second order feed forward. There is no third order gain. However, I suppose the command should still be fourth order to avoid exciting the closed loop pole just due to the command.

Some motion controller are limited to a series of 3rd order motion

See
http://www.20sim.com/webhelp4/Toolboxes/mechatronics/Motion_Profile_Wizard/MotionProfiles.htm
http://www.dct.tue.nl/New/Lambrechts/ACC_2004.pdf
http://www.motionsystemdesign.com/Issue/Article/45369/Mastering_motion_profiles.aspx
This will keep you our of trouble for a while
The really good stuff isn't published.

There would be a quiz but surferb objects.

 

[kamenges]

This will keep you our of trouble for a while

My wife says thanks.

 

[Pandiani]

Keith, why you are using terms "serial" and "parallel" feedforward?

I used that term because Peter did in his .pdf file (*RMC.pdf). My example shows the same structure as Peter's. Do you mean to some specific examples? Somehow I missed that.

 

[kamenges]

Pandiani-

On the top of page 2 of the PDF you posted you show a block diagram that shows the feed forward signal as an input to the PID controller. While this can be mathematically manipulated to be the same system as Peter shows in his posts it is not technically the same structure. It's kind of like the incremental (velocity) and absolute (position) forms of the PID filter. They can be shown to be mathematically equivalent but that doesn't necessarily mean they act the same in all cases.

For lack of better terms I referred to the form you show on the top of page 2 of your PDF as a serial form and the form Peter shows (or your modified form) as a parallel form. In the serial case the feed froward goes through the controller. In the parallel form the feed forward goes around the controller.

Peter, in the article you linked to by Paul Lambrecht he is using a 4^th order trajectory generator and all the feed forward gains to drive a 4^th order system. I would think he would want at least a 5^th order profile to do this to prevent the step output fron the 4^th order gain.

Keith

 

[Peter Nachtwey]

Pandiani-

On the top of page 2 of the PDF you posted you show a block diagram that shows the feed forward signal as an input to the PID controller. While this can be mathematically manipulated to be the same system as Peter shows in his posts it is not technically the same structure.

It is obviously a different structure. Both methods have their advantages and disadvantages but under normal circumstances they are still the same.

Here is an example where they are not. Say the axis must follow a sine wave motion profile. The command feed forwards method exaggerates the target position but what if the exaggerated target is outside the limits? Under some error condition could the axes go outside the limits and try to reach the exaggerated target position?

An advantage of the command feed forward is that the PID, or better yet, I-PD will work for all cases. If the command feed forward part is left out the I-PD will convert the closed loop transfer function into a n pole low pass filter. This is very good when using an analog input instead of a target generator to generate target positions.

It's kind of like the incremental (velocity) and absolute (position) forms of the PID filter. They can be shown to be mathematically equivalent but that doesn't necessarily mean they act the same in all cases.

Yes, they have different advantages and disadvantages otherwise why bother?

For lack of better terms I referred to the form you show on the top of page 2 of your PDF as a serial form and the form Peter shows (or your modified form) as a parallel form. In the serial case the feed froward goes through the controller. In the parallel form the feed forward goes around the controller.

I like the term serial and parallel form.

Peter, in the article you linked to by Paul Lambrecht he is using a 4^th order trajectory generator and all the feed forward gains to drive a 4^th order system. I would think he would want at least a 5^th order profile to do this to prevent the step output from the 4^th order gain.

I don't see where I would consider a 4th order. Right know we use 5th order but I would prefer to use 7th order and do what norm showed a few weeks ago. 7th order motion takes more processing power but simplifies matching the derivatives at the end points. The problem with using anything but a third order is that it is hard to limit the accelerations and jerks at all places along the motion profile. Finding roots to find maximums and minimums is very CPU intensive.

The hardest part of making a motion controller is the point to point motion profile. This doesn't seem intuitive. Anybody that tells you otherwise has not considered all the possibilities. Some of the problems would make pretty good Friday Night Math quizzes

 

[kamenges]

Originally posted by Peter Nachtwey:

The hardest part of making a motion controller is the point to point motion profile. This doesn't seem intuitive.

That is very true. In an interesting twist this perception is largey due to 'you guys' (high performance motion control suppliers). You have made it so easy for users to define what they want while abstracting them from the complexities that coming up with a motion profile seems easy. You have given them a methodology to 'model' their motion and the controller or development software takes it from there.

Compare that to control loop tuning. If the tools needed to perform system modeling were as intuitive and easy to use as the tools used for motion profile definition users would think that loop tuning was a no brainer also.

Keith

 

[Peter Nachtwey]

Sometimes it seems the mechanical guys are out to get you.

Compare that to control loop tuning. If the tools needed to perform system modeling were as intuitive and easy to use as the tools used for motion profile definition users would think that loop tuning was a no brainer also.

Loop tuning is easier by a long shot. You haven't seen how we do it. If we have information about what is being controlled then we can tune it as long as it doesn't have too many poles or is too non-linear. The only thing that makes tuning difficult is the ignorant mechanical engineers. We have total control over the motion profiles.

[OT rant]
BTW, last Wednesday one of our engineers told us of a problem system where he went out into the field. The customer was try to control a California Linear Devices linear cylinder. These are fast and work extremely well when used as intended. Our engineer tuned the system so it could accelerate up to a linear speed of 120 inches per second in back to 0 in 125 milliseconds. The customer wanted 100 milliseconds. The problem was that the linear motion push an arm that turned a shaft and the shaft was long and at the end of the shaft was another arm or rack and pinion that really did the work. The shaft itself flexed a lot when excited at those speeds and accelerations. This system had to have at least one pole for the motor and probably two. The long shaft added another two. The integrator added one. To move without overshooting requires a critically damped or over damped closed loop transfer function. The customer still wanted to control this with a RMC100 which only has PID gains and a velocity and acceleration feed forward. The customer also wanted NO OVERSHOOT. The RMC100 is fairly typical of todays motion controllers. Replacing a RMC100 with a M02AE wouldn't help. The M02AE or most other controller have the same gains and limitations. You can see that this system has WAY to many poles for the RMC100 OR M02AE to be able to properly place. So who's fault is this? Personally, I think it is the mechanical design that is at fault. These mechanical engineers think designing a machine is just kludging together a bunch of metal without regard as to how how it was going to be controlled. Adding the twisting shaft is the error. The poor person doing the control was having a very difficult time. Because he didn't know control theory and he didn't realize his job was impossible. The CLD linear motor should be used as it was intended to be used. The load should be directly coupled to the linear motor. The RMC100 does a fine job controlling these CLD linear motors in current or torque mode. I know Pandiani and Keith would NOT make this kind of mistake nor would they they try to do the impossible. They would not need a Delta engineer to tell them they are being screwed by an ignorant mechanical engineer.

BTW, the shaft would oscillate at about 50Hz. Also, the system was tested with a load attached directly to the linear cylinder before it was installed in the field. Everything worked fine.

I think we should apply the match penalty to designs with excessive poles too. One match for every pole over two. I know I sound like a hard *** to you guys but we see so many mistakes and the wrong person or thing gets blamed.
[/rant]

I brought this up because Keith said tuning should be a no brainer and that in a previous thread that he wouldn't have considered the flexing shaft.

 

[surferb]

I don't object - I was just suggesting (prior to relevant discussion) that the next Friday math quiz be on a different topic than motion control, which can be defered to another Friday. Or are you referring to my suggestion (in obvious jest) that you run 2 Friday math quizzes since you're company just opened a new forum?

That is very right. Everything you do helps.

Some motion controller are limited to a series of 3rd order motion

See
http://www.20sim.com/webhelp4/Toolboxes/mechatronics/Motion_Profile_Wizard/MotionProfiles.htm
http://www.dct.tue.nl/New/Lambrechts/ACC_2004.pdf
http://www.motionsystemdesign.com/Issue/Article/45369/Mastering_motion_profiles.aspx
This will keep you our of trouble for a while
The really good stuff isn't published.

There would be a quiz but surferb objects.

 

[Peter Nachtwey]

Ot

I don't object

I was just seeing if you are paying attention.
What do you want the topic to be? The only thing I could think of that would be related to what you do would be indexing, sorting, and hashing algorithms. Hashing algorithms would be a good topic. I don't think it has been covered before.