PIDE - Basic (VERY basic) “Bumpless Transfer” Setup in RSLogix5000

Ron Beaufort

Lifetime Supporting Member
Join Date
Jul 2002
Location
Charleston, SC
Posts
5,701
Greetings to all ...

I got this in a PM the other day ... since the question is a rather common one, I decided to answer it here in the open forum where hopefully it will benefit more than just one reader ...

The ProgValueReset bit

Hi Ron,

When going over the pdf of PIDE States Modes you posted some time ago I still have my mind unclear about a little issue...The ProgValueReset bit: is it for setting it to true in the exact point of time at which I toggle the auto mode to manual? Is it like that how we avoid the bumping when we operate this change from auto to manual? I also understand that additionally the PVTracking bit must be set to true. Is this right?

I'm just implementing all the knowledge I've been gathering from your posts and from other members of the forum too in my first project using the PIDE instruction and so far it is going fine unless for this little issue I've not been yet able to solve by myself.

Thanks again for you attention and your time at reading this,

I don’t have time to go through the entire setup for PIDE but I’m attaching some material that I’ve been developing for an upcoming class for a customer ... these are basically “lab notes” for use in hands-on exercises – and NOT a “textbook” ... please note that this is NOT completely finished – but maybe it will be helpful ... also, if there are any typos, etc. please feel free to point them out ...

the PDF file attached shows enough (hopefully) about how the “control bits” should be set up in order to gain AUTO and MANUAL control – both WITH and WITHOUT “bumpless” transfers between the auto and manual modes ...

before we go any further, here’s my personal opinion on the use of “bumpless” transfers ... sometimes it’s a good idea ... at other times it’s a bad idea ... I’ve actually heard of a few cases where a programmer has gone to a fair amount of effort to provide bumpless transfers – and then had to go back later and remove that capability when the operators complained about it ...

suppose that the system being automatically controlled has a well-established setpoint which never (or at least hardly ever) needs changing ... let’s say that the automatic setting is 350 degrees just to have a number for discussion ...

now suppose that from time-to-time the operator needs to put the system into manual operation – and that the manual setting is also well-established and hardly ever needs changing ... let’s say that the manual setting is 20% just to have a number for discussion ...

so – day after day – the operator runs the system in automatic – and occasionally switches it over to manual operation ... basically all he has to do is flip a switch from one mode to another – and if there happens to be a “bump” when going from one mode to another, then that’s quite OK (at least for THIS particular system) ...

next a young programmer “new and improves” the system – and along the way “bumpless” transfer gets incorporated ...

now look what happens the next time the operator flips the switch into manual mode ... instead of getting the old familiar 20% value for the output, now he gets whatever value the system happened to be running along at the instant the change to manual mode was made ... so now, instead of just flipping the “manual” switch and going on about his business, the operator is forced to tweak and twiddle an extra control to dial in the desired 20% output ...

and ...

the next time the operator flips the switch into automatic mode, instead of getting the desired 350 degree setting, now the setpoint stays at whatever value the system happened to be running along at the instant the change to the automatic mode was made ... once again, instead of just flipping the switch into “automatic” and moving on, the operator has to tweak and twiddle yet another extra control to dial the setpoint back to where it’s supposed to be ...

disclaimer: notice that I am NOT saying that “bumpless transfer” is a dumb idea ... in some (in many?) cases it’s completely NECESSARY ... all I’m saying is that just because it “sounds cool” is no reason to set it up on every system that comes along ...

anyway ... see if the attached files make sense, and if you have any specific questions, please ask them here on the open forum where others can benefit – especially from what other forum members can add to the conversation ...

Figure 1 shows a BASIC DOWN-AND-DIRTY set up WITHOUT bumpless transfer ...

Figure 2 shows another BASIC DOWN-AND-DIRTY set up – this time WITH bumpless transfer ... notice that the HMI/SCADA is connected directly to the INTERNAL addresses of the PIDE control – and does NOT use input references for the Setpoint or the Manual CV settings ... if you decide to use input references, you’ll probably have to come up with some means of disconnecting them when they’re not being used ... with many HMI/SCADA systems, if you use them and leave them connected, they’ll tend to overwrite any “present” values that the PIDE tries to store – which usually defeats the “bumpless transfer” idea ...

Figure 3 shows a trend of a system with “bumpless transfer” – based on controlling the Air Flow section of the Ramrod simulation that we’ve discussed before ... from A to B the system is under automatic control – and “on target” ... at B the setpoint is changed from 20% to 40% of full flow ... at C the system has settled down at the new setpoint ... at D the system is switched to Manual mode – notice that the CV (orange) holds steady at its present value ... in other words, no “bump” to the system when going from auto mode to manual mode ... at E the CV is manually moved to a new setting ... notice from D to F that the Setpoint is hidden behind the PV (blue) ... during that portion of the trend, the setpoint is “following” or “tracking” the PV ... at F the system is switched back to the Automatic Mode ... notice that the Setpoint (yellow) holds steady at its present value ... in other words, no “bump” to the system when going from manual mode to automatic mode ... at G the setpoint is manually raised to a setting of 40% ...

hope this helps ...

FLOW_1.PNG FLOW_2.PNG FLOW_3.PNG
 

Attachments

  • PIDE_setup_charts.pdf
    91.8 KB · Views: 825
more pictures ...

Figure 4 shows a trend using PI control ...

Figure 5 shows a trend using PID control ...

Note: these last two figures have nothing to do with the “bumpless transfer” question at hand, but personally I just like looking at these types of squiggly lines ...

FLOW_4.PNG FLOW_5.PNG
 
Ron:

I don´t use ProgValueReset bit, but instead copy CV to CVoper when in auto, and PV to SPoper when in manual, so when changing from man to auto or viceversa the change is smooth, Is that ok ??
 
Greetings Bill ...

sure ... if it works and it’s safe ...

in very basic terms, the ProgValueReset bit tells the PIDE to “reset” (to ZERO) certain other bits each time the PIDE gets executed ... it also sets up a copy from the CV location to the CVProg location ... that can certainly also be done in other ways ...

in my personal way of looking at things, the PIDE has a LOT of extra bells and whistles that many (most?) systems never need ... at a “technician” level, the biggest part of making sense of this animal is finding out:

(1) which of these things are actually being used? ... and
(2) what effect are they having on the system’s operation? ...

programmers who like (or even LOVE) the Function Block Diagram approach often say that it makes things easier to visualize – since you can follow the signal from block to block ...

other people hate the way those same signals often appear to tie themselves in knots when going from block to block ...

personally, I don’t get involved one way or the other in the “good/bad” debate ... I’ve got customers who (for better or for worse) have this stuff in their programs ... I’m just trying to give their technicians enough understanding about it to keep the machinery up and running ...
 
Thanks Ron, for having posted such a detailed answer to the question I adressed to you .
Now after having spent some time reading thoroughly at it, I can say I have understood the basis of the "bumpless transfer" idea. And so far, my control process isn't such critical that I should implement all this on it. But it's been well to have understood what was it about for possible and future occasions that I might make use of it.

And thanks Widel for letting us know about your approach to the bumpless transfer. Truly interesting too.

So all is clear now, and no more questions by now
icon14.gif
icon7.gif
 
Ron,
Thanks for posting the very comprehensive article on PIDE, I'm sure it will be of great assistance.
One small thing though, you say
"the next time the operator flips the switch into automatic mode, instead of getting the desired 350 degree setting, now the setpoint stays at whatever value the system happened to be running along at the instant the change to the automatic mode was made", I don't quite agree with that, classic bumpless transfer doesn't modify the Setpoint, just ensures that the Output doesn't make a sudden jump. Your setpoint should have remained at 350°. If it changes in manual, that's Setpoint tracking.
Regards
Roy
 
Greetings Roy ...

regarding your comment:

I don't quite agree with that, classic bumpless transfer doesn't modify the Setpoint,

I certainly won’t argue with you over that ... I suppose I should have been more specific – but I actually DID try to make the point in the title of my earlier post that I was outlining a “Basic (VERY basic)” approach to “Bumpless Transfer” ... I actually had no intention of covering the subject any deeper than a “just getting started” level ...

consider this ... when the PIDE instruction is first placed into a Function Block Diagram, it pops up with 32 “connections” ... now some of these are essential – but quite a few aren’t necessary to achieve basic control of the process ...

now then ... when you take a look at ALL of the parameters this thing has available, the list includes 84 inputs and 81 outputs – for a total of 165 “bells and whistles” ... that’s more than enough to bewilder anyone who is just getting started ...

and so, I was just trying to break things down into what someone (particularly a beginner) really NEEDS to know – and pass over the rest (at least in the beginning) ...

classic bumpless transfer doesn't modify the Setpoint, just ensures that the Output doesn't make a sudden jump. Your setpoint should have remained at 350°.

technically you’re correct ... the trick is to recognize what different people mean by the term “bumpless transfer” ... for SOME people it means (either rightly or wrongly) exactly what I illustrated in Figure 3 ... specifically, NO BUMP to ANYTHING ... more specifically, when going from Manual to Automatic (or from Automatic to Manual) NOTHING changes until and unless the operator dials in SOME TYPE of new setting ...

along those same “terminology” lines, the figure below illustrates what “bumpless transfer” means to a FEW people ...

back when I worked as an “answer man” for an Allen-Bradley distributor, I actually had a customer phone in because he was having problems achieving what HE called “bumpless transfer” ... when I finally (much later) nailed it all down, he was actually describing what most people call “overshoot” ... he had come across the term “bumpless transfer” in reading the book ... to him the response looked like a “bump” – and he was trying to eliminate the “bump” by tuning the PID ... (no, I am NOT making this up) ...

If it changes in manual, that's Setpoint tracking.

again, you’re correct ... and you’ll see that I incorporated the PIDE_01.PVTracking control bit and set it to a ONE status on pages 3 and 4 of the PDF file in my first post ... you’ll notice that I didn’t even show it at all on pages 1 and 2 – since I was (again) trying to keep things boiled down the very basic ideas ...

finally, I don’t think there’s any real disagreement between what you and I are saying – just possibly a difference in terminology ... along those lines, I’ll certainly admit that your terminology is more correct than mine ...

thanks for bringing this up ...

PS Edit ... I really do NOT want to confuse anyone ... please note that the terms “bump” and “bumpless” shown in the figure are NOT correct ... (there's a certain amount of humor intended in the picture) ... the CORRECT terms would be “overshoot” and “no overshoot” ...

bump_bumpless.JPG
 
Last edited:
bumpless transfer without changes in setpoint

...what I originally understood as the concept of "bumpless transfer" was rather the avoiding of bumps when toggling between both the auto or manual options and without having the need to make any changes in the setpoint, as Roy said...so I'm wondering now how this specific way should be deployed in the PIDE function block...too away from the tips given by Ron ??

Thanks in advance.
 
Greetings buhnen ...

I’m not 100% sure that I understand what you’re asking – but here’s a guess ...

try leaving the bit for “PVTracking” off (ZERO) and see if that helps ... keep all of the REST of the settings the same way that I showed in that earlier post ...

with those settings, the “CV” should still be moved into the “CVOper” location during AUTO MODE (just like before) ... so when you make the change from AUTO MODE to MANUAL MODE, the system will continue running along from its present output ... in other words, it should “hold steady” ... therefore, no “bump” should occur when going from AUTO to MANUAL ... (basic “bumpless transfer”) ...

then while you stay in the MANUAL MODE, with the “PVTracking” bit left off (ZERO), the “SPOper” location will not be updated ...

so ...

later when you finally switch back to the “AUTO MODE” the original setpoint will still be in place ... at that time the “tuning” of your loop will determine how quickly – or how slowly – the process will try to get back to the setpoint ... if the tuning isn’t too aggressive (too “fast”) , then there probably won’t be a “bump” when you go from the MANUAL to the AUTO MODE ... in other words, the tuning will cause the system to just gradually go back to the setpoint ...

if this isn’t the answer you’re looking for, you might want to post again with some extra details on what you really want to happen ... or maybe some of the other forum members will be able to help ...

note that in some cases, the setpoint has to be “ramped” gradually from one setting to another – to give the process a chance to react slowly over a period of time ...

I hope this helps ...
 
Last edited:
PIDE bumpless transfer

Greetings Ron...

And thanks for the answer: yes,it was all what I needed to know. Next week when I have the chance I'll test both configurations for the PIDE (with and without steady Setpoint)just for studying how my loop behaves on state control transitions auto-manual-auto.

In the end it was so easy as unselecting the PVtracking bit. So one more doubt cleared! (y)
 
Greetings buhnen ...

I’m not 100% sure that I understand what you’re asking – but here’s a guess ...

try leaving the bit for “PVTracking” off (ZERO) and see if that helps ... keep all of the REST of the settings the same way that I showed in that earlier post ...

with those settings, the “CV” should still be moved into the “CVOper” location during AUTO MODE (just like before) ... so when you make the change from AUTO MODE to MANUAL MODE, the system will continue running along from its present output ... in other words, it should “hold steady” ... therefore, no “bump” should occur when going from AUTO to MANUAL ... (basic “bumpless transfer”) ...

then while you stay in the MANUAL MODE, with the “PVTracking” bit left off (ZERO), the “SPOper” location will not be updated ...

so ...

later when you finally switch back to the “AUTO MODE” the original setpoint will still be in place ... at that time the “tuning” of your loop will determine how quickly – or how slowly – the process will try to get back to the setpoint ... if the tuning isn’t too aggressive (too “fast”) , then there probably won’t be a “bump” when you go from the MANUAL to the AUTO MODE ... in other words, the tuning will cause the system to just gradually go back to the setpoint ...

if this isn’t the answer you’re looking for, you might want to post again with some extra details on what you really want to happen ... or maybe some of the other forum members will be able to help ...

note that in some cases, the setpoint has to be “ramped” gradually from one setting to another – to give the process a chance to react slowly over a period of time ...

I hope this helps ...


I know this is an old post, but this is just the question I have. I specifically want my output to jump to the new value as determined by my PID calculation.

I know this may seem crazy, but I am using this as simply a MAN/AUTO station and when in AUTO, I want my CV to follow the PV (or SP, I'm not picky) and when in MAN I want the CV to follow the CVOper. Setting the Proportional Gain to 1.0 and the Integral and Derivitive to 0.0 accomplishes most of this, but when going from MAN to AUTO, the PIDE calculates the difference between the CV and the calculated so that the output doesn't jump (bump). I believe there was a function in the PID instruction that prevented this (the .NOBC bit?), but I'd like to stick witht the PIDE.

I know there are other ways to do this, but I'm a slave to consistency and I'd rather use the PIDE than building my own logic.

Any help would be appreciated.
 

Similar Topics

Greetings ... someone sent me a request for some student handsouts that I developed ... turns out that I had this hosted on my business website...
Replies
0
Views
132
Have a logix controller and I'm using the PIDE block for the autotuner. I've got the hang of doing it for direct control things like pressure...
Replies
21
Views
1,766
Studio 5000 version 34. Have error on PIDE CVFaulted (Status1.2), Control variable (CV) health bad. No more information online or in...
Replies
3
Views
967
Hi everyone, I am trying to add a control loop to my HMI interface however I keep getting the following issue, any idea why this would happen?
Replies
8
Views
1,613
We have a routine that we trigger with a JSR every 10 seconds that has PIDE instructions. This resides in a Periodic task that triggers every...
Replies
6
Views
922
Back
Top Bottom