How to use an OSF in a SLC 5/03
First: What do we REALLY mean when we say "start up'? And what do we REALLY mean when we say "power up"? If you'll pay careful attention to this rather lengthy post, I think you'll find that these two terms (and others like them) can generate quite a bit of confusion, particularly where things such as the OSR instructions are involved.
Second: Also covered below is an issue which revolves around the differences between AC inputs and DC inputs during "power down" or "power failure" conditions. I don't' think I've ever seen these particular issues discussed on any of the forums I visit, so I'm going to try to tackle them here. Many programmers are unaware that these issues even exist. The problems they present are rarely encountered, but knowing this material may come in handy someday. Legends are made of this type of stuff. And yes - I learned these lessons the hard way.
IMPORTANT DISCLAIMER: The material which follows is specific to the Allen-Bradley SLC-5/03 processor. Other Allen-Bradley processors (particularly the PLC-5 family) will give different results when programmed in similar manners, especially at processor startup.
I have on my desk an SLC-5/03 system to experiment with. In slot number 1 is a DC input module. I have hardwired input I:1/1 directly to the 24VDC output of the SLC's power supply. In slot number 2 is an AC input module. I have hardwired input I:2/1 directly to the 120VAC line terminals on the SLC's power supply. In other words, both I:1/1 and I:2/1 are ON right now, their LED's are lighted. All other inputs are unconnected and so they are all OFF right now. I will NOT alter the wiring of any of the inputs during the experiments which follow. This will allow us to concentrate solely on the way the OSR instructions operate whenever the processor "starts up", we pretty much already understand the way they operate once the processor is actually running. But let's run through it anyway just for kicks.
First, suppose that our processor is scanning - and it comes to an OSR, and suppose that the rung logic leading up to the OSR happens to be FALSE. In this case, the processor will simply write a 0 (zero) into the OSR's addressed bit, and then evaluate the OSR's logic as FALSE. In this situation we will NOT get a one-shot pulse.
(And just in case you're not sure what I mean by the OSR's "addressed bit" take a quick look at rung 0 in the ladder listing below. The OSR's "addressed bit" in that particular rung is B3/32).
Continuing on - next, suppose that our processor is scanning - and it comes to an OSR, and suppose that the rung logic leading up to the OSR happens to be TRUE. In this case, the processor will check the status of the OSR's addressed bit. If the bit contains a 0 (zero), then the processor knows that the OSR has NOT already been fired. So the processor will write a 1 (one) into the OSR's addressed bit, and then evaluate the OSR's logic as TRUE. In this case we WILL get a one-shot pulse.
Finally, suppose that our processor is scanning - and it comes to an OSR, and suppose (once again) that the rung logic leading up to the OSR happens to be TRUE. In this case, the processor will (as before) check the status of the OSR's addressed bit. If the bit contains a 1 (one), then the processor knows that the OSR has ALREADY been fired. So the processor will keep the 1 (one) in the OSR's addressed bit, and then evaluate the OSR's logic as FALSE. In this case we WON'T get a one-shot pulse.
From this you should see that the one or zero status of the OSR's "addressed bit" is used as a "marker" or "scratch pad" to remind the processor that the OSR has already been "fired", or that it is currently "loaded" and ready to "fire" again. If you'll keep these concepts firmly in mind, then the rest of this post should make perfect sense. Without this understanding of the OSR's operation, some of what follows might seem like utter madness.
After wiring my SLC-5/03 system as described above, I have downloaded the following program into the processor.
I:1/0 B3/32 B3/0 I:1/0 is a DC input
Rung 0 ----] [----[OSR]---------------(L)-- field-wired OFF
I:2/0 B3/33 B3/1 I:2/0 is an AC input
Rung 1 ----] [----[OSR]---------------(L)-- field-wired OFF
I:1/1 B3/34 B3/2 I:1/1 is a DC input
Rung 2 ----] [----[OSR]---------------(L)-- field-wired ON
I:2/1 B3/35 B3/3 I:2/1 is an AC input
Rung 3 ----] [----[OSR]---------------(L)-- field-wired ON
I:1/0 B3/36 B3/4 I:1/0 is a DC input
Rung 4 ----]/[----[OSR]---------------(L)-- field-wired OFF
I:2/0 B3/37 B3/5 I:2/0 is an AC input
Rung 5 ----]/[----[OSR]---------------(L)-- field-wired OFF
I:1/1 B3/38 B3/6 I:1/1 is a DC input
Rung 6 ----]/[----[OSR]---------------(L)-- field-wired ON
I:2/1 B3/39 B3/7 I:2/1 is an AC input
Rung 7 ----]/[----[OSR]---------------(L)-- field-wired ON
I:1/0 B3/40 S:1/15 B3/8 I:1/0 is a DC input
Rung 8 ----] [----[OSR]----]/[--------(L)-- field-wired OFF
I:2/0 B3/41 S:1/15 B3/9 I:2/0 is an AC input
Rung 9 ----] [----[OSR]----]/[--------(L)-- field-wired OFF
I:1/1 B3/42 S:1/15 B3/10 I:1/1 is a DC input
Rung 10 ----] [----[OSR]----]/[--------(L)-- field-wired ON
I:2/1 B3/43 S:1/15 B3/11 I:2/1 is an AC input
Rung 11 ----] [----[OSR]----]/[--------(L)-- field-wired ON
I:1/0 B3/44 S:1/15 B3/12 I:1/0 is a DC input
Rung 12 ----]/[----[OSR]----]/[--------(L)-- field-wired OFF
I:2/0 B3/45 S:1/15 B3/13 I:2/0 is an AC input
Rung 13 ----]/[----[OSR]----]/[--------(L)-- field-wired OFF
I:1/1 B3/46 S:1/15 B3/14 I:1/1 is a DC input
Rung 14 ----]/[----[OSR]----]/[--------(L)-- field-wired ON
I:2/1 B3/47 S:1/15 B3/15 I:2/1 is an AC input
Rung 15 ----]/[----[OSR]----]/[--------(L)-- field-wired ON
B4/48 B3/16 sample rung - not
Rung 16 -----------[OSR]---------------(L)-- recommended practice
Notice that the output of each rung will latch a "flag" bit if the processor ever executes the rung as true. This will allow us to see the results of any one-shot pulses even though the pulse itself lasts only for one scan. Yes, there is quite a bit of redundancy (if not to say overkill) in this program but I wanted to lay everything out so that we can compare "apples to apples" as the saying goes. Notice that I've placed rungs with AC inputs next to rungs with DC inputs to allow for easy comparison. Also notice that I've included samples of inputs which are field-wired OFF and also inputs which are field-wired ON. Then I've duplicated of all of these "straight-forward" rungs, and modified the copies by adding the XIO for the "First Pass" bit (S:1/15) which Keith suggested in his post.
Finally, I've included a very simple Rung 16 just for kicks.
Since I've just written the program and downloaded it to the processor, then ALL of the bits I've used are currently in an OFF (zero) state. Specifically, if we were to examine the data tables for these bits, we would find that ALL of them are OFF (zero). Specifically, so far I haven't put the processor in the run mode. Remember that the SLC-5/03 processor doesn't monitor the status of the input modules unless it is in the RUN mode. Specifically, all of the inputs (even those which are hardwired ON) are currently in an OFF (zero) state on the data tables. And so are all of the OSR status bits (B3/32 through B3/48). And finally, all of our flag bits (B3/0 through B3/16) are also in an OFF (zero) state. This is what I would personally describe as a "fresh-out-of-the-box" condition. (Sorry for beating this idea to death, but understanding this OFF (zero) status of the bits is critical for what comes next.)
Sneak preview: One of the main reasons I am writing all of this is to differentiate between the various conditions which many people lump together under the ambiguous headings of "start up" or "power up" or "power cycle" conditions. Here are five of those types of conditions which I intend to cover as we continue:
1. "Fresh-out-of-the-box" startup condition
2. "RUN-PROGRAM-RUN" startup condition
3. "RUN-power failure" shutdown condition
4. "RUN-power failure-RUN" startup condition
5. "RUN-power flicker-RUN" condition
As you're about to see, each of these conditions will give us slightly different results in the operation of the OSR instructions. Now for our first test.
1. "Fresh-out-of-the-box" startup condition
Since I've just downloaded the program to the processor, then we're "fresh-out-of-the-box", and ALL of our bits are currently OFF (zeros). The processor's key is in the PROGRAM position. Power is applied to the processor and also to the I/O system. Now we finally place the processor in the RUN mode. Question: How will the OSR instructions react?
Here's what we get: The following flag bits are ON (ones): B3/2; B3/3; B3/4; B3/5; and B3/16. All of the rest of the flag bits are still OFF (zeros).
The first point that I want to make is that in this test there is no difference between the operation of the DC inputs when compared to the operation of the AC inputs. (But stay tuned, that will come up later). Next, (and more importantly) the fact that bits B3/2; B3/3; B3/4; and B3/5 came ON illustrates the "false one-shot" operation which Keith brought up in his post. Specifically, in this "fresh-out-of-the-box" situation - David CAN get some one-shot pulses "when the processor starts". The specific situation that Keith was concerned about is illustrated by rungs 4 and 5. Notice that each of these rungs uses an XIO instruction (the construction which I had suggested earlier), and notice that the inputs involved are known to be OFF in the field. Further, notice that the "fresh-out-of-the-box" test can result in a "false one-shot" operation whether we're using an XIC or an XIO. This is illustrated by rungs 2 and 3.
Going a little further, Keith called this a effect a "false one-shot" and quite probably it is. But then, on the other hand, it's also remotely possible that David really WANTS this initial pulse when he first starts up his machine. Who can say for sure? Only David - since he's the only one who knows how his machine must respond when he starts it up "fresh-out-of-the-box". As Keith correctly pointed out, if David's system can't handle this initial pulse, then the XIO for S:1/15 will fix the problem. This is illustrated by the fact that bits B3/12 and B3/13 stayed OFF their rungs incorporate Keith's suggestion.
I'm just going to mention bit B3/16 in passing. This bit came on because the OSR bit (B3/48) contained a 0 (zero) when we first put the processor into the RUN mode. As soon as the processor executed this rung, TRUE logic hit the OSR (which had NOT already been "fired" - as denoted by the 0 (zero) status of the bit) and so the processor "fired" the OSR and marked the "fired" status by placing a 1 (one) into the OSR's bit. The flag bit B3/16 was latched ON as a result of "firing" the OSR. Keeping this sequence in mind should help you figure out just what made bits B3/2; B3/3; B3/4; and B3/5 come ON also. Now let's move on to our next test.
2. "RUN-PROGRAM-RUN" startup condition
Let's say that the processor has been running for some time in the RUN mode. The hardwired input bits are ON (ones). We've toggled all of the flag bits OFF (zeros) to get ready for our test. Then we place the processor in the PROGRAM mode for awhile. Finally, we place the processor back in the RUN mode. Question: How will the OSR instructions react?
Here's what we get: NONE of the flag bits are ON (ones). That's right, they ALL are still OFF (zeros). Notice the big difference between this test and the previous test specifically, in this test some of the OSR bits already contained 1's (ones). So when we went back into the RUN mode, the processor knew that these particular OSR's had already been "fired" and so there was no reason to "fire" them again. Remember that in our previous "fresh-out-of-the-box" test ALL of the OSR's contained 0's (zeros) so the processor considered each of them to be "loaded" and ready to "fire" when (and if) TRUE logic reached them.
The reason I specifically wanted to cover this situation is that many (if not most) programmers think of this "going to run mode" operation as a "start up" condition. Well, maybe it is and maybe it ain't. It all depends on your definition. The point remains: This is one of the conditions that all programmers (including David) need to consider when debugging and commissioning a new program. Case in point: Consider bit B3/16. In our previous "fresh-out-of-the-box" test, this bit came ON. Now we're testing for a "RUN-PROGRAM-RUN"situation and B3/16 does NOT come ON. If a programmer actually DOES need something to happen whenever the processor goes through a "RUN-PROGRAM-RUN" cycle, then the construction of rung 16 is not the answer. The most commonly used solution would be to use an XIC for S:1/15 to trigger the desired operation and leave the OSR completely out of the picture. Now for our next test.
3. "RUN-power failure" shutdown condition
Let's say that the processor has been running for some time in the RUN mode. The hardwired input bits are ON (ones). We've toggled all of the flag bits OFF (zeros) to get ready for our test. Next we turn off ALL power to the system by simply pulling the power plug out of the wall receptacle. This should duplicate what would happen if the plant had a full-scale power failure. Question: How will the OSR instructions react?
Now since we've removed the power from the entire system, we'll definitely lose communication with our processor but we can still examine the status of the processor's internal bits their OFF/ON status at the instant the processor lost power is still recorded in the data tables of our OFFLINE file.
Let's take a look and here's what we see: The following flag bits are ON (ones): B3/7 and B3/15. All of the rest of the flag bits are still OFF (zeros). Now take a good look at the difference between the DC inputs and the AC inputs. Most people think that an input - is an input is an input. This test illustrates that there ARE some differences particularly when it comes to "power shutdown" situations. In case you're missing it: Take a good look at rungs 6 and 7. These two rungs are constructed EXACTLY the same - and further, each of them has an input which (for our test system) is hardwired ON in the field and so both of these inputs are "guaranteed" to be ON. Yet rung 6 did NOT pulse its output while rung 7 DID.
Why? The trick is that the DC power "holds up" for a few seconds after the power plug is pulled but the AC power dies instantly. I can easily see this effect on my bench system if I watch the LED's on the two input modules while I pull the plug. As soon as the plug comes out, the AC input (I:2/1) drops off instantly but the DC input (I:1/1) stays lit for about one full second. The reason? As most technicians know, one critical component of a DC power supply is a large capacitor which is used to "filter" out the ripple which results from rectifying the AC input power. As soon as the AC line power is removed, this capacitor starts to discharge - and this discharge effect "holds up" the DC output for a little while (usually a full second or two). In the case of our SLC-5/03 system, the DC power supply is not only providing power to our DC input I:1/1 it's also providing power to our SLC processor. Again, if I watch the LED's on my test system and this time I pay careful attention to the LED's on the processor while I pull the plug these LED's will also stay lit for about one full second. Keeping this DC power supply "hold up" effect in mind, let's go through the "RUN-power failure" test again this time in slow motion.
Again - let's say that the processor has been running for some time in the RUN mode. The hardwired input bits are ON (ones). We've toggled all of the flag bits OFF (zeros) to get ready for our test. Next we turn off ALL power to the system by simply pulling the power plug out of the wall receptacle. Here's the trick: At the instant we pull the plug, the AC input at I:2/1 immediately goes OFF simply because there is no longer any AC power to keep it ON. BUT! since the processor gets its power from the DC power supply, it (the processor) stays powered up for an extra second or so. And that's plenty long enough for the processor to see the AC input make a transition from ON to OFF and the TRUE logic which results at the XIO is what actually triggers the OSR in rung 7 to "fire" - and that "firing" gives us a pulse which latches bit B3/7 ON.
But how about rung 6 why didn't it give us a one-shot pulse too? After all, it has EXACTLY the same construction as rung 7. Well, the construction is the same - but rung 6 uses a DC input rung 7 uses an AC input. This can get tricky. At the instant we pulled the plug, the DC input at I:1/1 did NOT go OFF that's because this input gets its power from the DC power supply - so it (the input) stays powered up for an extra second or so. That means that the processor did NOT see input I:1/1 make a transition from ON (one) to OFF (zero) and so there was no true logic to trigger the OSR in rung 6 to "fire" - and so there was no pulse to latch on bit B3/6.
Now I don't know about you, but I find this difference between AC and DC inputs to be VERY interesting. Personally, I don't drink but if I did, I'll guarantee you that I could win some serious beer money by betting on this one. And by the way notice that the XIO for S:1/15 in rung 15 did not prevent a pulse at B3/15 this time. The reason is that since this particular test did not involve a "First Pass" condition, the XIO was TRUE and allowed us to latch B3/15 ON. OK now for our next test.
4. "RUN-power failure-RUN" startup condition
Let's say that the processor has been running for some time in the RUN mode. The hardwired input bits are ON (ones). We've toggled all of the flag bits OFF (zeros) to get ready for our test. Then we turn off ALL power to the system by simply pulling the power plug out of the wall receptacle. A little while later we plug the power cord back in again and the processor automatically returns to the RUN mode. Question: How will the OSR instructions react?
Here's what we get: The following flag bits are ON (ones): B3/3; B3/7; and B3/15. Actually, the only bit that we really need to discuss here is B3/3. After all, test 3 (above) showed us that bits B3/7 and B3/15 had ALREADY come ON - just soon as we PULLED the power plug.
So why did bit B3/3 come on? Because when we pulled the plug and the power dropped off, the AC input I:2/1 went OFF immediately - before the processor shut down. (Remember the DC power supply "hold up" effect keeps the processor running for an extra second or two during a power failure.) When the processor saw the AC input go OFF, it scanned the OSR with FALSE logic. This caused the processor to write a 0 (zero) into the OSR's addressed bit which "reloaded" the OSR. Keep in mind that all of those steps took place while the system was LOSING power. Then later, when the power came back on again, the OSR was set up and ready to "fire" which it did just as soon as the processor executed rung 3 with I:2/1 in an ON condition. Now on to our last test.
5. "RUN-power flickers-RUN" condition
Let's say that the processor has been running for some time in the RUN mode. The hardwired input bits are ON (ones). We've toggled all of the flag bits OFF (zeros) to get ready for our test. Then we turn off ALL power to the system by simply pulling the power plug out of the wall receptacle. So far, this is just like our previous "RUN-power failure-RUN" test. But this time we'll do something just a little bit different. Let's plug the power cord RIGHT BACK IN AGAIN. Specifically, we plug the power cord back in BEFORE the processor has time to drop out of the RUN mode. Remember that the DC power supply "holds up" for about one full second so suppose we only pull the plug out for one-half second or so. This will simulate a situation where we have a very brief "flicker" in our plant's power system. Question: How will the OSR instructions react?
Here's what we get: The following flag bits are ON (ones): B3/3; B3/7; and B3/15 and also bit B3/11. Now the first three bits should be no surprise we covered them in our previous test. But B3/11 is very interesting - because it did NOT get a one-shot pulse in our previous "RUN-power failure-RUN" test but now when we only "flicker" the power while in the RUN mode - B3/11 DOES get a pulse. What's going on here?
The trick revolves around the XIO for S:1/15 in the rung for B3/11. This XIO condition will evaluate as FALSE IF the processor is going through its "First Pass" through the ladder. Normally this occurs every time the processor is just going into the RUN mode. BUT! since we only "flickered" the power supply, the processor is NOT just entering a RUN mode condition. Instead, as far as the processor is concerned, it's just happily chugging along (with NO change of mode) due to the power supply's "hold up" effect. So the XIO for S:1/15 is constantly being evaluated as TRUE. And look at what happens to input I:2/1 when the AC power gets "flickered" OFF and then right back ON again. The AC input I:2/1 - which is normally ON (one) - goes OFF (zero) just for half a second or so but that's plenty of time for the processor to see the input make a transition from ON - to OFF - and then back to ON again. This sequence of transitions first "reloads" the rung's OSR and then "fires" it - just as soon as the AC power comes back ON again. And notice that this is quite different from the operation of our previous "RUN-power failure-RUN" test. Specifically, when the power actually FAILED long enough to cause the processor to shut down, we did NOT get a pulse at B3/11 (the XIO for S:1/15 saved our necks there). But on the other hand, when the power only FLICKERED (but did NOT stay off long enough to cause the processor to shut down) we DID get a pulse at B3/11 (because the XIO for S:1/15 didn't come into play in the brief "flicker" situation).
So - are you starting to get the picture that these types of issues can cause all sorts of intermittent problems when interruptions to the plant power system are involved? Notice that we've just run five separate "start up" or "shut down" types of tests and each test has given us a significantly different pattern of pulses from our OSR instructions.
Now I'm sure that quite a few readers are thinking: This is a lot more information than I really wanted to know. But maybe a few others are thinking to themselves: I just hope I can remember this stuff, because SOMEDAY I'm bound to need it. Personally, I ran head-on into this "AC-input-versus-DC-input" phenomenon while helping to debug a system which only "went crazy" after power-down situations and even then it was only during certain random power-downs. The "craziness" depended on exactly which inputs were ON which were OFF and which inputs were wired to DC and which inputs were wired to AC. Plenty of room for confusion but guru legends are made from opportunities like this.
Here's a quick review of the tests we made - and the flag bits which were latched ON as a result:
1. "Fresh-out-of-the-box" startup condition = B3/2; B3/3; B3/4; B3/5; and B3/16
2. RUN-PROGRAM-RUN startup condition = No bits
3. RUN-power failure shutdown condition = B3/7; and B3/15
4. RUN-power failure-RUN startup condition = B3/3; B3/7; and B3/15
5. RUN-power flicker-RUN condition = B3/3; B3/7; B3/11; and B3/15
1. AC inputs can operate differently from DC inputs particularly in power-down situations. This can get extremely complicated (far beyond our simple examples above) whenever the processor gets its power from a source which is independent from that of the I/O modules. This situation occurs most often when a UPS (un-interruptible power supply) is provided for the SLC processor but not for the I/O system. Is that good or is it bad That's not for me to say here it depends on the system you're trying to control but I can guarantee you one thing - it CAN get tricky when the system goes through a power up or power down or power flicker situation.
2. The OSR instructions can be tricky to implement especially in situations where a field device is wired to be normally ON and is powered by an AC source.
3. Testing and commissioning a system should include what-if scenarios which incorporate (at a minimum) realistic power failure and power up and power flicker situations. I'd recommend that you make a checklist of procedures to run through and systematically test them all - before you finally sign off on your programming handiwork.
4. Simply placing an XIO for S:1/15 after an OSR will not guarantee that you won't get a false one-shot pulse at least not in certain start up or power up situations. Take another good look at the status of B3/15 after test 4. And the status of B3/11 after test 5. Notice that these bits DID get pulses - in spite of the extra First Pass condition. This is definitely something that David will want to keep an eye on as he continues with his project.
Well, that's what I wanted to cover about the OSR instruction for the SLC-5/03 system. Since I've still got a little more time, I think I'll bring up one more example of how the difference between AC inputs and DC inputs can cause issues when we have power problems even when we're not using OSR instructions. Consider the following rungs:
start Pump D Pump D I:1/0 is a momentary
I:1/0 O:3/1 pushbutton field-wired
Rung 17 ----] [------------------------(L)-- normally open with a
DC power supply
stop Pump D Pump D I:1/1 is a momentary
I:1/1 O:3/1 pushbutton field-wired
Rung 18 ----]/[------------------------(U)-- normally closed with a
DC power supply
start Pump A Pump A I:2/0 is a momentary
I:2/0 O:3/0 pushbutton field-wired
Rung 19 ----] [------------------------(L)-- normally open with an
AC power supply
stop Pump A Pump A I:2/1 is a momentary
I:2/1 O:3/0 pushbutton field-wired
Rung 20 ----]/[------------------------(U)-- normally closed with an
AC power supply
Here we have a very common method of starting and stopping two separate pieces of machinery by using momentary pushbuttons to either latch the outputs ON - or to unlatch the outputs OFF. The programmer intended to have both of the outputs RETAIN their ON status even after a power failure something that a common seal-in branch type construction can't do. So he used the LATCH/UNLATCH arrangement instead. This is a very common practice. And notice that he's used stop buttons which are field-wired normally closed to provide an extra measure of failsafe operation. The main idea is that if a wire ever breaks in either of the stop circuits, then the OFF (zero) status of the input bit will cause the processor to evaluate the XIO instruction as TRUE which will unlatch the appropriate output and thus turn it OFF. Again - this is done in order to gain an extra measure of fail-safe operation. This is also a very common practice. So what's the problem here
The problem is that the programmer (or possibly the electrician who wired up the I/O system) just happened to use the SLC's DC power supply for the buttons on the Pump D system but he used an AC power supply for the buttons on the Pump A system. Even so, both systems could work perfectly for years with no problems whatsoever. But! suppose that one day the plant is in full operation with both Pump D and Pump A running happily along.
Question: What's going to happen when the plant's power flickers OFF for half a second or so - and then comes right back ON again Answer: Pump D will keep running (as intended) but (oops!) Pump A will NOT keep running. It will shut down - and someone will have to go over and manually press its start button to get it going again.
This could be VERY bad. Remember, the whole reason for using the LATCH/UNLATCH construction in the first place was to bring both pumps back up in the run condition after a power failure. But it won't work for the system using AC inputs because as soon as the plant's power fails, the AC powered circuit from Pump A's normally-closed stop button is going to INSTANTLY go OFF (zero) and the processor (which stays powered up for an extra second or two because of its DC power supply) will evaluate the XIO for input I:2/1 as TRUE and the resultant true logic will unlatch Pump A's output O:3/0. So Pump A goes OFF and it will stay OFF after the plant's power comes back on.
On the other hand, when the power flickers (or even if it fails and stays OFF for awhile) the DC powered circuit from Pump D's normally-closed stop button will remain powered up just as long as the processor does. So the processor continues to evaluate the XIO for input I:1/1 as FALSE and the resultant false logic will NOT unlatch Pump D's output O:3/1. So Pump D will recover from a power flicker and it also will come back up in a run condition when the plant's power is eventually restored after a power failure just as the programmer intended.
Possibly the worst-case scenario is that the programmer might easily miss the fact that Pump A is NOT going to perform as intended after a power problem and if this is a critical piece of machinery well, we might not know just how ugly this situation is going to turn out until after the lawyers finally get through with it.
And so even though the rungs for Pump D and the rungs for Pump A are constructed EXACTLY the same the two pieces of machinery can respond in completely different ways after a power interruption just because of the little-known differences between AC inputs and DC inputs.
As I said earlier, I don't remember seeing this particular issue covered on any of the forums which I visit and it's certainly not covered in most beginner-level programming classes. Personally, I think it's quite interesting and maybe some of you will find it helpful someday in the future. If so, then I will consider my work here to have been worthwhile.
Continuing on so now that we have some idea of how tricky these power up and start up issues can be, the question remains: What can we do to handle all of these problems You could start by taking a look at the official explanation of these issues in the SLC-500 Modular Hardware Style User Manual - Allen-Bradley publication 1747-UM011C-EN-P dated Dec-01 - which is available at www.ab.com in the Publications Library; Manuals Online section.
Start reading at the heading for Master Control Relay which begins on page 3-8 (or Adobe Reader page 66 of 276). Keep in mind that if you follow the wiring diagram in this book (shown on page 3-10 or Adobe page 68), any power failure - or even a power flicker - will require that someone manually press the start button to energize MCR (the master control relay) to put the system back in operation. Clearly this is NOT the answer for a system that is required to resume full operation after any type of power problem. Also notice that there are three sets of contacts from the MCR relay one set to handle the relay's own seal-in circuit - another set to control the power for the AC I/O circuits and a third set (incorrectly labeled CRM) to control the power for the DC I/O circuits. Keep in mind that controlling the DC I/O power in this manner will remove the hold up effect for the DC inputs. In other words, using this wiring method, we would expect the DC inputs to operate in exactly the same manner as the quick acting AC inputs when the system goes through a power down situation.
As the manual continues, there's a suggestion under the paragraph titled Input States on Power Down.
The power supply hold-up time as described above is generally
longer than the turn-on and turn-off times of the input modules.
Because of this, the input state change from On to Off that occurs
when power is removed may be recorded by the processor before the
power supply shuts down the system. Understanding this concept is
important. Write the user program to take this effect into account. For
example, hard-wire power to one spare input. In the user program,
check to be sure that one input is on; otherwise, jump to the end of
the program and avoid scanning the logic. Use of a common power
source as recommended in the previous section is assumed.
One way to implement this last suggestion would be to program the following rung as the very first rung at the top of the program:
power monitor I:2/15 is a spare
I:2/15 input field-wired
Rung 0 --- *]/[*----------------------(TND)-- to be always ON
Personally, I'm convinced that we could still have some issues even after implementing this solution. If anyone is interested enough to ask, I'll try to cover those issues in a future post.
Beyond these official suggestions, I'd like to be able to offer a simple one-size-fits-all solution to all of the issues I've raised but unfortunately that's just not possible. There's no feasible way to write a good program without being intimately familiar with the operation of the machine and also with its wiring. Hopefully this post has pointed out some of the issues that we all need to keep in mind as we try to understand the machines we're programming.