Inconsistent Motion Axis Move

I am working on a retrofit of an old machine that has been updated using CL and Kinetix 6000. The machine is basically a 'smart belt' that synchs a rapidly moving product ( 40mtr/min ) into a flight chain using three smart belts.The product pieces are 6cm in length. A photoeye eye acts as registration input that triggers a motion axis move based on the amount of error
the product piece has with respect to a master encoder on the machine.

I am now in the wet test phase of the project and have one nagging issue that is troubling me. In testing each of the smart belts, I have disabled the logic that calculates error, and placed a fixed value to be sent to the Motion Axis Move ( MAM ) instruction and monitor the results. On a 6cm product piece, with a move of 3 cm I am getting an error of 1-2 cm on the gaps per each piece.

This machine has been in service for 15 years before the retrofit, so all that has changed are the servo motors and the controls.

I think I may be battling a servo tuning issue, but I have already applied the AutoTune feature available in RSlogix5000.

Any direction would be appreciated.


Thanks

CurlyandShemp, but no Moe

curlyandshemp said:

I think I may be battling a servo tuning issue, but I have already applied the AutoTune feature available in RSlogix5000.

Click to expand...

So how do you find out if the problem is as tuninig issue?

Well, I would plot my axis velocity command, velocity error and position error during a commanded move. But that's probably just me being old fashioned.

My guess is you have an axis acceleration or velocity limit that is preventing the axis from reaching the speed you intend it to. I don't know how the CLX motion card would handle this. If the limiting is done on the command side my plot idea wouldn't help much.

Keith

kamenges said:

Well, I would plot my axis velocity command, velocity error and position error during a commanded move. But that's probably just me being old fashioned.

Click to expand...

That is what I would do. I don't know what would be better or 'new fashioned'. You forgot to mention posting the trend on this forum when he posts next.

kamenges said:

My guess is you have an axis acceleration or velocity limit that is preventing the axis from reaching the speed you intend it to. I don't know how the CLX motion card would handle this. If the limiting is done on the command side my plot idea wouldn't help much.

Keith

Click to expand...

Sure it would. I would plot the control output too.

This is what a well tuned axis should look like on a trend. The target and actual trend lines look like just one line. This means there is no error between the target and actual position or target and actual velocity.
ftp://ftp.deltacompsys.com/public/jpg/scurves.bmp

The plots talked about above will highlight tuning deficiencies. However, if the issue is a command side problem plotting the command and the actual won't directly (intuitively?) show you the problem. The axis may be correctly following the command but the command might be wrong.

And that's where my inexperience with CLX motion comes in. If I specify a motion that will violate an axis limit (either velocity or acceleration) does the motion controller know this and modify the command profile or does the motion controller just send the command and the axis applies the limit. If it does the former The command and actual would track together but the command won't be right. If it is the latter the command and actual will begin to deviate. If it is an accel limit it will deviate almost immediately and the actual velocity slope will be shallower than the command slope. If it is a velocity limit the command and actual will track together up to a certain point and then the actual will plateau before the command does.

So, yes, you can determine the source of the error from the plots assuming you know what the command is supposed to be.

Keith

kamenges said:

The plots talked about above will highlight tuning deficiencies. However, if the issue is a command side problem plotting the command and the actual won't directly (intuitively?) show you the problem. The axis may be correctly following the command but the command might be wrong.

Click to expand...

You can see of the command or what I call target position are wrong from the graph, both the RSLogix trends and our product allow one to move a cursor back and forth across the graph/trend to read the values. It is easy enough to calculate accelerations by dividing the change in the target velocity by the time of the change.

kamenges said:

And that's where my inexperience with CLX motion comes in. If I specify a motion that will violate an axis limit (either velocity or acceleration) does the motion controller know this

Click to expand...

Yes, but only because the output is saturated or a following error has occured.

kamenges said:

and modify the command profile or does the motion controller just send the command and the axis applies the limit.

Click to expand...

The target generator does not change unless the error triggers the supervisor program and the supervisor program changes the parameters to the target generator. This means the output will saturate.

kamenges said:

If it does the former The command and actual would track together but the command won't be right. If it is the latter the command and actual will begin to deviate. If it is an accel limit it will deviate almost immediately and the actual velocity slope will be shallower than the command slope. If it is a velocity limit the command and actual will track together up to a certain point and then the actual will plateau before the command does.

Click to expand...

Your intuition is good. The motion controller shouldn't modify the motion profile on its own. It will work for some cases and there will be a lot of upset customers in others. If there are multiple axes tracking together the motion controller should not want to change the motion profile. It is one thing if the customer ruins machinery because of a mechanical bind. It is quite another if the motion controller ruins machinery because it tries to be smart.

You wouldn't want to modify the motion profile in this example.
ftp://ftp.deltacompsys.com/public/jpg/stall.gif
Notice that the system does get back in synch.

I can get example graphs of these cases if anyone is interested.

kamenges said:

So, yes, you can determine the source of the error from the plots assuming you know what the command is supposed to be.

Click to expand...

The programmer had better know!!!!

Originally posted by Peter Nachtwey:

The programmer had better know!!!!

Click to expand...

I would tend to agree with this. But Peter, in this post:
http://www.plctalk.net/qanda/showpost.php?p=50927&postcount=21
you seem to indicate that it's not so important for the end user to know exactly how the axis gets where it wants to go. As long as it gets there on time and at velocity. This frees the end user from having to run through the calculations that would tell them exactly where and how fast the axis is at any given time.


Again, I haven't done much with CLX motion. I know what you are saying above is correct for the M02AE. But does it also apply for the M08SE or the M16SE? In both those cases the drives (at least the K6000) are configured through SERCOS with parameters entered in Logix5000. It would seem odd to me that the motion firmware would allow a command trajectory that it should know the axis can't possibly follow. Granted, I as a user shouldn't be asking the axis to do something it can't either. But just because I don't intend to drive into a bridge support column doesn't mean I shouldn't wear my seat belt (note: that's an example; I don't intent to try it). I would think that allowing the trajectory planner to use the configured axis limits as limits to the profile would be a way to avoind axis control saturation.

Keith

Yea, yea, yea.

kamenges said:

I would tend to agree with this. But Peter, in this post:
http://www.plctalk.net/qanda/showpost.php?p=50927&postcount=21
you seem to indicate that it's not so important for the end user to know exactly how the axis gets where it wants to go. As long as it gets there on time and at velocity. This frees the end user from having to run through the calculations that would tell them exactly where and how fast the axis is at any given time.

Click to expand...

Most controllers use traditional commands where the programmer must specify the destionation, speed, acceleration and deceleration. In this case the programmer knows what to axis is doing because the programmer specified all the parameters.

We have another class of commands where the program just specifies the desired end results and the controller computes the means of achieving the desired results. A simple example is what we call a timed move. The programmer speficies where the axis needs to be and when and the motion controller takes care of calculating the motion profile to achieve the desired results. In this case one must use a graph to plot the target position and velocity as a function of time or as a function of the position of another axis. In this case the programmer can still find out exactly what is happening every millisecond if need be.

Here is another example.
ftp://ftp.deltacompsys.com/public/jpg/democrv.JPG
All you need to do is specify the positions and times. The position, velocity and acceleration are updated as you edit the master points. This way the programmer still knows exactly what is going to happen before it happens. That is a good thing as most people hate surprises. It is an electric cam.

We should have a Peter and Keith discus motion thread.
I wonder what happened to curlyandshemp? Hopefully he is getting a RSLogix trend for all to see.

curlyandshemp said:

I think I may be battling a servo tuning issue, but I have already applied the AutoTune feature available in RSlogix5000.

Click to expand...

There are several items that are optional in the auto-tune procedure. Since you seem to be experiencing excessive following error, perhaps you didn't include velocity feedforward in the tuning process. The auto-tune process also sets the position error tolerance inversely proportional to the P gain. This must be greater than the 2cm error you're getting or the axis would fault. On the sercos units, you can also select to include acceleration feedforward.

curlyandshemp said:

This machine has been in service for 15 years before the retrofit, so all that has changed are the servo motors and the controls.

Click to expand...

If the motors you replaced were DC and you selected AC motors with similar torque ratings, then you could have a sizing problem. Older DC servos typically have 2-3 times the rotor inertia of modern AC servos with the same torque ratings. That increases the load:rotor inertia ratio which makes tuning more difficult. The de-tuning necessary to get stability may make it impossible to achieve your speed and accuracy requirements.

Originally posted by Peter Nachtwey:

We should have a Peter and Keith discus motion thread.

Click to expand...

Isn't that what most of the motion related threads turn into anyway?

I just get into this to learn new things from The Master.

The position/velocity/time motion definition is a pretty cool way to go. The JPEG didn't come throough real clear but it looks like all the segments use cubic interpolation. Is that the oly interpolation type or can you choose that also?

Originally posted by Peter Nachtwey:

I wonder what happened to curlyandshemp? Hopefully he is getting a RSLogix trend for all to see.

Click to expand...

I kind of wonder, too. It would be good to see a trend. That would tell us quite a bit. I'd also like to know what controller flavor he is using.

The thing that catches my attention from a move definition standpoint is that the MAM instruction is always time based. Other than the cam instructions it doesn't look like they have any space based moves. Unless the move parameters for the MAM are being constantly recalculated based on conveyor speed I would think it would be pretty tough to put something consistently on a specific spot of a moving conveyor.

Keith

kamenges said:

The position/velocity/time motion definition is a pretty cool way to go. The JPEG didn't come throough real clear

Click to expand...

Did you click on the image after downloading it? It gets expanded. At least it does for me. You actually have to scroll to see the whole image because I captured the screen using a 1600x1200 laptop. If you look at the bottom in the spread sheet part you will see where you can select cubic or linear. The linear segments have an acceleration of 0 so they are good for moving at a constant velocity.

kamenges said:

but it looks like all the segments use cubic interpolation. Is that the oly interpolation type or can you choose that also?

Click to expand...

That product uses only cubic and and linear segments while executing splines or camming. Normal point to point ramps are either linear or sinusoidal for the s curve.

The new product uses 5th order polynomials all the time.

kamenges said:

The thing that catches my attention from a move definition standpoint is that the MAM instruction is always time based. Other than the cam instructions it doesn't look like they have any space based moves. Unless the move parameters for the MAM are being constantly recalculated based on conveyor speed I would think it would be pretty tough to put something consistently on a specific spot of a moving conveyor.
Keith

Click to expand...

I have seen a flying shear using a 1756-M02AS. A M02AS is like a M02AE only it uses an SSI input so it is absolute. The M02AS can both linear and rotary applications. In this flying shear application a cam was used.

My Bad...
As it turns out I messed up count ratio between the machine and the absolute encoder I have installed. This is why I was having inconsistent MAMs, as my Process Variable into the control loop was wrong.

Quick recap of the application

- high speed wrapper, that handles up to 400 6cm product pieces per minute that are synched to a flight chain on the machine. The main VFD driven shaft of the machine turns and absolute encoder that allows the upstream servos to know where the flight chains are.

This is where I messed up. I miscounted the number of turns the main shaft turned the absolute encoder. Somehow I was sure 4 shaft turns equaled 1 encoder turn. As it turns out it is actually 2 shaft turns equals 1 encoder turn.

It was not until today when I started plotting a timing diagram that I noticed the 'good' window and the 'bad' window occured twice per encoder revolution. Then it hit me...dohhhhhhhhhhhhhhhhh.

CurlyandShemp, and Moe should hit me with an anvil

A picture or plot is worth a 1000 words.

curlyandshemp said:

It was not until today when I started plotting ...

Click to expand...

That OK. Keith and I had an excuse to talk motion.