AB PID - Cannot "reset"

Hi folks, so... firstly I have setup a hydraulic pressure test system. The system is used to pump up a volume to a set pressure - i.e. if we need to test at 10000psi, the operator will put in 10000psi to the SCADA and the system will pump up to this with an air driven pump - the air supply for the pump is electronically regulated (0-100psi) which "linearly" controls the output of the pump (0-30000psi).

I have programmed a ramp up to approx 80%* in line with our required ramp up requirements, then a PID function kicks in to take us up to set value - this works nicely.
*Reason its 80% is because the pumps are not very linear and can very quickly (<1sec) kick to over pressure - over pressure is considered as 5% above the set value.

I say it works nicely… it does the very first time the system is used... i.e. right after I have uploaded the programme to the PLC. After the pressure test is complete and vented down, we will inevitably perform another one with the system, however I notice that despite enabling the PID.SWM bit and "MOV"ing 0 to the PID.CV and PID.SP as soon as the PID is not in use, the PID function flickers between 0 and an old value (from the first time the PID was used) when monitoring on Studio 5000. Subsequently, the next time the PID is used (when the PID.SWM is disabled and the output is used) the system does not react properly (the pressure spikes before the PID can catch it (it looks as if the output flickers between 0 (from the MOV function) and the max output...

The PID is on its own live rung. It is clocked with a counter set at 50ms which matches the PID settings. While the ramp up is taking place (non PID, the .SWM bit is =1 and I do not use the PID Output. Once the ramp is finished, I then clear the .SWM bit to 0 and use the output of the PID. As I say, this works great the first time.

I'm happy to say I’m a beginner with Studio 5000 and PLC PIDs, it’s almost like I need to reset or clear the PID, which I thought I was doing by moving the 0's into the .CV and .SP.

Unfortunately, I left my work laptop in work so don't have the logic to show - I've had my head buried in this for a few days so let me know if that doesn't make sense...

Do you think its factoring in past values? Do you think you should force the error to 0 when its not in use?

Do you have the tieback connected?

Are you using PID or PIDE?

Hi Oysterman - I'll give it a go, I assume this would bring the output down to 0 i.e. as per the start up.

Hi Ken - no not using the tieback..

I was talking about 'forcing' the error by changing your SP to your PV

Ken Moore said:

Do you have the tieback connected?

Are you using PID or PIDE?

Click to expand...

Using the PID in ladder logic.

Since you are in fact bypassing the PID in a manual way. Then I think you should connect the tieback to the analog output so the PID will know the position of the control element. Then use the .MO bit instead of .SWM to place in manual.

Per the PID instruction documentation this will cause the PID loop to adjust it's internal calculations to match the physical output, so when you go to auto, it should be bump less, and start controlling smoothly.

i am first off, a novice to pid loops, but i have a question.
to me, the idea of a pid loop is for continuous control, not an on 1 minute , off 3. i can be totally wrong, someone please correct me if i am.

i have had several applications in which i had to make my own pid loop.
for example, apply 1,000 lb force to an object to see if it movs.
1. set an initial pressure
2. apply weight
3. use 50 ms to 1 second timer
4. after timer expires, look at pressure.
5. add to pressure (increment)
6. goto step 2
7. keep track of the pressure for the next cycle. reset the data when the machine goes to manual of turned off.

8. when you are done, retract with some pressure.
you should be within +/- 50 lbs in 5 cycles.
why 5 cycles, the oil temperature. it has to heat up. and you do not want an exact fore to start with, something may go wrong the first cycle.
james

a different approach ...

first things first ... let me see if I've got this straight ... you want to use/execute a PID control for "awhile" ... then you want to deactivate or quit using the PID for "awhile" ...

then – eventually ...

you want to start using the PID control again – BUT – you want the PID to always start back up from "scratch" ... in other words, you want to cancel out ANYTHING and EVERYTHING that the PID might remember from the last time that it was executed ... specifically, the PID should always start up from a "fresh out-of-the-box" condition ...

IF (big IF) that's what you're looking for then the following approach might do the trick ...

note that I used this approach back when I had to teach basic PID troubleshooting to maintenance technicians ... there were many situations where the class would finish one hands-on exercise – and then need to start over again from scratch with the next experiment ... this "system reset" worked perfectly in the classroom – and MAYBE it will meet your needs too ...

the basic idea is to set up a completely extra/separate PID control block EXACTLY like the one that "works OK" ... suppose that your working PID is named PID_Control_Run ... you might name the new extra PID something like PID_Control_Raw ... note that this PID doesn't get a rung or any other type of programming to ever execute it ... basically it just sits silently in the controller's memory – and serves as a storage space for whatever "startup" settings you want to use ...

then ...

write a "reset" rung to COPY the "raw" PID on top of the "run" PID whenever you want to do a reset of your system back to the "out-of-the-box" conditions ...

see if this makes sense – and maybe it will work as well for you as it always did for me ...

keep in mind that if you make changes to any "tuning" settings, etc. then you'll have to make the same changes to the extra PID too ... this might drive your co-workers nuts – so be sure to document the system appropriately ...

EDIT: the easiest way that I found to create the extra PID was to add it on a new rung - and then delete the rung leaving the PID memory block in place ...

party on ...

When the loop is in software manual (.SWM set), the set output (.SO) input is used to "pass-through" the desired manual value to the CV. In addition to clearing the loop after the test, there is a benefit to using the SO while ramping: when you switch to auto (.SWM cleared), the loop will provide a bumpless transfer. (You must either have integral gain set or bias-back-calculate with P-only for this to work.) The "bumpless" is in the context of no output bump before the first update. If there is SP/PV error at the auto transition, that will create an apparent bump due to the initial PID action.

Also, on these ramp-to-auto situations, there is a minor detail in timing of the last ramp update. You will not get the last update if it occurs on the same input-true scan of the PID as when the SWM bit is cleared. The bumpless behavior uses the SO from the previous input-true scan of the PID when the SWM transitions from 1 to 0. You may not notice this if the ramp increments are relatively small.

Plantationpark said:

however I notice that despite enabling the PID.SWM bit and "MOV"ing 0 to the PID.CV and PID.SP as soon as the PID is not in use, ... it’s almost like I need to reset or clear the PID, which I thought I was doing by moving the 0's into the .CV and .SP.

Click to expand...

1) What is the actual sequence of operations performed in the code?

1.1) e.g. are PID.SWM, PID.CV, and PID.SP all changed (to 1, 0, and 0) on the same scan when enabling software manual?

1.2) what is the sequence when PID.SWM is changed from 1 to 0?

1.3) Are these changes scheduled to happen on the pulse that normally triggers the PID calculation every 50ms, or can they happen on any scan?

1.3.1) If they execute on the scan with the pulse, do they happen before or after the PID calculation?

1.4) Is there any difference in this sequence between the first time after the PLC program is loaded, and the second i.e. when the kick occurs?

1.4.1) Specifically, is the PID.SP 0 before or during, or after, the first time PID.SWM is changed from 1 to 0 at the end of the 80% ramp?


2) Why is PID.SP ever being changed?

2.1) I.e. OP states above that it is changed to 0 when "PID is not in use;" I assume that means when PID.SWM is 1. When is it changed back?

2.1) And perhaps more importantly, is PID.SP ever being changed while PID.SWM is 0? Stated more specifically, does the PID ever detect a change in PID.SP while PID.SWM is 0?

2.1.1) Or are they changed at the same time?

2.1.2) This is my guess at the reason for the kick (this is probably saying the same thing as @Mispeld in post #10).

2.2) What happens if only PID.SWM and PID.CV are changed, and PID.SP is not?


3) What are the tuning parameters (Kc/Kp, Ti/Ki, Td/Kd)?


[Update: lots of iterations on this post; also, has anyone ever stumbled onto this diagram: https://literature.rockwellautomati...e/documents/rm/ra-rm002_-en-p.pdf#G10.1042368? wow.]