Motion Madness

[jstolaruk]

jstolaruk, that "blended" move looks very poor. One can see the ripple which will induce vibrations.

If you say so; I'll certainly yield to your expertise. That product has been adequate for the applications that I used it in (cam profile).

Eric, jstolaruk what is your definition of blended moves? Certainly it must be more than smoothing the splice between to motion segments. Can one of you give an example? If I were home I could post a link to my definition of blended moves but that will have to wait until Monday night.

I guess I don't have a particular one. Servo drives are usually just a sub-system of the machine. Generally the customer specs the manufacturer and if they don't then I use the mfg that will provide the most support. I try not dwell on any particular area because we're trying to be ontime with the startup and delivery (which has been getting shorter and shorter these last ten years).

I do appreciate your knowledge in this area. Please keep the informative posts coming.

 

[Eric Nelson]

Eric, jstolaruk what is your definition of blended moves? Certainly it must be more than smoothing the splice between to motion segments. Can one of you give an example?

My take is that a blended move is just a change to a motion already in progress. A blended move allows you to change speed (and the accel/decel used to get to the new speed), and/or modify the end position of the currently executing move. Ormec's definition is on THIS page, and there's a graph at the bottom of the 'more info' link I gave in my last post.



-Eric

 

[Peter Nachtwey]

There is a problem with definitions.

The different motion controller OEM's have different definitions. I don't see what is being 'blended' by Ormec's definition.
By Ormec's definition we have been doing blended moves with our firt generation controllers since 1986.

 

[kamenges]

Originally posted by Peter Nachtwey:

The different motion controller OEM's have different definitions.

I should say. The only place I have come across the specific term 'blended move' was with Delta Tau PMAC motion controllers. There blended move will simply stick two linear moves together at the transition point between constant velocity and accel/decel. So you needed to command the next move before the previous move started to decel. This is if you were using linear mode blended moves. If you were specifying PVT (position-velocity-time) moves you had more flexibility as the controller just solved for the third order position path that would get you from where you are to where you want to be.

I think of superimposed moves as a separate thing. I just look at them as the addition of two different position profiles running concurrently. I wouldn't consider that a form of blending.

Peter, I've never considered feedforward items in terms of plant poles. I've always looked at them as a solution to specific physical phenomena. For example, velocity feedforward can account for viscous friction, accel feed forward accounts for mass acceleration effects, etc. As you increase the order of your feedforward commands it seems you run out of physical effects to counteract and you are completely in the frequency arena. You are adding feedforward poles to address a pole or zero present in the plant. But how does that actually help? By definition feed forwrd commands are only present during a move. Aren't the plant poles you are addressing with the feedforwards present and ready to cause stability issues when you are just sitting still also?
Keith

 

[Peter Nachtwey]

But what you are really seeing is an energy transfer rate.

I thought you understood when you made this statement. The power to mass ratio will help until the 'spring' becomes non-linear or peak power has been reached. The 'spring' will absorb energy which must be compensated for by the feed forwards but eventually real limits exist I will try to make a Mathcad .pdf to show what I mean.

Check this link out. See the last example with the fast step change in position or SP. It is an example of how ideally one can control something just about any way you want IN THEORY. Just increase the gains.
http://www.engin.umich.edu/group/ctm/PID/PID.html
What this example doesn't show is that the control and plant are not ONE equation as shown. In reality, the motion controller only outputs +/- 10 volts and the drives have only so much power. This is the practical limit.

 

[kamenges]

I understand the need for at least a 3rd order position path. This allows you to define the energy transfer rate in the system. I can even see the use of a 4th or 5th order position path, especially if you have multiple spring rates that come into effect successively. What I don't quite understand is the feed forwards based on anything greater than the 2nd order quantity. This is the term that really controls the energy transfer. While the higher orders define that rate of transfer what is the merit of feed forward values based on them?


Keith

 

[Peter Nachtwey]

Deriving the equations for feed fowards.

Check out this link. I am not done with it but you will be able to see the procedure used to calculate what the feed forward gains should be for 3 different models. You can see that the higher the order of the model, the more feed forward gains are required to keep the transfer function equal to 1. Notice all the equations are different except for the Kv or velocity feed forward gain. Be sure to look at all three models.

ftp://ftp.deltacompsys.com/public/PDF/Mathcad - FeedForward.pdf

Perhaps I will polish this a make it a magazine article. I still want to show the graphs of responses to a sinusoidal target generator using the different feed forwards.

If you can get the model, calculating feedforward gains and PID gains is easy. Getting the model is the hard part. What winds my integrator up are those that have tuned one system and then think their experience should be good for everybody. You can see from the link that every model is different and has its own formulas.

Keith, one more thing. How do those motion controller control the higher order models when they use only 3rd order ramps and can't generate the higher order feed forwards? Hmmm.

Why the questions? Do you have a difficult system to cotnrol?

 

[kamenges]

Originally posted by Peter Nachtwey:

Keith, one more thing. How do those motion controller control the higher order models when they use only 3rd order ramps and can't generate the higher order feed forwards?

The only motion controller I've used for any type of demanding application so far is the Delta Tau PMAC. That was about 5 years ago. I don't know what they've changed since then (if anything). But for 'more demanding' applications they recommended you write your own servo algorithms using pole placement as opposed to the on-board PID with accel and velocity feed forward. Apparently you wrote it in assembly and they provided a 56000 compiler and a specific memory location on the board to download the compiled code. This would then run at the servo loop closure rate. They tossed in all sorts of disclaimers about this not being for the faint of heart. I'm not making any judgements on this either way but that was their solution.

Originally posted by Peter Nachtwey:

Why the questions? Do you have a difficult system to cotnrol?

No. Inquiring minds simply want to know. I have trouble letting go of things that I don't understand. We (collectively) put a man on the moon. I ought to be able to figure out where higher order feed forwards fit into a system.

OK, a little twist. You have a high order feed forward model that allows you to match zeros (which is what the feed forwards provide, correct?) to the poles of the plant. Doesn't your feedback filter (PID or other) also need to have a pole for every pole in the plant?

Keith

 

[Rod]

Keith and Peter,

We started out with Delta Tau. But there was too much work on our end to accomplish our needs back then (13 years ago). Boards were good, speed was okay. Now we have to have an order of magnitude increase.

Motion control math speeds and internal communication speeds are paramount!!!

DO NOT get me wrong! They had - and probably now have a seriously good machine! What we needed then and what they had then....

We were forced to move to Acro-loop and at this point we can't back up to DT.

Now were are fighting the ISA EIA ETC comms. Dang .DLLs! XP SUXS!

The ETC comms are the pits!

Big deal - only 120 machines out in the field that need to run and run and run...

Rod

 

[Peter Nachtwey]

Now everyone knows we are really mad.

The only motion controller I've used for any type of demanding application so far is the Delta Tau PMAC. That was about 5 years ago. I don't know what they've changed since then (if anything). But for 'more demanding' applications they recommended you write your own servo algorithms using pole placement as opposed to the on-board PID with accel and velocity feed forward. Apparently you wrote it in assembly and they provided a 56000 compiler and a specific memory location on the board to download the compiled code.

Again, how many people can do that? That would limit the market down to a handful of PhDs.

This would then run at the servo loop closure rate. They tossed in all sorts of disclaimers about this not being for the faint of heart. I'm not making any judgements on this either way but that was their solution.

Good for them. Any volunteers? I would like to keep it simpler and provide the extra gains so the user only needs to enter the right value or better, let the autotuning set the right gains.

No. Inquiring minds simply want to know. I have trouble letting go of things that I don't understand. We (collectively) put a man on the moon. I ought to be able to figure out where higher order feed forwards fit into a system.

Can you see that evey pole requires another feed forward? If you don't not have all the feed forwards terms there will be errors that the PID?? will have to correct. The ?? is for the extra error gains that would be required.
A motor with a load on a flexible shaft isn't so easy anymore. It never was. I will see what I can do to get a .pdf that shows how this system would be controlled.

OK, a little twist. You have a high order feed forward model that allows you to match zeros (which is what the feed forwards provide, correct?) to the poles of the plant. Doesn't your feedback filter (PID or other) also need to have a pole for every pole in the plant?
Keith

Very good question. I hinted at this during the PID threads last summer or the summer before. The answer is yes. We have found in hydraulics that the normal PID is not enough. Sometimes we need a higher order gain than the derivative. The derivative gain is basically a gain for the error between the target and actual velocity. Higher order gains would be for the error between the target and actual acceleration and the target and actual jerk. We use the pressure from either side of the hydraulic piston to provide the force and change in force which is proportional to the accelerations and jerk. A servo motor application would have the same problem with a flexible coupling. Position system have yet another pole that integrates velocity into position. The integrator gain on a PID does not count as a gain in these situations because the integrator comes with its own pole.

Scary isn't it? Tuning these higher order systems is not fun. Trial and error using graphs that show the sum of errors squared or integrated square error helps. Using the graphs to compute a model is best. Even if the model isn't exactly right it will at least provide good start points for all these higher order gains. Getting close on these higher order gains is better than ignoring the problem. The best plan is for the mechanical guys to design their systems so they are very stiff. The higher order poles are still there but if they are at a very high frequencies they can usually be ignored.

 

[kamenges]

Yea, I'm not quite right...

This will be my last post. I've dragged this thread so far outside the scope of the original post it isn't even funny anymore.

Originally posted by Peter Nachtwey:

I would like to keep it simpler and provide the extra gains so the user only needs to enter the right value or better, let the autotuning set the right gains.

I agree. I like your way better. As you said it is something that is at least accessible to the average user. They may not totally understand what they are adjusting but it will operate in a somewhat intuitive manner.

Originally posted by Peter Nachtwey:

The best plan is for the mechanical guys to design their systems so they are very stiff. The higher order poles are still there but if they are at a very high frequencies they can usually be ignored.

I've been pretty lucky so far. I haven't needed to set up any real systems that had to be high performance but were also very compliant. So, as you said, while the additional poles were there they were high enough in frequency that they didn't cause a problem.

Thanks for the info, Peter.

Keith

 

[Peter Nachtwey]

Now for some marketing info from Rod.

Keith and Peter,

We started out with Delta Tau. But there was too much work on our end to accomplish our needs back then (13 years ago). Boards were good, speed was okay. Now we have to have an order of magnitude increase.

DO NOT get me wrong! They had - and probably now have a seriously good machine! What we needed then and what they had then....

We were forced to move to Acro-loop and at this point we can't back up to DT.

Yes, 10 years ago I would have loved to have their DSP. I envied their processing power. Now processing power is not a problem. I am pretty sure DT wrote most of their code in assembly like I would have done and did. However, it is difficult to change processors when writing in CPU specific assembly language. I know because we are in the last phases of converting our code to C and we are re-writting our setup tool. We have decided to break with the past with our 3rd generation products and use DSPs or PowerPCs so now I think I have them out gunned finally. BTW, I have met the owner of Dimitri Dimitri, the owner of DT. I know he takes motion seriously. DT has been good competition. They have most got the high volume accounts where some engineering time can be devoted to getting the PMACs to run. There is a local integrator here in Vancouver, WA that uses DT in some pretty sophisticated applicatons. Most are in bottling.

Motion control math speeds and internal communication speeds are paramount!!!

Yes, the TMS320C33 we use runs at 60 MHZ and can do 60,000,000 floating point mulitply and adds a second. In reality this is not possible but we can still execute about 50 million instructions a second. We can still increase the speed to 75 MHZ. Compare these speed with PLC speeds. The PowerPC we use has a built in Ethernet interface so we can keep up with the 1756-ENBT cards and whatever else Rockwell designs. Ethernet/IP rocks. Our second generation product was designed to be twice as fast as the PLC5's Ethernet. This is not good enough.

Now were are fighting the ISA EIA ETC comms. Dang .DLLs! XP SUXS!

I wish you would say more about this. I would like you to describe in greater detail what you don't like about the .dlls.
I know XP suxs. It is a poor excuse for a operating system.
Still I would like to know about the troubles you had so I can avoid them.

The ETC comms are the pits!

Again, I would like to have more details. Tell me what your needs were and how the ETC comms failed to meet your needs. I don't want to make the same mistake. This is your chance to affect a future product. I listen. There were some threads about this. Our current product saves the whole project as a zipped .xml file. That includes symbols, comments and labels.

Please reply and expand your comments.

 

[Rod]

Peter,

I'll try to explain BUT I'm now out of the main programming/hardware loop.

As you know, EIA or is it ISA motherboards are no longer available. You will have to correct me here.
The new bus has a intermittant communication error with AcroLoop cards when we are running a 4th or 5th axis.
We are flooding the port with calls and responses. Our programmer can't find it, Acroloop can't find it and I am unwilling to give AL our source code.

They probably don't have the time to wade through 100,000 lines of our code and I can't afford to send our programmer there for the time it would take. We/I am STUCK!

We only buy about 3 motion control units per month, so we are too small to be of concern.

I'm not angry at AL or our programmer - just can't seem to get off the dime!

I do not envy your having to move your code to C. We, well I, began this project in VB because of our graphic interface and I could not afford the graphic modules required for C++. Now we must port to C++ and make it modular. After 13 years this thing has become a MONSTER!

A question for you sir. On your hydraulic servo valve controls do you incorporate a 'dithering frequency/voltage' to prevent stiction in the valve spool? If so, what freq do you find to be the best? I've always used about 400Hz.

Thanks,
Rod

 

[Rod]

Peter,

You mentioned PowerPC. You use a MAC for the front end?

To me that would imply using USB or Firewire ports and a stand alone motion control box.

I love my MACs but wouldn't base an industrial machine system on them. I've only seen two.

Rod

 

[ndzied1]

Peter,

You mentioned PowerPC. You use a MAC for the front end?

To me that would imply using USB or Firewire ports and a stand alone motion control box.

I love my MACs but wouldn't base an industrial machine system on them. I've only seen two.

Rod

I don't want to answer for Peter but just because something uses a Power PC micro processor doesn't mean it is a mac any more than something that used a 80286 chip had to be DOS. Anyone can buy these chips and write their own code on them to do whatever they want.

I once checked out a book on assembler for the 80386 processor. Microsoft never exploited many of the features on that chip regarding protected memory that might have made crashes a rarity. Instead, they continued to let the programming community (of which they were one of the biggest members) write willy, nilly to anywhichwhere in memory and voila, blue screen of death city.