Flying cut of saw line encoder

[AJZ]

On a flying shear or cut-off saw system, the encoder that measures the speed of the material fed is very important. To select an encoder, what is the minimum velocity resolution required?
I looked at a older system with a newer motion controller that is working OK but product length is a little to inconsistent(Spec. is +/- 1/8") and some odd things are happening (Cut length does not match set point and cut length is different depending on which direction the saw moves). The line speed can be set from two inch/sec to 16 inch/sec.
The existing line encoder provides 398.5 pulses per inch of travel resulting in a velocity resolution of 1.25inch/sec. And the saw carriage encoder has a velocity resolution of 0.58 inch/sec.
By what factor should the encoder resolution be improved to get a good performing machine?

 

[Peter Nachtwey]

To select an encoder, what is the minimum velocity resolution required?

There isn't an minimum. The finer the resolution the better but eventually you get to the point of diminishing returns.

I looked at a older system with a newer motion controller that is working OK but product length is a little to inconsistent(Spec. is +/- 1/8") and some odd things are happening (Cut length does not match set point and cut length is different depending on which direction the saw moves). The line speed can be set from two inch/sec to 16 inch/sec.

I have customers getting 0.010 inch resolution at 30 inches per second.

The existing line encoder provides 398.5 pulses per inch of travel resulting in a velocity resolution of 1.25inch/sec. And the saw carriage encoder has a velocity resolution of 0.58 inch/sec.

That is very poor resolution. Some depends on how fast the controller updates its output. If the controller updates every 1 millisecond and the resolution is 0.001 inches then the velocity resolution is 1 inch per second which is definitely not good enough. If the motion controller updates every half millisecond the velocity resolution is 2 inches per second.

Now what about the acceleration? The acceleration resolution is the position resolution divided by the update date time squared. Therefore the if the position resolution is 0.001 inch and the sample time 1 millisecond the minimum acceleration resolution is 1000 in/sec^2 which is not usable.

If you can get 1000 times the resolution that would be good. There are encoders that will provided 100,000 to 500,000 counts revolution. The encoders cost about $1000 but the return is in less waste.

I have found that the reference or master encoder must have high resolution. It is key because the rest of the system is geared to it. We obviously use the master encoder for calculating the slave position and velocity but we also calculate acceleration. Acceleration feed forwards are very important for getting up to speed quickly and stable for the cut.

The saws cutting differently in different directions is a mechanical problem. You probably have the same gains going both directions so unless the saw is moved by a single rod hydraulic actuator there is a mechanical problem.

Can you capture trends or graphs and post them here?

 

[AJZ]

Thanks, Peter

Attached is an Excel file of captured data. Pieces are cut to 36" and the line runs at 52FPM.

Both the carriage and saw are controlled by servo motors. I suspect that they are tuned poorly to compensate for design deficiencies.

 

[Peter Nachtwey]

Good graph! The positions and velocities look stable enough

What I like to see is the target position and velocity as well as the actual position and velocity. Then the errors between the target and actual position and velocity can be seen.

It looks like the controller is using only linear, velocity ramps instead of s-curves. Use s-curves if you can. It looks like there is time. It is hard on the machinery to do the abrupt velocity changes I see in the carriage and saw velocity profiles. The acceleration profiles would not be smooth. The accelerations would just be step changes.

Look at your line encoder data in the spread sheet. You see that the velocity changes in steps. That is due to the low resolution of the encoder. It would be very difficult for the slave to use the derivative gain with these kinds of step changes is velocity. The velocity resolution looks like it is 1.26 inches per second but in reality it is much worse. The controller probably updates every millisecond. You need to figure out how many counts the controller is getting per control loop not over 10 control loops.

Get the target data too.
You are getting about 400 counts/in*10 inch/sec=4000 counts per second or only about 4 counts per millisecond. Because of line and sample jitter you are going to usually get about 4 counts per millisecond but every once in a while you will get 5 or 3 counts per millisecond. Each control loop the controller can see a 25% change in velocity! The derivative will never be useful under those conditions. If your controller updates every 0.5 milliseconds the situation is even worse because now the controller will see 2 counts most of the time and 1 or 3 counts some of the time. That is a 50% change!

I made this worksheet for Chris Elston on mrplc.com years ago. I have kept it around because this resolution issue comes up so often
http://www.deltamotion.com/peter/Mathcad/Mathcad - t1p1 pid mrplc.pdf
You can see I am comparing a 2^17 count encoder with a 5000 count encoder. You can see the encoder resolution makes a big difference in the control out. A real physical system would not like the noisy output of the 5000 count encoder. To reduce the noise one would have to reduce the gains.

The gains can be higher with a higher resolution encoder and therefore the following error is less.

 

[AJZ]

Another trend file that has the carriage following error included.
Two other files has data when a tuning profile was run. The tuning looks bad to me. The following error is large.
The motion controller has limited memory for trending. It lowers the sampling rate when more channels (Max 6) are activated or total time is increased. Next time I am on site, I will capture more data.

 

[Peter Nachtwey]

Yes, the tuning is very poor but what can you do?

It looks like only PI tuning is being used, no feed forwards, no derivative gain. I can tell because the control output doesn't change radically with the change in speed from the reference encoder.

It would be nice to use the derivative gain but the encoder feed back is so coarse the derivative gain would probably cause more harm than good.
It would be nice to use feed forward gains too but how can you when the master encoder has very low resolution too?

Buy decent encoders. Get one with no less than 10,000 ppr if you are cheap but 100000+ ppr will pay for itself in reduced waste an increased quality.
Only after getting the new high resolution encoders should you spend time tuning the system. Trying to tune what exist will not be productive because the gains can't be cranked up high enough to do any good. A hi res encoder will allow you to use feed forwards and crank up the PI AND D gains.

BTW, the control output does go to about 50% so there is plenty of capacity in the motor and drive. It just requires a good feed back signal.

 

[kamenges]

You may be giving them too much credit, Peter. It looks to me like the motion controller is using only proportional control. If I scale the position error by a factor of 17 it lies right on top of the DAC output. So they are going P-only on the motion controller and PI in the drive. I'm not sure how you usually split these since you don't want two integrators in the control path. I'm guessing you go PI in the motion controller and P-only in the drive, but I'm guessing. This is obviously the other way.

It would be interesting to see the drive torque output relative to the velocity command. The drive is definitely not following the DAC output very well. So even if the aplication was using the velocity feed forward term it wouldn't be following it. This would indicate that drive tuning is currently more important than motion controller tuning.

Having said that, the spreadsheet does seem to contain a reasonable velocity demand value. This has to be coming from somewhere. From what I can tell it has about a 0.1 inch/sec/scan "dither" on it (+/-0.05). At the very least I would make this a contributing member of the DAC output.

Keith

 

[AJZ]

Following the last two replies, I checked the controller (Next Move ESB 2) gains. For the carriage servo, they are:
' Gain terms
KPROP.0 = 0.2000
KINTMODE.0 = 1
KINT.0 = 0.0000
KINTLIMIT.0 = 100.0000
KDERIV.0 = 0.0000
KVEL.0 = 1.0000
KVELFF.0 = 1.0000
KACCEL.0 = 0.0000
'Profile parameters
SPEED.0 = 20.00
ACCEL.0 = 50.00
DECEL.0 = 50.00

For the saw servo, they are:
' Gain terms
KPROP.1 = 0.2500
KINTMODE.1 = 1
KINT.1 = 0.0000
KINTLIMIT.1 = 100.0000
KDERIV.1 = 0.0000
KVEL.1 = 2.0000
KVELFF.1 = 6.5000
KACCEL.1 = 0.0000
'Profile parameters
SPEED.1 = 125.00
ACCEL.1 = 200.00
DECEL.1 = 200.00

And from the help file:
KPROP = Proportional Gain
KINTMODE = Integral Gain Mode
KINT = Integral Gain
KINTLIMIT = Integral Gain Limit
KDERIV = Derivative Gain
KVEL = Velocity Feedback Gain
KVELFF = Velocity Feedforward Gain
KACCEL = Acceleration Feedforward Gain

I do not have the drive parameters. The drives (H2 VS1SD models)are rather sophisticated units but they are used as dumb drives in this application. But it looks like the drive set-up is in-correct.

So they are going P-only on the motion controller and PI in the drive. I'm not sure how you usually split these since you don't want two integrators in the control path. I'm guessing you go PI in the motion controller and P-only in the drive, but I'm guessing. This is obviously the other way.

I like to know too how these functions are usually split. All my experience is with integrated servo drives (Parker, AB U3K and AB K6K)

 

[kamenges]

My bad on the velocity feed forward thing. I neglected the fact that the plots were tuning plots. If you look at the actual move plots you can see that the carriage steady state velocity is already incredibly noisy.

I'm with Peter. You need much more encoder resolution so you can develop a reasonable velocity command to follow.

Keith

 

[Peter Nachtwey]

Just to show the difference between using a hi resolution encoder ( 0.0002 in/count) ) encoder and AJZ's lo resolution encoder ( 0.250941 in/count )
http://www.deltamotion.com/peter/Pictures/HiResEncoder.png
http://www.deltamotion.com/peter/Pictures/LoResEncoder.png
I am providing links to my site because I didn't want to trim these down to 800x600 or what ever the limit is.

I set the simulator so the simulator control outputs were similar ( system gain ) to those in the excel work sheet.. I had to guesstimate a system time constant. I used 0.02 seconds which may be a little fast but the band width of the machine is about 8 Hz. The flying shear program I have 'canned'. I just changed the cut length and the line velocity to 36 in and 10 in/sec to match AJZ's
I used the same gains in both graphs. I used PI control velocity AND acceleration feed forward. The derivative gain would not work with such coarse feed back. The control output looks 'noisy' enough as it is. Notice the light purple target acceleration plot. A heavy shear would go nuts trying to follow that or respond to the acceleration feed forward component of the drive.

The control output ( green line ) is very noisy. It doesn't affect the simulator that much but I bet it would excite higher frequency poles in a real system

My simulator takes into account the quantizing of the feed back. In the first post AJZ mentioned there are 398.5 counts per inch and since his cut length is 36 inches I set the position unwind for the master to be 36 inches and the count unwind to be 36*398.5=14346 counts.

 

[AJZ]

What if I am really cheap

Buy decent encoders. Get one with no less than 10,000 ppr if you are cheap but 100000+ ppr will pay for itself in reduced waste an increased quality.

Peter,

What do you think if I replace only the line/master encoder with one that has 131072 PPR? (One revolution is 12" of travel) But keep the existing carriage encoder that provides 1725 counts per inch travel.