Uncoiler strip guiding with PLC – application issue

[jim767]

Hello all. Anyone got experience or can share some knowledge on how to do this. I’ve got a new application where I am guiding metal strip from a uncoiler. Normally we have a edge sensor located near the coil and control the uncoiler with a PID controller and a servo valve to a hydraulic cylinder in a closed loop. The edge sensor is located prior to the deflection or break roll (first roll downstream of the coil which the metal bends over). The sensor reads the error then moves the uncoiler over to eliminate the error. This works very well. I now have a application where the sensor has to be placed after the break roll due to space limitations and will be using a AB PLC. I know from discussions with other engineers and reading website descriptions that I will have to implement a position control scheme instead of a normal closed loop due to the increased distance from the uncoiler to the sensor and being after the break roll. Also the tendency of the break roll to restrict lateral movement of the strip. From what I have put together, a position control scenario would measure the error at the sensor, lets say .25” then move the uncoiler .25” in the opposite direction to correct the error. In this case we would have to have a position feedback sensor on the uncoiler to measure the correction distance. It all sounds too simple but evidently won’t work unless you compensate for the increased delay time for the metal to reach the sensor since it’s much further downstream. This would especially be a problem at low line speeds. From research I have found some suggestions that the sensor signal error can be placed in a PID block as the PV with set point at zero. Use a line speed signal to ramp up the proportional gain and set the Integral at some fixed rate. Subtract the scaled CV value (not sure how to scale this) from the position feedback signal of the uncoiler to produce the signal to the servo valve. Anywhere I look has very limited detail on this control scheme. Any knowledge to add? Thanks!

 

[kamenges]

I suspect Peter Nachtwey will jump in on this one. He would have some pretty good ideas on this.

I suggest you start by use a proportional only controller on this unless you suspect you are going to have a large amount of valve or cylinder leakage. With a PI loop you will effectively have two integrators in series; one in the PI loop and one in the physical plant (fluid flow into the cylinder). This can be hard to control, especially given the deadtime.

You may want to look at the Control Guru website. There is a pretty good tutorial there about dealing with first order plus deatime systems. The tutorial develops some tuning correlations that may be of help to you.

As you correctly state, since you are looking at the position of the strip after the break roll the web will not reposition as quickly as you expect. The generally held number to achieve cross-machine web stabilization after cross-machine displacement is 5 web spans (pretty familiar number, eh). Again, as you correctly state, the time involved in this changes with web speed.

I think you might want to look at this a bit differently also. This isn't so much a deadtime issue as a changing system time constant issue. As soon as you shift the unwind the web at the backing roll will start to shift. It will just take much longer for it to fully shift to the new position of the unwind than it would if the sensor were just downstream of the unwind. As you look at the tuning correlations think in terms of how the gains are affected by long system time constants.

You may want to look into something similar to a Smith Predictor to try and compensate for the deadtime. If nothing else that may give you some ideas on how to proceed. This may be overkill for what you are trying to do though. If you move away from an integrator in the control loop simply modifying the proportional gain based on machine speed may be enough in your system.

Keith

 

[Peter Nachtwey]

Thinking.

This will require executing the PID as a function of line speed instead of time and the current sensor error will need to be put in a fifo. I think the bias should be set to what ever the sensor current error times a scale factor or gain. The output of the PID is the command position to the hydraulic cylinder. This will cause much of the error to be correctly quickly. The PID should use the sensor error that has been delayed by the fifo that is long enough to store errors for the distance between the coil and the sensor. The PID is updated only when there is a new sensor error available in the fifo and this should happen as a functon of line encoder counts. This way the PID will slow down as the lines slows down. The bias gain will speed up response at the expence of perhaps being too reactive. The total control out will shift from the bias to the PID as the error is reduced. The integrator term should drive the error to 0 eventually. The trick here is that we are delaying the error that the PID sees so the PID doesn't over react.

 

[jim767]

Thanks. I'm reviewing the guru site. Alot of good info there.

Peter, I think I understand your methodology with the exception of the bias. I'm going to look at a PID ladder block in RS5000. Should I set it to dependent or independent? Your response is still closed loop control is it not? All others I've seen use the position feedback from the uncoiler.

Jim

 

[Electrically_Bound]

This will require executing the PID as a function of line speed instead of time and the current sensor error will need to be put in a fifo. I think the bias should be set to what ever the sensor current error times a scale factor or gain. The output of the PID is the command position to the hydraulic cylinder. This will cause much of the error to be correctly quickly. The PID should use the sensor error that has been delayed by the fifo that is long enough to store errors for the distance between the coil and the sensor. The PID is updated only when there is a new sensor error available in the fifo and this should happen as a functon of line encoder counts. This way the PID will slow down as the lines slows down. The bias gain will speed up response at the expence of perhaps being too reactive. The total control out will shift from the bias to the PID as the error is reduced. The integrator term should drive the error to 0 eventually. The trick here is that we are delaying the error that the PID sees so the PID doesn't over react.

I have a lot of projects before me and one of them is updating the web guide system on one of our sheeters. Your post contains a lot of good ideas. Because of time contraints, this probably something that I will deal with using equipment designed explicitly for this purpose. Nevertheless, I learned a few things from reading your post. I never really thought about executing the PID as a function of line speed instead of time - that makes a lot of sense.

 

[Peter Nachtwey]

Thanks. I'm reviewing the guru site. Alot of good info there.

Peter, I think I understand your methodology with the exception of the bias.

The bias is just a way to get an immediate proportional response. I said the bias should set to the current error times a gain proportional gain. This effectively allows for two proportional gains. One that is multiplied by the current error and the other PID proportional gain will be multiplied by the delayed error. When the bias is set to the current error times a gain this allows for a little faster response.

I am just suggesting using the bias so you can have two proportional gains. One delayed, one not.

I'm going to look at a PID ladder block in RS5000. Should I set it to dependent or independent?

I don't think it will make much difference.

Your response is still closed loop control is it not? All others I've seen use the position feedback from the uncoiler.

Yes, this is closed loop. The hydraulic position controller must be able to go to the position which is set my the PID control output. Ideally one should be able to measure an error. For instance 0.25 inches. The PID would then tell the hydraulic controller to go to .25 inches and the error is corrected. However, it there is still an error of 0.01 then the PID integrator term will eventual wind up to tell the hydraulic position to go to .26 inches. The delayed PID just correct for any non-linearities or offsets without over correcting.

 

[kamenges]

Originally posted by Peter Nachtwey:

The bias is just a way to get an immediate proportional response.

This is probably a good idea. Because of the way webs track you should be able to make an imediate correction in the correct direction. The web won't move like a snake unless you are going around several rolls between the unwind and the sensor. If you have the unwind, one roll and then the sensor, the web at the sensor will start to move as soon as the unwind starts to drag it. It will just take some time for the web at the sensor to fully assume the new unwind position. If you are going around several rollers between the unwind and the sensor then you need to be a bit more careful. The web will act like a snake, effectively anchoring itself at each roll and allowing semi-independent motion on either side of it.

Given Peter's suggested system with an outper loop based on the web position error feeding a position command to an inner loop controlling the actuator position, you will definitely need an integrator in the outer loop. Most commercial web guide systems perform proportional velocity correction only. The integrator is the actuator itself. So when the error goes to zero the correction goes to zero and the edge guide actuator holds position regardless of where it is at. In your case when the error goes to zero the unwind will return to zero position, counteracting the correction you just made. Since you nee to include an integrator you will certainly need to be very mindful of the points Peter made in his initial post about controlling the call frequency of your outer loop.

Keith

 

[Peter Nachtwey]

Given Peter's suggested system with an outper loop based on the web position error feeding a position command to an inner loop controlling the actuator position, you will definitely need an integrator in the outer loop. Most commercial web guide systems perform proportional velocity correction only.

Yes, you could add incremental error to the hydraulic position by telling the hydraulic position to make relative moves. I think that using the integrator in the PID is easier because the PID control output is an absolute position for the hydraulic controller to go to. This allows for more control in the outer loop. It also allows one to user the current error for quicker response by using the current error and telling the hydraulic positioner to close the error quickly.

 

[kamenges]

The trick will be keeping your integral time constant/PI execution rate right so that the integrator grows at the same rate the bias fades. If you get it right you will most likely see the unwind make an imediate correction and then move only very little after that. This is probably where the PID execution based on distance traveled is a big benefit.

Keith

 

[jim767]

If I set up the execution of the outer loop PID as a function of line speed, how does this affect the Integral timing in the PID.
To perform this would it be correct to ramp up the "loop update time" in the RS5000 PID block? You guys are great, to bad I'm a novice here. thanks

I'm looking at how I would set up a FIFO scenario in RS5000. Any suggestions.

Currently I having a simulator stand built so I can run this.

 

[jim767]

Peter or Keith I have my test stand built and the system appears to be functioning as you said. Could you clarify when you said it will require executing the PID as a function of line speed. Currently I have this done by varying the loop update time .UPD - Is this correct? If not could you tell me how. Thanks

 

[Peter Nachtwey]

Think about gearing. Everything works as a function of distance or velocity,not time

Peter or Keith I have my test stand built and the system appears to be functioning as you said. Could you clarify when you said it will require executing the PID as a function of line speed. Currently I have this done by varying the loop update time .UPD - Is this correct? If not could you tell me how. Thanks

Are you varying the update time as a function of line speed?
If so how?

My gut tells me to think differently. Think in terms of executing the PID distance intervals rather than time intervals. This means where every you see minutes in the PID block you should mentally replace that by feet, inches or meters, feet will probably do. This means that the udpate interval will be in feet. Let's say 1 foot. Now the PID should only be called every time 1 foot has gone by. This means the PID is geared to the line speed. If the line stops the PID will not be updated. The PIDs output is a positon for the hydraulic controller. The hydraulic controller should make corrections as a function of line speed ( be geared ). If the line stops you don't want the hydraulic actuator to keep correcting. You want the hydraulic actuator to stop correcting too. The amount of correction should be determined by the PID but the rate of correction needs to in proportion to the line speed.

Fun!!! If I wasn't having so much fun I would be jealous.

 

[coolblind]

I think the only problem when a sensor is placed far away from the correction actuator is the BIG delay in the system. There are a lot of methods about how to tunning the PID in the absence of the pure system delay, since I am dedicated to regulate the web tension but not guiding, this is the only thing I can say by now.

But have you take a look at this edge(positon) sensor: http://www.fife.com/fife_products_fife_se22.asp ? This is what we are using on the web line, I think it is small enough, if, somehow, you can manage to install a sensor near the unwind roller, you just come back to the beginning point in your post, right?

 

[OkiePC]

I can only recommend sensors:

Two first hand favorites (with no personal preference):

1. fife controls (already mentioned) makes really good stuff;

2. as does (did) Harris Instruments, which I believe is now owned by North American mfg... I have used THIS one with flawless reliability, even though we were using analog signals to get the values from the system to a PLC5, the accuracy was well within 0.5mm in a rubber web measuring/guiding application for over two years without recalibration.

Harris Instruments designed this system for the steel milling industry, and it is very industrial.

Paul

 

[Peter Nachtwey]

I think the only problem when a sensor is placed far away from the correction actuator is the BIG delay in the system.

This has been covered somewhat above. I would use a queue to shift the errors down but if the dead distance ( dead time ) is small one can use the same formula as what is found on www.controlguru.com.