PID Troubles

View attachment 46660

This is about 35 minutes of data

White -overall system production rate
Red-master setpoint
Green-CV (PID output)
Pink-PV ( flow directly after auger)

Note, you can see that the overall system production rate begins to oscillate on the far right due to the PID control of the auger. I know that my PV doesn’t match my CV but this is only due to the way the data is manipulated for the historian. They match in the PID.

View attachment 46661

The CV and the PV don't match, as they are apples and oranges (RPM vs KG/Min). The SP and the PV should be similar. However, it looks like your SP is similar to the production rate, not the flow rate.

Use the trend in RSLogix instead of your historian.
Trend N152:2 (SP), N152:14 (PV), and the CV.
 
You were right! I knew something outside the PID was causing this!



Check to see if there is anything writing to the N addresses involved in the PID function. That could be something in the PLC5 ladder logic or from an HMI panel.

I’ve found the cause. Further downstream, there is another process and then a hopper. The hopper low limit switch sets the auger PID output to 60 (almost 0, considering the output is 0-4950) when the level gets too low. Unfortunately, whoever designed this didn’t understand level control. When the hopper level hits the low limit switch, my auger PID setpoint goes to 60, and the PID mode is set to SW simulate for exactly 1 second. The system dead time then takes its 20 seconds, and the low limit of the hopper goes away. BUT as soon as the hopper level gets above the low limit, the system ramps all the way back up to normal speed, and quickly empties the hopper again and so the loop continues over and over.

As a temporary fix, I plan to change this so that:
1. My auger speed is reduced much less dramatically, maybe in steps as necessary
2. My hopper will then fill to level much higher than the low limit
3. Once this undetermined level is met, my augers will go back to normal rate.

I’m sure this will reduce the dramatic oscillations. However, I will still see the system speed up and slow down at some interval.

The best solution may be to tune the second process so that my hopper doesn’t hit the low level. I haven’t gotten far enough into it yet to know how it is controlled. Either way, once I get this somewhat stabilized, I can go upstream to the beginning of the process and increase feed rates (master setpoint).

I really can’t describe this whole process on here, but there’s many PID loops, all in series. Probably none of them are very well tuned. I honestly don’t know the best way to get them to all work together. Any advice on all this would be greatly appreciated!
 
I really can’t describe this whole process on here, but there’s many PID loops, all in series. Probably none of them are very well tuned. I honestly don’t know the best way to get them to all work together. Any advice on all this would be greatly appreciated!

perhaps a master line speed that ramps up to drive all the processes in series?

I worked in a tire plant with a lot of sheet processing machinery and we had some that had several variable speed drives in series processing stock with slack loops and festoons in between. This new line we had was a little out of control since each station had a PID that could "get to bouncing" if the upstream or downstream station reached a high or low limit. There was nothing inherently wrong with the design and logic from the OEM, each station was its own little world and only used the loop it was feeding as the process variable...simple is good right? not always...

The solution was a master line speed that drove everything, sort of like a virtual axis in motion control...each station then used that master reference multiplied by a scale factor and a trim factor. Each station PID would only affect its trim factor so they could be individually tuned and limited for their individual characteristics.

At the end, the machine was actually capable of producing the quality and quantity in the original spec that the OEM could not achieve, so I was the hero to both companies for spending many days and weeks getting this all ironed out.
 
perhaps a master line speed that ramps up to drive all the processes in series?

I worked in a tire plant with a lot of sheet processing machinery and we had some that had several variable speed drives in series processing stock with slack loops and festoons in between. This new line we had was a little out of control since each station had a PID that could "get to bouncing" if the upstream or downstream station reached a high or low limit. There was nothing inherently wrong with the design and logic from the OEM, each station was its own little world and only used the loop it was feeding as the process variable...simple is good right? not always...

The solution was a master line speed that drove everything, sort of like a virtual axis in motion control...each station then used that master reference multiplied by a scale factor and a trim factor. Each station PID would only affect its trim factor so they could be individually tuned and limited for their individual characteristics.

At the end, the machine was actually capable of producing the quality and quantity in the original spec that the OEM could not achieve, so I was the hero to both companies for spending many days and weeks getting this all ironed out.

I am sure you made the company a boatload of money! That’s pretty much my goal. I have the opportunity to be the “hero”. If I can increase average kg/minute by 10, I will definitely make my superiors happy. I have a feeling I may run into a bottleneck or two.

I like your thought process... Isolate each process and tune to its capabilities, then control each process by a master rate factor. Theoretically each integrated process should self regulate. Am I following correctly? Obviously my overall process is NOT setup this way currently. I don’t even know if it’s capable at this point. But with a few select hardware changes....

Any chance you could PM about the scale and trim. I guess I’m not sure exactly that means. Why not make it a % so there’s no scaling, just multiply. Please forgive me if I am misunderstanding.
 
I am sure you made the company a boatload of money! That’s pretty much my goal. I have the opportunity to be the “hero”. If I can increase average kg/minute by 10, I will definitely make my superiors happy. I have a feeling I may run into a bottleneck or two.

I like your thought process... Isolate each process and tune to its capabilities, then control each process by a master rate factor. Theoretically each integrated process should self regulate. Am I following correctly? Obviously my overall process is NOT setup this way currently. I don’t even know if it’s capable at this point. But with a few select hardware changes....

Any chance you could PM about the scale and trim. I guess I’m not sure exactly that means. Why not make it a % so there’s no scaling, just multiply. Please forgive me if I am misunderstanding.

In my case, the master line reference was a percentage if I remember right, then the scale factor and trim factor at each station were real numbers. The scale factor was adjusted and left static at a value so that when the trim was a value of 1.0, the surface speeds of each section would match at any master speed.

The PID for each section only controlled the trim number and I had a couple of other variables that limited how much trim could be applied at each station. I may only allow a range of 0.8 to 1.2 at one station for trim, but another might allow 0.2 to 2.5 (the center driven winder at the end of the line was like the latter).

The scale factors were all over the place simply due to the mechanically gearing of different sections, more of a configuration value that got set once and left alone...

The speed command math at the end of the speed logic in each station was line_spd * scale_factor * trim_factor

My system was sort of easy to implement because it was one big machine with a PLC5/80 and a bunch of remote I/O at each station, so all the logic was in one place and the hardware they had in place was pretty much good to go. I did end up swapping out some sensors for better quality for loop height detectors between some sections, but aside from that it was all keyboard magic.
 
The CV and the PV don't match, as they are apples and oranges (RPM vs KG/Min). The SP and the PV should be similar. However, it looks like your SP is similar to the production rate, not the flow rate.

I would say that the controller output does in fact represent a flow rate of Kg/min as for a given steady controller output there will be a fixed speed of the auger. Assuming the auger is full then the auger will pass a flow rate proportional to the instantaneous speed. So auger speed and mass flow are indeed related.

Looking at the graphs you uploaded it seems to me that the controller output changes before the PV changes and so this implies that the controller PI function is being bypassed and it's output is being directly over ridden.
 

Similar Topics

I'm using a PID loop instruction in a Floboss 107 RTU for an oil and gas application. There are two loops, a primary and override loop - primary...
Replies
3
Views
3,718
I have set up some "PID_Temp" loops in a 1517F3 processor and they seem to work ok. For pressure and flow rate I've used "PID_Compact". The issue...
Replies
2
Views
2,595
I have S7 1512C controler for controlling 48 PID temperature loop, the output is PWM. Please I need the best, most efficient way to write the...
Replies
5
Views
218
Hi all, I'm having trouble solving a problem I've been working on for several months, and thought you might like a stab at it. The machine runs...
Replies
22
Views
851
How can I connect PID Output to a valve. In ladder logic program is there any logic do I want to add between valve and PID? PV=SP What will be the...
Replies
7
Views
384
Back
Top Bottom