RS5000 and M02AS hydraulic servo motor

[Peter Nachtwey]

Originally Posted by MaxK

It would be very interesting to see also the control curve, because the nature of the noise modes in the valve position signal is not clear.

What do you mean by control curve? The green line should be the output to the valve. The valve has an inner control loop that should position the valve to 50% open when a 5 volt signal is applied. The valve takes -10 to +10 volts. There is a spool position feedback which most people don't bother with.


I wrote the code for they HYD02 and M02AS controllers over 20 years ago. The code for the HYD02 and M02AS started with the M02AE code. There where conditional compiles that would add or remove code depending on the feedback. The advantage is that the learning curve going from one controller to the next was minimal. The same commands from the PLC could control all three versions.

[kamenges]

Originally posted by Peter Nachtwey:

So the target and actual positions are not on the same scale?

That's the way to looks to me. The numbers in the box on the upper left corner of the trend show the min and max values for each trace. But like I said, the thing that really tipped me off was that each trace touches the top and bottom of the graph somewhere. That isn't likely to happen with fixed scaling and it isn't coincidental.

Keith

[Robb B]

Target and actual positions were set to automatic scale, but are the same units (inches). The latest one is done with fixed scales + 10%.

I might look a little further into the feedback circuit, it could be enlightening for future diagnostics.

[ASF]

Originally Posted by Peter Nachtwey

So the target and actual positions are not on the same scale? The tracking looks good when moving.

That's correct - the command position is scaled 16-101 units, and the actual position 13-103. Logix trends are set to automatically scale the Y axis by default, and in some cases that's helpful, but in cases like this the first thing you need to do is to manually set up the scaling so that you can get a meaningful trace happening.

[MaxK]

Originally Posted by Peter Nachtwey

The green line should be the output to the valve.

This is the signal from the controller to the valve. Got it.

1. Any way, the "noise" is not white or normal, there are obvious "modes", i.e. there is a clear system “error” in the operation of the algorithm (calculations) - it seems to me that it would be useful to identify it.

2. If we look at the "Motion cycle manual 2023 02 02.jpg" graph (trying to remove the noise), we can see the fluctuations (1:12:14 - 1:12:19 they can be seen quite well). Fluctuations mean that at least one of the process harmonics (lag order) is not compensated by the control system. Possible solutions:
- Reduce the "order" of the process. Make the pipeline more rigid, remove backlashes, leaks, delays, etc.
- Increase the control order. In practice, it is not realizable.
- Reduce the "speed" of the process.
S-curve formula?
The "up" movement takes about 4 seconds, and the "down" movement takes about 6 seconds.
- Why?
- I do not know the intricacies of the process, but when moving "down" the fluctuations are much less

[Peter Nachtwey]

Originally Posted by MaxK

This is the signal from the controller to the valve. Got it.

1. Any way, the "noise" is not white or normal, there are obvious "modes", i.e. there is a clear system “error” in the operation of the algorithm (calculations) - it seems to me that it would be useful to identify it.

The spikes are not really noise. They are due to poor feedback resolution and the derivative gain.

2. If we look at the "Motion cycle manual 2023 02 02.jpg" graph (trying to remove the noise), we can see the fluctuations (1:12:14 - 1:12:19 they can be seen quite well). Fluctuations mean that at least one of the process harmonics (lag order) is not compensated by the control system. Possible solutions:
- Reduce the "order" of the process. Make the pipeline more rigid, remove backlashes, leaks, delays, etc.
- Increase the control order. In practice, it is not realizable.
- Reduce the "speed" of the process.

The controller has a scan time of 250 microseconds. Going slow will not help. I bet there are times when the controller doesn't even see the counts change between scans because there aren't enough encode counts per resolution.

The M02AE, HYD02 and M02AS all work of counts internally and there aren't enough that go by every scan time.

S-curve formula?

Yes, the PLC generates the a 3rd order s-curve. The M02AS knows nothing about s-curves. The PLC generates a position for the controller to be at every coarse update time. The controller interpolates between the coarse up date times to generate a new position and velocity every 250 microseconds.

The "up" movement takes about 4 seconds, and the "down" movement takes about 6 seconds.
- Why?

Maybe that is all the is required. Robb B needs to do some math and tell us how many counts occur every 250 microseconds while moving.

- I do not know the intricacies of the process, but when moving "down" the fluctuations are much less

Remember the spikes are just due to quantizing error.

[Robb B]

Originally Posted by Peter Nachtwey

The spikes are not really noise. They are due to poor feedback resolution and the derivative gain.


The controller has a scan time of 250 microseconds. Going slow will not help. I bet there are times when the controller doesn't even see the counts change between scans because there aren't enough encode counts per resolution.

The M02AE, HYD02 and M02AS all work of counts internally and there aren't enough that go by every scan time.


Yes, the PLC generates the a 3rd order s-curve. The M02AS knows nothing about s-curves. The PLC generates a position for the controller to be at every coarse update time. The controller interpolates between the coarse up date times to generate a new position and velocity every 250 microseconds.


Maybe that is all the is required. Robb B needs to do some math and tell us how many counts occur every 250 microseconds while moving.


Remember the spikes are just due to quantizing error.

If my math is correct, at 250 microseconds there is 0.2085 Feedback counts. The position is almost meaningless or undefined in 250 microsecond intervals, it's only when longer time periods are used that any real information about position becomes available.

The "up" and "down" is horizontal movement, but it's the difference between forward and reverse. They run at slightly different speeds due to carrying a load and being empty. The load is maximum 8 railway ties, about 300 lbs each (sometimes less).

[MaxK]

Originally Posted by Robb B

If my math is correct, at 250 microseconds there is 0.2085 Feedback counts.

How did you calculate it???

Originally Posted by Robb B

The "up" and "down" is horizontal movement, but it's the difference between forward and reverse. They run at slightly different speeds due to carrying a load and being empty. The load is maximum 8 railway ties, about 300 lbs each (sometimes less).

So in which direction does it move loaded and in which empty?

Originally Posted by MaxK

- Reduce the "speed" of the process.

I'm sorry, I didn't express myself correctly. By Reducing the "speed" I meant decreasing derivatives (velocity, acceleration, etc.).

[Peter Nachtwey]

I 'be got a new topic for a Peter ponders pic video. Resolution.

[Robb B]

Originally Posted by MaxK

How did you calculate it???

So in which direction does it move loaded and in which empty?

I'm sorry, I didn't express myself correctly. By Reducing the "speed" I meant decreasing derivatives (velocity, acceleration, etc.).

To calculate I used 41.7 counts per inch at a rate of 20 inches per second (maximum speed in the axis configuration), reduced to a 0.000250 second interval. Lower speeds will produce more counts per second, I think the existing encoder should be okay for the application at 22bits of resolution, but that the way it's measuring, or perhaps it's location is causing more uncertainty or inaccuracy.

It moves from low (13 inches) loaded to high (106 inches) to unload. There are different speeds programmed for loaded travel vs unloaded travel, which is probably unnecessary.

[Peter Nachtwey]

Originally Posted by Robb B

To calculate I used 41.7 counts per inch at a rate of 20 inches per second (maximum speed in the axis configuration), reduced to a 0.000250 second interval. Lower speeds will produce more counts per second,

No! fewer!

41.7 cnts/inch / 20 inch/sec = 2.085 cnts/sec.


This means that most of the time, the controller doesn't see the motor turning. When it does, the derivative term provides a big spike.

I think the existing encoder should be okay for the application at 22bits of resolution, but that the way it's measuring, or perhaps it's location is causing more uncertainty or inaccuracy.

Now I am confused again. are there 2^22 counts per turn or just 22 counts per turn? How do you get 22 counts per turn when an SSI encoder usually has some number n raised to the 2 counts per turn? 8 bit encoders are common and will produce 2^8 bits per revolution or 256 bits. So are 10 and 13 bit SSI encoders.

It moves from low (13 inches) loaded to high (106 inches) to unload. There are different speeds programmed for loaded travel vs unloaded travel, which is probably unnecessary.

It may be necessary, the load changes the open loop gain or maximum speed of the system.


There is a lot that doesn't make sense.

[Robb B]

Originally Posted by Peter Nachtwey

No! fewer!

41.7 cnts/inch / 20 inch/sec = 2.085 cnts/sec.


This means that most of the time, the controller doesn't see the motor turning. When it does, the derivative term provides a big spike.




Now I am confused again. are there 2^22 counts per turn or just 22 counts per turn? How do you get 22 counts per turn when an SSI encoder usually has some number n raised to the 2 counts per turn? 8 bit encoders are common and will produce 2^8 bits per revolution or 256 bits. So are 10 and 13 bit SSI encoders.




It may be necessary, the load changes the open loop gain or maximum speed of the system.


There is a lot that doesn't make sense.

I must have misplaced my decimal. There's a lot I'm learning, my ignorance surely causes confusion. I don't know about counts per turn, I got 22 bits from the feedback tab of the motion axis. 22bits at 208Khz with an absolute feedback offset of 10006.984 inches.

[Peter Nachtwey]

I am still confused. If an SSI encoder has 22 bits then it gets 2^22 counts per revolution. Next we need to know how many inches travel per revolution. From this we calculate the number of counts per inch. If the machine moves at 20 inches per second, we can calculate the number of counts per second and the number of counts per 250 microseconds.

[drbitboy]

[Edit: fixed some typos]

Originally Posted by Peter Nachtwey

41.7 cnts/inch / 20 inch/sec = 2.085 cnts/sec.

Oh dear, Peter ...

Do at least perform a modicum of unit analysis and get the units right.

     count
41.7 -----
     inch            cnt s
-----------  = 2.085 ------
      inch           inch2
20    ----
       s

Which is of course the kind of complete nonsense we get when we don't pay attention to units.

OP had at least the number correct originally:

     count            inch                s              count
41.7 -----   *     20 ----  =  0.000250 -----  =  0.2085 -----
     inch              s                cycle            cycle

OP did get the slope wrong though: lowering the linear speed (20.47 inch/s, above) will produce fewer counts per second.

[MaxK]

Originally Posted by Robb B

20 inches per second (maximum speed in the axis configuration)

it seemed to me that on the chart "Motion cycle manual 2023 02 02.jpg" the speed reaches 25 inches per second. doesn't matter

Originally Posted by Robb B

Lower speeds will produce more counts per second

Excuse me?
According to your logic, at speed = 0, the accuracy will be infinite
(encoder resolution) * (speed)
speed = 20 inch/second
counts per second = 41,7 counts/inch * 20 inch/second = 834 counts/second
speed = 0 inch/second
counts per second = 41,7 counts/inch * 0 inch/second = 0 counts/second

Originally Posted by Robb B

It moves from low (13 inches) loaded to high (106 inches) to unload.

In other words loaded stacker moves faster then unloaded. Correct?
At the moment then stacker almost immediately stops it lost load. Correct?
You questioned why it is oscillations. Correct?

Try do decrease all target position curve derivates as low as possible

Originally Posted by Robb B

22bits at 208Khz with an absolute feedback offset of 10006.984 inches.

10006.984 inches * 41,7 counts/inch = 417291,2328 counts

2^22 = 4194304

10 times difference. Are you sure you didn't make a mistake with the orders (decimal point) anywhere?