PID Implementation - Developing a plan

[BobLfoot 302]

The "power that be" have decided that we need a PID loop to control the speed of a Vibrating Bin Bottom in a dry material transfer process. The Process Variable will be the Fluid Pressure Reading in PSI of the Transfer Piping. The Control Variable will be the Speed of the Vibration Generating Motor in hertz. I know from visual observation of the system that it can take 30 to 90 seconds before a change in speed produces a change in pressure. I am questioning whether a PID Loop will do any better tnat the Bang Bang Up/Down Control we have now. Any experts with thoughts?

[Guest]

IF (that's a big IF) the input and output signals are already connected to the PLC, then it shouldn't be too hard to disconnect the present control logic and plug in a PID loop in its place ... the tuning is probably going to be a bear - or maybe even impossible - but at least a day or so of experimenting should arm you with some charts full of squiggly lines to prove your point ... (survival tip: trend graph the present control response before you change anything) ... quick question: once the present system stabillizes (assuming that it eventually does) how constant does the speed remain from then on out? ... specifically, does this thing constantly "hunt" back and forth to control the output - or does it eventually find a "happy place" and pretty much settle down? ... and finally ... what type of PLC ... and how are the I/O signals presently scaled? ...

[BobLfoot 302]

Let's see if I can tackle your questions Ron. All of the present Input and Outpuit Signals go thru a ControlLogix PLC so you're right swapping the present control for a PID based module is not an issue, I was even planning on a test_toggle Flag bit to allow for quick fail back. To answer the rest of your issue let me see if I can describe the system a little bit better from source thru target. 1. We have Two Supply Bins Number2 and Number3 they both hold granulated sugar. 2. Each Bin has a vibrating bottom to feed sugar into a drop tube and into a De-lumping unit. 3. The De-lumper output is feed to a flatbed sifter where oversized particles are eliminated and Sugar drops out the bottom. 4. The bottom exit of the sifter is a Pocket Rotary Valve moving at a fixed speed. 5. The Rotary Empties into a Delivery Pipe filled with air by a positive pressure blower. 6. The Pressure in the Delivery pipe is monitored by a module which returns a value between 0 and 15 PSI with 7.5 pis as the optimal target. 7. The delivery pipe fills the selected target bin from among several available. The present control system is as follows: The motor for the Vibrating bin bottom starts our at 30 hertz. Once every 10 seconds a one scan adjust speed pulse is given. If the pressure is below 6 psi the the hertz are increased 0.75 hz. If the pressure is above 9 psi the hertz is decreased 1.5 hz. Bin 3 stablilizes just fine around 45 hz for delivery to bin 58 and around 60hz for delivery to bin 60. as examples. Bin 2 on the other hand some months ago began ramping all the way top 75 hertz and then the pressure would jump from 5 to 15 and hi pressure safeties would shut everything down. The mechanical gurus swear up and down "nothing has changed" but the two bins refuse to behave alike any more. And the Big Boy Decision Makers now want a PID on Bin 3 Vibrator. I think this is all an exercise in futility, but maybe I'll find the smoking gun when I begin to look hard at what's going on. Tuning will be a bear if darn near impossible. But your suggestion of trend data give me a great idea. I've got an INSQL Server just waiting to sample this system 1/sec for the next couple weeks.

[Rod_Hackney 2]

With a long delay you stated, you might want to look at the advance process control addons for ControlLogix. I ran into a system we had to replace the PID with the IMC control in order to tune the long delay. When we used a PID, we had to detune the loop so much to get it to work that large process upsets did not respond fast enough.

[Peter Nachtwey 15]

Yes, you need a Smith Predictor to do this right. I would also use a feed forwards too. The IMC tuning is PID tuning that takes into account the dead time but it doesn't work very well if the dead time is long compared to plant time constant.

[paulengr 44]

I smell Accurate feeders. Which are anything but. The bane of my process engineering existence. Run away if you can. If not... Bin vibrator type feeders are highly nonlinear in their response. It's sigmoidal (exponential at low speeds, and then inverse exponential at close to maximum). Forgetting dead band, you will have an incredible amount of trouble trying to tune this thing at all because your system gain is variable, and very much so. Plus the response itself not only has deadband but it's also exponential in nature. Also as it is highly sensitive to the flow characteristics of the material (which are frequently time varying), tuning even this is a nightmare. These things are difficult to adjust and control by hand to any level of control/accuracy. Don't expect any better under automatic control. Expect that if you get anywhere, you will spend weeks trying to get it to respond with any reasonable level of accuracy and reliability. The best thing I can suggest you do which gives you a really good, easy response that is very amenable to PID control is to insert either a belt weigh feeder system or a screw feeder system. Both will give you nice, smooth responses that are very linear if designed correctly. You can still use this to feed to your vibrating feeder and then simply set it to wide open so that it dumps everything out. I highly suggest you forget about even trying a PID. IMC is also a linear controller and won't work either. This is exactly the realm where sliding mode controllers work, with one slight modification. In practice I've found that you need to use exponential backoff on the speed decreasing direction but that linear is acceptable on the increasing direction. You are going to have to trade off reaction rates for control, and if you aren't using mass flow hoppers on your bins and/or air slides if deaeration is a problem, good luck because surging due to ratholing or bridging will be a huge issue. I strongly suggest you talk to Jenike and Johansen about your bin SYSTEM, not just the feeder. They are experts on material feeding problems. They are somewhat expensive but I've found that if you just follow their recommendations, it works every time with fantastic results.

[Pulsar2003 0]

I don't know if I can be of any help here. I want to point out that I haven't read all the questions and answers, only the opening topic. If I understand well the project is still on paper. I work in the plastic industry where we also have some dry material. To be more precise it's a pulverizer. Check the link: http://www.kevoshod.ca/samples/Orenda/ we have the model: H1D 500. In order to have the plastic beads to fall into pulverizing chamber there is a Vibrator (on the picture that is the minuscule orange part beside the yellow cylinder). We can adjust the percentage at which we will mill. Also once the process is activated there is what I believe to be a ramp to increase the process. There is an analog output that connects to a solid state relay which acts like a dimmer on a light. This PLC is a GE Fanuc and I don't have the software to upload the ladder to study it. Depending on the size of your bin could there be a simpler way to shake?

[Peter Nachtwey 15]

What is the real goal? Is it to deliver material at a desired rate or to move it at a desired rate? If there was a bin at the end where the material can accumulate then the material can be controlled at the bin. The speed control of the conveyor would not be that critical as long as the bin had enough material at all times.

[paulengr 44]

OK, you've given a lot more details now. What you described is definitely not linear. Using a PID controller will drive you insane from experience. This is more akin to internet congestion control algorithms and I recommend you look at these for ideas. With internet traffic, the goal is for each packet stream to maximize the bandwidth usage but the exact maximum flow rate is unknown (and time varying), and there's no way to directly detect this anyways since it would require coordination among multiple potentially unreliable streams. So what is used in practice is AIMD...additive increase, multiplicative decrease. That is, there is a known safe speed increase rate but overshooting is catastrophic. Once you exceed the maximum traffic volume, everything comes to a screeching halt very quickly. I'm sure you've seen similar phenomena in real traffic as well. The trick here is that up until the point where the system becomes overloaded, everything is more or less linear. But traffic jams in real life, as well as across the internet and with dry transport systems, result in exponentially increasing congestion (or by analogy, plugging). Your current algorithm is really close to what's needed. But, you need to make two changes. First, feed the changes more quickly. You set your timer at 10 seconds. Cut this to 2 seconds and cut the additive increases to 0.1 Hz. This gives you identical ramps for increasing but increases the frequency of the scans. For decreases since plugging is an exponential problem, you need to respond in kind with an exponentially decreasing response. You don't use a fixed amount. On the first decrease (aiming now for 7.5 PSI, not 6-9), decrease again by 0.1 Hz. On the second round, decrease by 0.2 Hz. Then 0.4 Hz. Keep doubling on every correction until you get it under control. Or alternatively, and this may be more effective for your situation, cut the timer in half on each check where you have to decrease things. PID control cannot do this because it's linear.

[paulengr 44]

The following paper is the one on congestion control that I was thinking of. It is very enlightening when you think about how it relates to your current system: http://ee.lbl.gov/papers/congavoid.pdf Just throw away all the "discretizing" stuff and pay special attention to the extremely large footnotes because the problem that Van Jacobson was trying to solve is very similar to the one that you are encountering, and provides a very clear engineered solution to it. There are LOTS of extensions to the original TCP congestion/flow control algorithms out there which improve on the basic Van Jacobson design but none seem to be as applicable.