Sign in to follow this  
Followers 0
Jeevan

Retentive Bits

29 posts in this topic

In one of my process i have to continue the process from where it left of after a power failure/interruption so i need to retain bits states inside the CONTROLLOGIX PLC is their any specific method of programming to retain the bits or is it more simpler than that like just clicking the check box to retain all the required bits. My progam is almost completed and its a very big program with over 16000 tags so it would be very difficult to modify the program to retain all the required bits. It would be gr8 of all u PLC experts out there if u help me out. Thank u all in advance bcos i know there is a solution coming up very soon from u all. Jeevan

Share this post


Link to post
Share on other sites
As far as I know, all bits will retain their last state during a power cycle

Share this post


Link to post
Share on other sites
Don't know about the CLX line, but in the older PLC's only the latched outputs were retentive, I'll have to look into the bit question. If we're lucky Ron B. will chime in with a detailed response.

Share this post


Link to post
Share on other sites
Perhaps I am understanding what you mean by a retentive bit. I have heard some complain about AB values not going to a "default" value during a power cycle. If a bit is on, it doesn't even actually have to be addressed in the program, and the power is cycled, the bit will still be on when the PLC powers back up. Am I out in left field? And yes, an answer from Ron would definately help. - The birds are singing, the trees are blooming.....

Share this post


Link to post
Share on other sites
With all of our machines programed with RSLogix5000 We have no problems with Latch bits resetting after a power cycle. We use Logix5561 and Logix5555 some with 2 processors in the same rack.

Share this post


Link to post
Share on other sites
Any bit referenced by an OTE instruction will be reset (turned off) on power-up. It may come back on immediately if the rung conditions are right. Bits referenced by OTL & OTU instructions retain their previous state and are not changed on power-up (assuming the battery isn't flat). Again, rung conditions may make immediate changes after power-up. Counters retain their accumulators, TON & TOF do not, RTO does. Results from math and move instructions do not change unless rung is true.

Share this post


Link to post
Share on other sites
Greetings to all, before we begin, thanks to Ken Moore and to TWControls for the kind compliments ... and it looks like Gerry, in just a few concise sentences, has already nailed down almost everything that I'm about to say ... and so if you're short on time, just read his post and get on with your life ... but since I've already typed it, I'm going to post it ... so without further ado, here's my "overkill" take on Jeevan's problems ... first of all, Jeevan, please don't be offended if the following seems to start out with very basic information ... if you've written a program with 16,000 tags, then I'm certain that some (most? - all?) of this is going to be "old news" to you ... but it's a pretty safe bet that some of your questions will eventually be asked by someone else in the future ... with that in mind, I'm going to start out with some basics just for their benefit ... Jeevan said this: so now let's go back to the output module's "Properties" and set the "Program Mode" settings back to their default values of "Off" ... things are confusing enough without that particular onion being thrown into the stew ... {B} now let's go back to the simple program ... again, suppose that we're in the "Run mode" ... suppose that both "Pump A" and "Pump B" are currently turned On and are running fine ... suppose that we power-cycle the system ... since the system has no power applied, of course the two outputs both go Off ... now suppose that we turn the power back on again ... in that case, "Pump A" (controlled by the OTE/seal-in rung) will be turned Off ... specifically, it won't come back On unless someone goes over and presses the Start button ... but "Pump B" (controlled by the OTL/latched) rung will be left On ... and so we've "retained" the "On" status of the bit controlled by the OTL ... but NOT the status of the bit controlled by the OTE ... so now let's try to nail down what (I think!) Jeevan is trying to do ... specifically, let's try to make the NON-retentive OTE instruction "act like" a RETENTIVE OTL instruction ... here we've added two new rungs to the program ... and we're not showing the latch/unlatch rungs just to keep things as simple as possible ... now let's try our experiments again ... {C} suppose that we're in the "Run mode" ... suppose that "Pump A" is currently turned On and is running fine ... suppose that we power-cycle the system ... since the system has no power applied, of course the output goes Off ... now suppose that we turn the power back on again ... in that case, "Pump A" (controlled by the OTE/seal-in rung) WILL come back up in the On condition ... bingo! ... specifically, the OTE rung now acts like an OTL rung ... {D} one more time and we're finished ... again, suppose that we're in the "Run mode" ... suppose that "Pump A" is currently turned On and is running fine ... suppose this time we don't power-cycle the system ... instead we only go to the "Program Mode" and then go right back to the "Run Mode" ... again, "Pump A" (controlled by the OTE/seal-in rung) will come back up in the On condition ... specifically, the OTE rung now acts like an OTL rung in this scenario too ... and now the sun is shining ... the birds are singing ... life is lovely ... the "how does this work?" ideas are covered in the rung comments ... so read those carefully and post again if you have any further questions ... finally ... a great big WARNING! ... please remember that we haven't seen your program and we know little or nothing about your system, so all we can do is offer general ideas ... if you decide to implement this approach, think VERY CAREFULLY about any and all safety implications involved in what you're doing ... some things simply should NOT be programmed as retentive ... other things SHOULD BE ... one size does NOT fit all! ... when you get right down to it, if the RIGHT WAY to fix your problem happens to be REWRITING the entire program, then you should certainly consider doing exactly that ... while the approach that I've outlined above MIGHT take care of things, it also might also be regarded as simply putting a Band-Aid on the underlying problem ... sometimes you've just got to bite the bullet and do the right thing ... but anyway, I hope that this helps ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
Again a most usefull post by Ron B Qyick question..along the same lines.. Can a timer keep timing during a power outage?? Say i have to bake something for 20 mins..oven temp is perfect and the product has been in for 15 mins..(Now i know the over will retain its heat for say 15 mins before begining to drop off)..Now power fails for 3 mins..hen power is reaplied do those 3 mins still count?..or will the cycle continue for the remainder 5 mins.. (Yep i know about RTO just wondering if the RTO still ticks when power is off..never tried it myself....) D

Share this post


Link to post
Share on other sites
sorry, but no ... but if you really HAD to track something like this, you could record the time from the processor's WALLCLOCKTIME when the system shut down ... and record it again when the system started back up ... then do some math ... that way you COULD keep track of the time which had been lost ... it would probably be easiest to do this by working with the "CurrentValue" attribute instead of the hours, minutes, etc. values ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
No, the RTO will not continue to tick when the PLC is turned off. Just off the top of my head, if I had a situation that it need to shut off in 20 minutes no matter what, I believe I would log the start time and then look for the current time to be 20 minutes greater than the start time. And thanks for the great response Ron. I always look forward to reading your post Edit - And on top of all of that, you beat me to the post. As you once said - Must type faster, must type faster, must type faster. You win this one Ron Edited by TWControls

Share this post


Link to post
Share on other sites
Thanks Ron, I was hoping you would respond, you're the best at explaining the nitty gritty operations. Just a quick comment, I have used something similar to your data buffer on the PLC-5's using the first scan bit, if not first scan, move bits to an N file, if first scan true, move from the N file to the bits. If you used something similar in the CLX, couldn't you reduce the PLC load slightly, you would only be moving the data from the buffer when it was needed. I'm not saying your method is bad, just curious if my old method would work the same in the CLX line of processors.

Share this post


Link to post
Share on other sites
Ron - Can you clarify a few things for me. I think I am understanding you correctly but what to make sure. If you have an unconditional output statement, you are saying that on power up, the output is turned off during the power up, then it is not turned on until the end of the 1st scan. Is that correct? For an output that is not referenced in the ladder (just has a 1 in the data value to turn it on), would this fall under the same category as a latched output?

Share this post


Link to post
Share on other sites
Greetings TWControls, I only have a few minutes, but I think that I'll have time to answer your questions ... Ken's will take a little bit longer ... I'll get back to those ... yes ... the status of the bit/box would "retain" a 1 ... because the processor would have no "instruction" available to tell it to turn the bit/box back to a 0 ... that concept drives a LOT of electricians NUTS when they first try to deal with PLCs ... "but they told me that this OTE thing works JUST-LIKE-A-RELAY-COIL" ... big problem ... if a "true" rung has an OTE on it, then the bit/box has a 1 in it ... and the output is ON in the field ... now delete the rung ... the bit/box STAYS a 1 ... and the output in the field stays ON ... that's NOT the way a relay coil works is it? ... nope ... when you disconnect a relay coil, the durn thing turns OFF ... gotta go ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
Wow Ron, you can take a few minutes and turn it into amazing explanations. I appreciate your time and thank you for the excellent education. Although I have gotten a few hints from your post, if you don't mint me asking what exactly does your job involve? And though I am not trying to swell your head too much, you are absolutely the best at nailing down the details of how things work

Share this post


Link to post
Share on other sites
Power the PLC from a UPS, but make sure that any pertainent code that could be dangerous knows that the power has failed and acts appropriately.

Share this post


Link to post
Share on other sites
HI Ron B, Whoever u r, u r really great, since it has given me a direction to think on to implement the solution for my problems successfully. Any how Ron i like descriptive tech stuffs from experts like u. Short on time right now but will join the discusssion once again later Also a final thank u to all of u all TWControls, Ken, Gerry and all who took part in the disscusion keep the disscussion going we might come u up with more ideas. Honoured to get a reply from u all.

Share this post


Link to post
Share on other sites
Greetings Ken, you said: I'm assuming that by this you meant to use an XIO for the processor's first scan bit to condition this particular rung ... let's talk about that ... now you've already made the argument (above) that using the XIC for S:FS on the TOP rung was a good idea ... and I agree - no debate there ... but now that you've raised "scan time" as something of an issue, let's keep "scan-time" in mind and take another look at the second "buffer" rung ... here we can shave a few "milli-micro" seconds off of each scan sequence by making (or keeping) this particular MOV rung UNCONDITIONAL ... look at it this way ... if we use the XIO, then the ONE-AND-ONLY time that the second "buffer" rung will ever be "false" will be on the processor's very first scan ... in that situation (and in that situation alone) we WILL actually save a tiny amount of scan time by NOT doing the MOV command ... but ... on each and every subsequent scan, the processor will be forced to re-evaluate the XIO instruction ... and on each and every one of those subsequent scans, he'll ALWAYS find the instruction to be "true" ... and so ... here we could actually save some scan time by simply leaving the XIO out of the picture completely ... basic idea: why make the processor check it repeatedly when we already KNOW what the outcome will ALWAYS be? ... quick answer: let's don't check it ... let's just do the MOV on each scan ... going further ... some of the official Allen-Bradley books do give "timing requirements" for various instructions ... and in some cases, they even point out recommended ways of arranging the order of "usually true" and "usually false" instructions on the rungs and branches for optimum results ... but just between you and me, I've never been able to really nail down those concepts with clear-cut experiments that would either prove or disprove that those recommended methods amount to a hill of beans ... now I'm NOT saying that I doubt the book ... I'm just saying that I can't PROVE that it's either right or that it's wrong ... and personally, I'm always very skeptical of anything that I can't prove for myself ... anyway ... thank you for bringing up these additional concepts for discussion ... and as always, thank you for the kind compliments ...

Share this post


Link to post
Share on other sites
Being that I am no longer a true OEM, I only build control panels in house now, I am curious. How many of you supply power from a UPS to you PLCs. Currently I do not use them and not equipment we have purchased has had them.

Share this post


Link to post
Share on other sites
Greetings TWControls, earlier you asked: thank you for the kind compliment ... but there's little chance that my ego will get too far out of hand ... what most people don't realize is just how difficult most of this PLC stuff is to me ... the honest story: in just about every case, the stuff that I post (or teach) is material that I've literally slaved over in order to understand it ... I actually have to work my way through these problems step-by-step before they ever start making sense to me ... I am (without a doubt) the dumbest, most frustrating student that I have ever tried to teach ...

Share this post


Link to post
Share on other sites
Our buildings have a huge UPS system. We actually have UPS drops from the ceiling to several hundred PLC's and com's boxes (PC's). Though the logic survives fine in power outages, especially a brown out will take out the rs232 modules programs and HMI's often. We bought a competing company and they had a UPS on each machine. I have a UPS at my desk as well.

Share this post


Link to post
Share on other sites
Now that is a great saying

Share this post


Link to post
Share on other sites
Ron, Have you played with the User defined JSR's yet. Fun and frustrating...

Share this post


Link to post
Share on other sites
What version and where? I haven't seen them yet

Share this post


Link to post
Share on other sites
I am using rev. 13.01 Once you have created one then you can plug in tags for the app. you are on. here is an barcode reader example. There is rung logic to correspond. Edited by Smoke

Share this post


Link to post
Share on other sites
Good job Ron, I never considered that time savings before, but I agree with your logic. I'll try and remember that in my next application. Thanks, Ken

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0