CLX PID control using line speed parameter

Any suggestions to this are appreciated. I am thinking about setting up a PID loop (I'm new to PID and PLC stuff, take it easy on me if you will). Anyway, I want to set up a PID where I have a detector output as the PV and a actuator in closed loop to place a web back to the center of the detector (SP). Since the configuration of the guiding mechanism will not produce immediate movement of the web and would cause overshoot, there is a need to create a time lag and this needs to be based on the line speed. There is a prox switch on one of the rolls which can be fed to the PLC. Would it make sense to place a bit instruction for the prox signal on the same rung of the PID instruction or can someone suggest some other method using the prox.

One item I thought about was, what if the line stopped and the bit was true keeping the PID active, the actuator would just keep moving, not good. Is this where a one shot could be used.

Thanks

Jim,
Can you please tell us more about the physical setup
Is this a typical unwinder using a dancer to maintain web tension?
Or are you trying to steer the web when the web is in motion?

Michael, actually this is a bowed roll spreader for fabric which stretches. Not sure what a dancer is. When the bow's curvature is parallel to the fabrics passline the most spreading action is performed. When you move the bows angle the fabric will not immediately change its width therfore the need to produce some time lag or stepping action by the actuator or move then wait, check how far off, then move and wait again.

Jim, I have not come across this application before but here goes.. I am still trying to get a handle on the physical setup. You have a stretch fabric that must have a controlled width into the rest of the machine? The Fabric width does not change unless the fabric moves forward. The feedback sensor is measuring the edge position of the fabric a short distance downstream from the bow roll (hence the transport delay).
Some Other Questions - What response are you expecting from the system? Get there quickly or reasonable time but be very accurate.
Do you have a web length measurement system available (Can we use travelled web distance to determine when to update the output Controller?)

The PV is the measurement of the Web Width
The SV is your setpoint or target Web Width
The CV is the controlled variable - in your case the output for the PID probably would be a angle for the Bows Roller

Yes, a stretch fabric with a controlled width. the detectors right after the bowed roll say 12 inches give the PV value. Again correct, a controlled width into the rest of the machine and the fabric width does not change unless there is line speed. Reasonable time but maintain accuracy is best. The proximity switch is located on the bowed roll so basically update would be about two or three revolutions of the roll or four to six pulses of the prox. I would like to vary this update through the operator interface for tuning. If the system ran in straight closed loop it can not be stabilized. The CV would be a actuator which changes the bowed roll angle which can be adjusted with the actuator for no spread or full spreading action.

Jim, There are others here that are better at control Theory than I am but I think that I can help you to get a simple system going which they can improve on. Basically its what you have already said, Every 12 to 14 inches of Web that passes snapshot the FB and make a correction to the angle based on that snapshot. Practically there are some things to think about 1) The web distance measurement - This is best measured on a pinch roll using an encoder or Prox. Not the bending roll which I think could slip on the web sometimes. 2) The Actuator that determines the bowed roll angle is best to be closed loop - I.e. when you want 5 degrees you get 5 degrees. The alternative is open loop - controller needs a little more/less bending, make the change and then wait until the change in fabric width is seen. 3) If you have a PID running, the Integral term is time based. In your application I believe that you would be better off freezing the integral term whenever the web speed is below a tuned value. Integral is PID Setpoint correction that gets the accuracy.

The current setup has rolls in tandem and mechanically linked which will not let the fabric slip. Number 2 in your reply is what I believe will work the best. The system does have a position transducer on the actuator but I would like to control by a closed loop approach not a position control type which evidently was used on older systems but I don't quite understand how it was accomplished. The later stuff not using a PLC uses a controller with a primary loop which uses the position transducer for input then uses a secondary loop which the input is the fabric width detector. The primary loop holds the actuator to a midstroke position while the secondary uses the detector input to step the actuator from this position in proportion to the error and timing steps with line speed or fabric distance using the prox switch. I would like to accomplish control with a PLC, not necessarilly using this method because I would think a closed loop would work as long as I can turn off and on the CV based upon the prox signal pulses to accomplish the time lag needed to let the fabric width change happen before the angle is changed to much. Hopefully I am not way off on this but would like someone to tell me if so. I will be on this job for the next week so I apologize if I can't respond quickly but will try to get logged on to my email there. I appreciate the responses.

Jim, the existing system that you are describing is a "cascade" PID controller. There are two loops - The inner controlling Angle, The outer controlling the web width. That is the type of control system that I would be using.
The inner loop MUST be at least 10 times faster (prefer 20) than the outer loop. This allows the outer loop controller to assume that between one snapshot and the next the change in position reference to the inner position loop is complete. eg Outer loop requests 2 degree change - position Change is complete within 1/10 of the cycle time of the outer loop.
Inner Loop
PV - Position transducer Angle
CV - Actuator reference - Speed to a motor (zero to hold stationary) OR two outputs (Increase angle, lower angle Both off to hold stationary)
SP - Controller Reference ANGLE (during tuning you set manually in the PLC - When you engage the Cascade, the reference comes from the Width Controller in the outer loop)
NOTE: This loop runs always, it is totally independant of what is happening on the web.
Outer Loop
PV - measured Web Width
SV - Setpoint Web Width
CV - Angle Reference to Inner Loop
NOTE: This loop is dependant on Web movement to see a change in width - This loop "Freezes" the integral when the web speed is slow

There are extra things to think about in cascade controllers - If the Inner loop is unable to control (eg at end of travel) then the outer loop must inhibit the integrator from winding up) - Sometimes Ramping the reference between the loops provides better control - I think that I have seen this well discussed elsewhere.

MichaelG said:

Jim, the existing system that you are describing is a "cascade" PID controller. There are two loops - The inner controlling Angle, The outer controlling the web width. That is the type of control system that I would be using.

Click to expand...

What I think has been missed is jim767's concern about the 'dead time' between detecting the width and after the actuator changes the bow.

The inner loop MUST be at least 10 times faster (prefer 20) than the outer loop. This allows the outer loop controller to assume that between one snapshot and the next the change in position reference to the inner position loop is complete. eg Outer loop requests 2 degree change - position Change is complete within 1/10 of the cycle time of the outer loop.

Click to expand...

What do you mean by 10 times faster? Do you mean the loop update or the time constants.

NOTE: This loop is dependant on Web movement to see a change in width - This loop "Freezes" the integral when the web speed is slow

Click to expand...

Why?

There are extra things to think about in cascade controllers - If the Inner loop is unable to control (eg at end of travel) then the outer loop must inhibit the integrator from winding up)

Click to expand...

The output of the outter loop should not tell the inner loop to go outside of its limits.

- Sometimes Ramping the reference between the loops provides better control - I think that I have seen this well discussed elsewhere.

Click to expand...

Not between the outter and inner loop. That effective sloops down the response of the inner loop. That doesn't jive with your earlier statement about the inner loop being fast.

Jim's feel for the problem is good. He knows the dead time is a problem. MichaelG is right about the dual loop. The problem with the dead time has been solved in many industries. MichaelG is also right about 'freezing' the loop.

This is not an easy problem. I will think about this, but to me this is somewhat obvious. The PID update rate for the outter loop must be done as a function of line speed or distance the line has traveled. This answer the problem MichaelG said about freezing the output the integral. If the line stops and the PID is updated as a function of the line speed then the integral is frozen. There is also a matter of the 'deadtime' this should be rephrased to be the 'dead distance'. I hope this is understandable.

Yes, I wondered when one of the best would dip in into this thread. Glad to see your input Peter.

What I think has been missed is jim767's concern about the 'dead time' between detecting the width and after the actuator changes the bow.

Click to expand...

Not missed, just not detailed, waiting for additional support - I was concentrating on the control basics

What do you mean by 10 times faster? Do you mean the loop update or the time constants.

Click to expand...

For Cascade loops we are talking time constants. These Loop setups are strange so I was trying to give jim a pointer as to update rates

Quote:
NOTE: This loop is dependant on Web movement to see a change in width - This loop "Freezes" the integral when the web speed is slow
Why?

Click to expand...

Hmm a bit of a rethink here - If Stopped then definitely freeze the integral (Stop the integral from moving angle as the feedback will not change {we know this as the web is stopped}) When Moving Slowly then the integral time must be stretched (I have another thought regarding this see next reply)

There are extra things to think about in cascade controllers - If the Inner loop is unable to control (eg at end of travel) then the outer loop must inhibit the integrator from winding up)

The output of the outter loop should not tell the inner loop to go outside of its limits

Click to expand...

In this Case I was thinking to a Gas Fired oven that I setup - cascaded loops, inner loop was gas fire control, outer loop was oven temperature (never had gas exhaust in the oven due to heat exchanger with burner) Outer loop had a Max output that was the limit of the burner (oven supplier construction limit)
During Startup the Outer loop integral would wind up because the inner loop was on full burn (inner CV on Max) on but not yet to max temperature - Control :If the inner loop is on the a limit (Max CV, Max SV), then hold the integral on the outer loop because we are no longer controlling the process ( Note: loops tuned using RS tune, SLC platform)

Not between the outter and inner loop. That effective sloops down the response of the inner loop. That doesn't jive with your earlier statement about the inner loop being fast.

Click to expand...

Not there - I was meaning the outer loop ramped its output (smart PID's do this eg PIDE in controlLogix CV ) so that the inner loop was not hit with a step change and the outer loop is aware of the rate limiting

Back to Jims Problem

Inner Loop
I think that both Peter and I agree that this is a bacis Position Control loop reference Angle and operates all the Time
Outer Loop
This is the interesting one - Up for Discussion please!
Peter, Is it better to change "time" base here to mm of Web travel, This removes the integrator wind up effect when stationary and the integral speeds up the faster the web moves. It naturally freezes the controller when stationary and slows the response at slow web speeds
ASSuMEptions - Web width change is linear (or nearly) with distance travelled. Specifically a 1 degree change in angle gives x mm change in width over y mm of web travel

MichaelG said:

For Cascade loops we are talking time constants. These Loop setups are strange so I was trying to give jim a pointer as to update rates
Hmm a bit of a rethink here - If Stopped then definitely freeze the integral (Stop the integral from moving angle as the feedback will not change {we know this as the web is stopped}) When Moving Slowly then the integral time must be stretched (I have another thought regarding this see next reply)

Click to expand...

This is why I think the outer loop should be done as a function of distance. This means the PID gets updated every 6 inches or so of distance traveled instead of by timer periods. The time constants are now 'distance constants'. I know it seems weird. By using 'distance constants' you will not need to worry about the line stopping or slowing down. You must think in terms of distance instead of time when dealing with the outer loop.

When tuning a system you can predict how long it will take the PV to reach the SP. In a 'distance based' PID one can predict how far the line will travel before the PV reaches the SP.

I just returned from the project and briefly skimmed over the latest responses of which I greatly appreciate. This also is very interesting to me on the best method to provide control although I will need to disseminate your responses and see if I can understand them. Just to update on what I had performed while at the project since I briefly was able to work with this amongst other things. I have set up a bit triggered from the prox switch, then sent this to a counter which I can vary the preset from the HMI. The DN bit will change the SP of the PID instruction when preset is reached. The set point calculation value is 50% of the angle of the bowed roll position (0-10vdc) or 5 volts at a constant plus the error value from the center of the fabric detector (4-20ma) or value from 12ma. I've actually taken the output of the detector and subtracted 12 which gives a +8 to -8 range which 0 would be the final value if on center of the detector. My process variable is the position transducer 50% stroke position. I did not yet get to completely try the logic but I did get to run the PID instruction and the angle went to the 50% position when toggled. The pulses did update the SP of the PID as instructed. I did not have a polarity of something set correctly or possibly a PID parameter at the end the actuator completely stroked out. I am going to set up a detector andactuator in the office for further research.

Does anyone have a example of the cascade control in ladder?

Jim, we do not know your PLC platform (ie brand and model)