Match Speds on AB motion control

Hi Guys:
I got a motion control application (flying cutoff machine for steel pipe )with AB control logix using a 1756-M02AE, in one channel of this board I got a feed back only axis ( quadrature encoder )and on the other one there is a servo axis driving a hidraulic servovalve that moves a cylinder with double stroke, feedback here is done thru another quadrature encoder.
I'm using a MAG (Motion axis gear) trying to move the cylinder (slave) to the same speed of the feed back only axis( master,)but the speed of the slave is a little bit lower than the master's, so when I cut the pipe, the knive leave a mark on the pipe due to difference in speed.
I tune the whole system as the manual explain but keep on trying to match speeds, any suggestion ???

william

widelto said:

I'm using a MAG (Motion axis gear) trying to move the cylinder (slave) to the same speed of the feed back only axis( master,)but the speed of the slave is a little bit lower than the master's, so when I cut the pipe, the knive leave a mark on the pipe due to difference in speed.
william

Click to expand...

So how are you doing the clutching or ramp up part?
Do you have a trend you can post on this forum?
Are you using feed forwards.

Peter, Thanks for your response:

- I speed the slave at 100% of maximum accel.
I'm not using the clutch option.
- I'm not trending because I read on the AB manual says that trending on the PLC makes my event tasks slow and I want my system to be as fast as possible, but I see that phisycally that the slave is slower than the master.
I use a MAW ( motion axis watch ) instruction before doing the MAG instruction just to start moving the slave up to the master's speed.

- The MAG instrution is the only one needed to eleectronically gear both axis so I need nothing else.

Thanks,
William

Now Peter is much better at this than I am but you say you are acceling at 100% but is your speed 100%. Is your master speed 100% of what the motor can do?

Are motors, feedback, gearboxes, etc the same?

Does the slave seem to be falling further behind, catching up, or just steadily behind?

widelto said:

Peter, Thanks for your response:

- I speed the slave at 100% of maximum accel.

Click to expand...

This doesn't make sense. You can't accelerate at 100%. Your acceleration depends on the clutching or ramping distance and the master encoder ( line speed ).

widelto said:

I'm not using the clutch option.

Click to expand...

You just can go from a gear ration of 0/1 to 1/1 instantly. It is know wonder the machine is having problems.

widelto said:

- I'm not trending because I read on the AB manual says that trending on the PLC makes my event tasks slow and I want my system to be as fast as possible, but I see that phisycally that the slave is slower than the master.

Click to expand...

Get a trend anyway. You need to see what is happening. You can turn the trend off when you are not debugging.

widelto said:

I use a MAW ( motion axis watch ) instruction before doing the MAG instruction just to start moving the slave up to the master's speed.

Click to expand...

I will need to check on that. It would seem to me that there would be a lot of variablity in the starting point.

widelto said:

- The MAG instrution is the only one needed to eleectronically gear both axis so I need nothing else.

Click to expand...

Using the cam tables may be better. This way you can ramp up the slave ( clutch ).

The basic trick is that there must be a clutching distance or ramping distance where the gear ratio goes from 0/1 to 1/1. You just can't change the gear ratio instantly without cause the machine to jump. During the clutching the master will travel twice as far as the slave. That is because the slave's average speed will be the average or half between 0 and the master speed. Therefore, if you know the master and slave must be synced at 0.1m you would start the slave from 0.05m and the master at 0.0m. If the slave can't accelerate to the master speed in 0.05m then you may need to start the slave at 0.06m and have the axes synchronized at 0.12m. The master always travels twice as far a the slave unless you have a customer ramping alogorithm for the slave.

Another point is that all this must happen as a function of the master speed. If the master speed is slow then the slave speed and accelerations are slow. You have the change of the slave position as a function of the change in the master position times the change in the master position per second.
In calculus this is called the chain rule. The motion controller should hide the calculus from you.

After the cut the slave must hurry back to the home position which may be a .05m or .06m and wait for the master positin to be reset back to 0.0m where the whole cycle repeats.

Here is an example from another motion controller that can get real time plots and still have 90% idle time.
ftp://ftp.deltacompsys.com/public/jpg/flying shear.png
This plot has a lot of detail so it couldn't be displayed on the forum.

Here the clutching begins at about 0.42 seconds. The lines are color coded. You can see the pink arch which is the acceleration that is used for the acceleration feed forward. The green line is the control output. The red and cyan lines are the actual and target position and the blue and magenta line are the actual and target velocity. Notice that the velocity ramps up smoothly. The clutching or ramping is complete at about .62 seconds and about .2 seconds pass before the shear makes its cut which you can also see. At about 1 second the slave or traverse is head back to the home position. It doesn't need to be geared for that.

Peter Nachtwey said:

Using the cam tables may be better.

Click to expand...

Absolutely!!

Your master axis must go through a cycle (the cut length). So it should be configured as a rotary axis with the unwind equal to the cut length (probably variable).

Create a cam profile defining where the flying shear should be at the critical points of the master's cycle. The cam profile length must equal the master unwind.

Peter Nachtwey said:

Are you using feed forwards.

Click to expand...

IF not, you should be - minimal following error is vital to your application.

Gerry, if you have used the cam tables for a flying shear, how many points did you use? How did you change the table on the fly? I would think that would take some time. You should be able to tweak the motion profile between cuts.

Thanks for your responses:

Peter Nachtwey said:

This doesn't make sense. You can't accelerate at 100%. Your acceleration depends on the clutching or ramping distance and the master encoder ( line speed ).

Click to expand...

Yes, you're right. I opted for this method due to the lack of space i got for accelerating, making the cut and go back to home (0.9 meters)

Peter Nachtwey said:

You just can go from a gear ratio of 0/1 to 1/1 instantly. It is know wonder the machine is having problems.

Click to expand...

Ok, today i'm testing a slower accel rate and I'm even trying with the clutch option.

Peter Nachtwey said:

Get a trend anyway. You need to see what is happening. You can turn the trend off when you are not debugging.

Click to expand...

I hope to have it by this afternoon

Peter Nachtwey said:

I will need to check on that. It would seem to me that there would be a lot of variablity in the starting point.

Click to expand...

The reason I did this is that I want to make the cut always at the same point, so If start the electronic gear always at the same point I should cut always at the same position.

{QUOTE=Peter Nachtwey]
Using the cam tables may be better. This way you can ramp up the slave ( clutch ).
[/QUOTE]
Yes, that's an option. I'll look at it.

{QUOTE=Peter Nachtwey]
Another point is that all this must happen as a function of the master speed. If the master speed is slow then the slave speed and accelerations are slow. You have the change of the slave position as a function of the change in the master position times the change in the master position per second.
In calculus this is called the chain rule. The motion controller should hide the calculus from you.
[/QUOTE]
Good idea, I'll try it

Peter, plase explain to me What feed forward is ?

To the other people who also responsed, Gerry send me your approach.

Thanks for your help.

william

First of all, feed forward. Feed forward is a control output based on the command position/velocity/accel/jerk/force/etc. of an axis. If you use only a closed loop filter (like a PID) to develop your output command you need a certain amount of error to get any command at all. This puts you behind the curve immediately and you get farther behind the faster/harder you move.

By using feed forward (output based on command) you will have a much better chance of staying on profile right from the start. You start putting out a control output BFORE an error even develops. The nice thing about feed forward values is they are open loop. They won't tend to induce oscillation in your system. With a feedback filter only you often have to increase the gains so hign that you induce oscillation.

I also agree whole-heartedly with Gerry and Peter that camming is the way to go. The motion axis gear function doesn't provide defining acceleration in terms of master motion. So, as Peter said, you will need to continually recalculate either your acceleration rate or your trigger point based on master speed. While this isn't necessarily difficult it does add another software delay component, especially if your master speed reference is noisey or changes often. Camming makes this all disappear. Granted, with camming you need to recalculate the cam rollover position for each length. But that is all you would need to do, I think. Everything else would stay the same assuming you set up you accel/match/cut/decel/return portion of the cam to your worst case cut.

Keith

widelto said:

Yes, you're right. I opted for this method due to the lack of space i got for accelerating, making the cut and go back to home (0.9 meters)

Click to expand...

In my link above you can see the slave moves from 2 inches to a max of 13 inches which is a difference of about 0.326m. This is tracking metal sheet traveling at .2m/s

widelto, how fast it the master moving? How much mass are you accelerating? If the hydraulic/mechanical system is not designed correctly then the motion controller will not have a chance no matter what you do. Can you do a MAM at the speed and acceleration that your system requires? If not it is time to fix the hydraulics/mechanics.

widelto said:

The reason I did this is that I want to make the cut always at the same point, so If start the electronic gear always at the same point I should cut always at the same position.

Click to expand...

yes, but use the technique I stated above where the master travels twice as far as the slave.

widelto said:

Peter, plase explain to me What feed forward is ?

Click to expand...

Keith's explanation was pretty good.
Note, we turn off the acceleration feed foward during the shearing action so the system does react to the shock caused by the shear.

I also agree whole-heartedly with Gerry and Peter that camming is the way to go.

Click to expand...

I am not convinced that cam tables are the way to go but cam tables may be the easiest way to get something work. The link above does not use cam tables.

especially if your master speed reference is noisey or changes often. Camming makes this all disappear.

Click to expand...

One must still calculate the master velocity even if using a cam table. Any noise or quantizing on the master velocity is reflected in the slave's target position.

Granted, with camming you need to recalculate the cam rollover position for each length.

Click to expand...

This is why I am not convinced that cam tables are the best way to go. It takes time to recalculate the cam table.

Originally posted by Peter Nachtwey:

I am not convinced that cam tables are the way to go but cam tables may be the easiest way to get something work. The link above does not use cam tables.

Click to expand...

How did you do that? I know how the evil guys from California would do it, but how did you?

Originally posted by Peter Nachtwey:

One must still calculate the master velocity even if using a cam table. Any noise or quantizing on the master velocity is reflected in the slave's target position.

Click to expand...

True enough. This is a basic concern of all real master applications. As far as I know your two alternatives are to filter the master reference, which affects accuracy, or use a virtual master, which requires control of the feed axis. Is there another option in following?

Originally posted by Peter Nachtwey:

This is why I am not convinced that cam tables are the best way to go. It takes time to recalculate the cam table.

Click to expand...

You only need to recalculate the cam table on a length change. If this is something you are doing on every cut then camming probably isn't the way to go. However, if the application is to enter a desired cut length, cut 1,000 copies, then enter another cut length it isn't such a concern. For any given length the slave to master position relationships hold for any speed right up until you violate the capability of your actuator.

Keith

I would try to increase the FF gain before diving off into setting up cam tables...I have had similar applications that I successfully synchronized by using the FF Gain, although they were in 1394 and S-Class controllers...

If you get too high with the FF Gain, the slave steady state velocity may oscillate, or the slave velocity may overshoot slightly just as the master acceleration ramp ends. When FF is required, these are the indicators I look for to know where to stop increasing it.
JMHO

Originally posted by OkiePC:

I would try to increase the FF gain before diving off into setting up cam tables...I have had similar applications that I successfully synchronized by using the FF Gain, although they were in 1394 and S-Class controllers...

Click to expand...

I agree that to a large degree feed forward will take care of the issue of staying on profile. This will correct the problem of skidding across the material as the cut begins. However, outside of that issue is the issue of starting at the correct point. From what I can tell the AB CLX motion suite doesn't provide for 'spacial' acceleration definition. You can define a gear ratio with the motion axis gear command but you can't tie the accel rate to the master rate. So as the speed changes you either have to recalculate your 'clutch' accel rate or you need to redefine your accel start position. Even if you do this, if the speed changes while you are accelerating you are toast.

Camming produces a slave to master relationship that takes care of this concern. There are other ways to do this but I don't think the CLX platform provides for them.

Keith

kamenges said:

How did you do that? I know how the evil guys from California would do it, but how did you?

Click to expand...

5th order polynomial ramps and the chain rule. That is the easy part. Calculating smooth velocities over a time period of 1 millisecond is the key. If the master speed is bouncing around the slave target speed will to the same and so will the control output. Calculating the acceleration, the pink line, for the acceleration feed forward is something I will keep to myself.

True enough. This is a basic concern of all real master applications. As far as I know your two alternatives are to filter the master reference, which affects accuracy, or use a virtual master, which requires control of the feed axis. Is there another option in following?

Click to expand...

Yes, get a high resolution encoder. The encoder above gives over 200,000 counts per revolution. If you read my article about resolution then you know I feel strongly about having all the resolution you can get. How can you track a master encoder that has only 1000 counts per revolution? If the roller has a circumference of 10 inches the resolution is .01 inchers per count when sampled every millisecond. The best speed resolution one can get then is 10 incher per second which will not work. The link above does not use a filter because the system must track even if it slows down or speeds up while in the process of making a cut. The virtual master trick will not work. There are other 'tricks'.

OkiePC said:

If you get too high with the FF Gain, the slave steady state velocity may oscillate

Click to expand...

kamenges said:

The nice thing about feed forward values is they are open loop. They won't tend to induce oscillation in your system.

Click to expand...

Keith has is right. Feed forwards do not cause oscillations.

However, if the master velocity is very coarse, because one is using only a 10000 count encoder with a 10 inch diameter roller, the master velocity will be quantized to increments of 1 inch per second. Therefore the slave target velocity will try to follow the master velocity so the slave target velocity will change in increments of one inch per second. When this quantized speed is multiplied by the feed forward gains the output will be quantized too. The output will jump up and down and look like fuzz or noise on an oscilloscope.

If the output looks as clean as the output in the link there is a good chance you can have a system that will track accuately and smoothly.

So what does this mean to widelto? Let assume the these facts:
Max speed = 1.0 m/s
encoder = 10000 counts/rev
1 rev = .25 m.
synchronizing speed = 0.5 m/s

At synchronizing speed the encoder is turning at 2 revs per second and generating 20000 counts per second. That sounds like a lot until you look at how many counts the controller sees each millisecond, 20. This means the system speed will vary by about %5 from one millisecond to the other millisecond because the encoder will generate 18,20 or 21 counts each millisecond. %5 of .5 m/s is .025 m/s of error due to quantizing.

Now for the feed forward term. The max speed of 1.0 m/s is achieve when the controller output 10 volts. This means the feed forward gain is 10 volts/(m/s).

Now when the quantized velocity of .025 m/s is multiplied by 10 v/(m/s) the output will jump around by 0.25 volts. This is from just from the velocity feed forward term. The acceleration feed forward term will be MUCH higher.




Hopefully widelto is using high resolution encoders.

Originally posted by Peter Nachtwey:

5th order polynomial ramps and the chain rule.

Click to expand...

I'm going to need to dig into this a little bit to see how it applies. Either the coefficients change or time changes. My initial guess is that time changes but I have to look at it a little more carefully.

Originally posted by Peter Nachtwey:

Calculating smooth velocities over a time period of 1 millisecond is the key.

Click to expand...

and

Originally posted by Peter Nachtwey:

Yes, get a high resolution encoder. The encoder above gives over 200,000 counts per revolution.

Click to expand...

I definitely agree with that. Even in the relatively simple things I do the highest possible resolution would be nice to have. Doing even a single differential on a low resolution signal gets ugly. Higher order differentials are nearly impossible.

Originally posted by Peter Nachtwey:

Hopefully widelto is using high resolution encoders.

Click to expand...

A common mistake people make is looking at encoder resolution only in the context of position measurement accuracy. 'I need to position to within 0.125" so a pulse every 0.030" is enough.' As Peter stated, not necessarily. For very low bandwidth applications that may be OK. But as the application gets more demanding and the tools required to make the application work get more involved, encoder resolution above and beyond that needed for simple measurement accuracy becomes inmportant.

I'll be very interested to see what widelto ends up using for a command generation strategy with the tools he has avaliable. It can be done but how will he do it.

Keith