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

As far as I know, all bits will retain their last state during a power cycle

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.

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.....

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.

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.

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:

QUOTE

... like just clicking the check box to retain all the required bits.

now I'm reading between the lines here, so don't get offended if I've misunderstood your meaning ... but your statement seems to indicate that you're a little confused by one of the ControlLogix platform's features ... let's talk about this for a few seconds ...



suppose that I have a 1756-OA16 (16-bit AC Output) module located in my ControlLogix chassis ... suppose that I open that module's "Properties" and go to the "Configuration" tab ... I'd see something like this ...



[attachmentid=2149]



now I might be tempted to click on the little pull-down arrows on this screen and make some changes ... suppose that I try adjusting the "Program Mode" and the "Fault Mode" settings for various bits ... maybe I'm hoping that entering these particular settings as "On" or as "Hold" will help me "retain" the On/Off status of those particular bits whenever I cycle the power to my system ... sorry ... that won't work ... the settings on this screen ONLY affect the system while it is in the "Program Mode" or when the system is "Fault Mode" ... specifically, these settings won't help you "retain" the On/Off status of a bit when the system is power cycled ...


note: if you were talking about some other "check boxes" please post again and let me know ... I've probably just misunderstood exactly what you were talking about ...


now let's move on to what we mean by "retain" ... suppose that I have the following simple program ... (note: on this excellent forum, you can click on the pictures to enlarge them) ...



[attachmentid=2150]



the rung comments should nail everything down ... but just to make sure that we're all on the same page, let's say that in Allen-Bradley systems, the following "normal situation" rules apply ...



(1) any and all bits which are controlled by an OTE (Output Energize) instruction, will NOT retain their "On" status whenever the processor is either power cycled – or if the processor is switched from the "Program Mode" to the "Run Mode" ... specifically, if a bit which is controlled by an OTE happens to be On when the processor shuts down, then that bit is going to be turned Off when the processor restarts ...



(2) any bits which are controlled by an OTL (Output Latch) instruction, WILL retain their "On" status whenever the processor is either power cycled – or if the processor is switched from the "Program Mode" to the "Run Mode" ... specifically, if a bit which is controlled by an OTL happens to be On when the processor shuts down, then that bit is going to remain turned On when the processor eventually restarts ...



now those are the basic "normal operation" rules ... and like most (all?) rules, there are some exceptions ... but we've got to start somewhere - and this is where we start ...



{A} now let's consider that sample program ... suppose that we're in the "Run mode" ... suppose that both "Pump A" and "Pump B" are currently turned Off ... so neither one is running ... suppose that we put the processor in the "Program Mode" ... think about those "Program Mode" settings that we made in the first figure ... now "Pump A" (which was set for "On") actually defies the ladder logic and suddenly turns "On" while the processor is in the "Program Mode" ... but "Pump B" (which was set for "Hold") will remain "Off" while the processor is in the "Program Mode" ... that's because we're "holding" the previous "Off" state for this particular device ...

QUOTE

side trip: this is one of the truly "weird things" that I really have to stress to the technicians in my ControlLogix classes ... many of these guys have had considerable previous experience with Allen-Bradley PLC-5 and SLC/MicroLogix systems ... and in those systems, whenever the processor is placed in the "Program Mode", the output devices in the field are ALWAYS turned OFF ... now look what we're running into with the new ControlLogix platform ... here's an output that was OFF while we were in the "Run Mode" ... but ... now it suddenly comes ON when the processor is turned to the "Program Mode" ... now you've gotta admit, that's pretty weird - at least until you understand what's happening - and know where to go look for the source of the confusion ...

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 ...



[attachmentid=2151]



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 ...

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

QUOTE

Can a timer keep timing during a power outage??

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 ...

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

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.

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?

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 ...







a lot depends on what you mean by "output" ...



(1) do you mean the OTE instruction on the rung? ... or ...

(2) the bit/box in the processor's memory? ... or ...

(3) the actual device (example: a pump) in the field? ...



personally, I only use the word "output" to refer to the field device ... but a LOT of people (most?) use it interchangeably to mean any one of the other items listed above ... let's try to nail some of this down ...



suppose that we're dealing with a ControlLogix platform ... suppose that we have only one simple unconditional rung located in the MainRoutine ladder file ... the rung contains ONLY one OTE instruction with the address Local:2:O.Data.0 ... suppose that this address is assigned to a pump in the field ... the output module has been left in its default "Configuration" ... specifically, all outputs on this module will be turned Off when the processor is in the "Program Mode" ... and also, all outputs on this module will be turned Off when the processor is in the "Fault Mode" ... the processor is in the "Run Mode" ... our rung in the MainRoutine of the program is being scanned ... the OTE is highlighted in green on our ladder display screen ... the bit/box addressed as Local:2:O.Data.0 contains a 1 ... the "0" LED on the front of the output module is lit ... the pump in the field is running ...



the sun is shining ... the birds are singing ... life is lovely ...



now the 120VAC service to the power supply for the ControlLogix chassis is turned off ... while the power remains off, here are our conditions ...



(1) the screen display has gone offline ... we can't communicate with the processor since it has no power ... but the OTE on the screen is still highlighted in green ... the software displays the OTE this way because, in the offline file, the bit/box Local:2:O.Data.0 still contains a 1 ... actually this is pretty well meaningless at this point, but since some people are confused by the green indication, I thought I'd add the detail ...



(2) inside the processor, the rung is no longer being scanned ... no power - no scanning ...



(3) inside the processor, bit/box Local:2:O.Data.0 still contains a 1 ... that was the "last state" when the processor shut down ... so far there has been nothing available to change that state ... the 1 is maintained by the processor's battery power ...



(4) the 0 LED on the front of the output module has gone off ... no power - no LED ...



(5) the pump in the field has gone off ... with no backplane power, the output module cannot drive the output on ...



now let's turn the 120VAC service to the power supply for the ControlLogix chassis back on and see what happens ... the processor takes a few seconds to "warm up" and get started ... since it was in the "Run Mode" when it powered down, it comes back to the "Run Mode" when it powers back up ... and then ...



(1) the processor does a "prescan" routine ... one of the features of the "prescan" is that our rung will be executed (just once) with "false" logic ... think about that ... we have an UNCONDITIONAL (guaranteed-to-be-true) rung here ... but the processor (at least on the "prescan") still executes the rung as "false" ... quick question: what does an OTE do when it is executed with "false" logic? ... answer: it instructs the processor to go write a 0 into the bit/box that has the same address ... at this point the status of the bit/box Local:2:O.Data.0 becomes a 0 ...



note that the "prescan" is NOT the same thing as the "first scan" ... specifically, any conditional references to S:FS will be ignored during the "prescan" sequence ...



(2) the processor has now "warmed up" in the "Run Mode" and also finished its "prescan" routine ... now the processor begins its normal scan of the ladder program ... our rung is now being scanned again ... since the rung is unconditional, the OTE is now executed with "true" logic ... quick question: what does an OTE do when it is executed with "true" logic? ... answer: it instructs the processor to go write a 1 into the bit/box that has the same address ... at this point the status of the bit/box Local:2:O.Data.0 becomes a 1 again ...



(oops! Wanda Faye just called and I've got to head home for dinner VERY soon) ...



but what about the pump in the field?



while the service to the power supply was turned off, the pump was also off in the field ... as the processor was coming back up again, the "prescan" took place and wrote a 0 into the pump's bit/box ... but that was just for one quick scan ... the pump in the field stayed off during this period ... then the processor scanned the OTE with "true" logic and wrote a 1 into the pump's bit/box ... then the output module received the "on" signal over the backplane and turned the field output (the pump) back on again ...



now to someone standing in the field, all that they saw was that the pump was originally running ... then the power failed and the pump went off ... then the power came back on again and the pump turned back on ...



sorry but that's as much as I have time for right now ... did that help - or hurt? ...



final specific question/answer:







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 ...

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

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.

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.

Greetings Ken,



you said:

QUOTE

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.

for purposes of discussion, let's break that last part down into two separate statements ...

QUOTE

if first scan true, move from the N file to the bits.

you're absolutely correct ... making the top rung conditional could save a small amount of scan time ... specifically, that way we wouldn't needlessly sacrifice the scan time required to move the contents of the buffer on each and every program scan ... and yes, the CLX platform will work the same way (as the PLC-5) in this situation by using an XIC for "S:FS" (Status: First Scan) on the top "buffer move" rung ... and in fact, that's exactly the way I had my top rung programmed when I first plugged this program in ... then just before I did the screen dump, I decided to make the rung unconditional in order to keep the "how-does-it-work?" description as simple as possible ...



and now for the second part of your statement ...

QUOTE

if not first scan, move bits to an N file

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 ...

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.

Greetings TWControls,



earlier you asked:

QUOTE

... if you don't mind me asking what exactly does your job involve?

no, I certainly don't mind if you ask ... and hopefully no one will mind if I answer ... but then again, this might end up sounding like advertising ... if so, the moderators are welcome to delete any (or all) of it ... I can assure you that my feelings will not be hurt ...



actually the biggest part of my job is teaching PLC classes to plant maintenance technicians ... most of those classes are weeklong affairs and I usually teach about two weeks out of a month ...



besides that, once in a while my boss farms me out to "consult" with a young/inexperienced programmer who's having some sort of "mental block" problem writing or debugging a particular program ...



and then depending on the workload around here, my boss might have two or three young programmers working on integration/programming projects ... I help them out when/if they need a hand ... basically my boss thinks of it as teaching them as we go ... sometimes it's PLC programming ... sometimes it's AutoCAD skills ... how to manage a project and things like that ... personally I think that my boss has realized that I'm 59 years old ... so maybe it's time to start thinking about a replacement for the old guy ...



and then (joy of joys) if nothing else is going on, I actually get paid to answer questions on these PLC forums ... my boss figures that this is a great way for me to stay in touch with lots of different PLC troubleshooting and/or programming problems ... quite a lot of what I read (and write) here actually ends up in the classes that I teach ...



and that's pretty much it ... on days when I'm not actually teaching, I seldom (if ever) set my alarm clock ... on the other hand, I do spend quite a bit of "midnight oil" time developing new courses (mostly ControlLogix lately) ... my spare bedroom usually has a PLC-5; an SLC-5/04; a MicroLogix 1000; and a ControlLogix system ... all set up and ready to go just in case I don't feel like sleeping at night ...

QUOTE

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

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 ...

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.

Now that is a great saying

Ron,



Have you played with the User defined JSR's yet.
Fun and frustrating...

What version and where? I haven't seen them yet

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.

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

Ok. It is for SFC programming. I don't have that add on. I'm still having a hard time selling myself on programming methods other than ladder. I'll come around sometime

The Ladder is still there. When you are keeping standard code for all machines but the applications change this is a good way to go. You just plug in the Tags for the application your working on.

I'll tell you, I not sold on Tags yet.
I was easy to follow a number around but a large tag is a pain. Not to mention no Data Tables now.
Just Tag monitor

Regards UPS it depends on the situation. For example in a non critical machine No UPS.
Examples of where i have used UPS on PLC.
1. Gas plant to monitor the GAS storage tanks to alarm etc even in a power outage. Also enable the PLC to send SMS messages to alert operators of outage etc.
2. On an amusment ride where by I needed a way to lower an 11 ton hydraullically controlled platform at an Emergency Slow Speed on power outage.


As a side note when i first looked at smoke's function block i got the following mode
FUN MODE-

I thought this was cool, I think that i prefer FUN mode over Run mode because we all know thats when it begins.

Actually I love the Tags of Controllogix. The trick to them is building your structure with the user defined tags.

I have had several discussion here about the function blocks. I see some advantages of it but just haven't made the jump. I know the ladder is still there, but once I get the add on, I will be obsessed with learning it