How To Use Osf On Plc 5/03

[Guest DAVID]

I AM WRITTING THE PROGRAM ON PLC 5/03 WITH REQUIRED ME TO USE OSF FUNCTION.I KNOW IT NOT AVAILABLE IN PLC 5/03.DO WE HAVE ANY SUBTITUTE FOR OSF IN PLC 5/03. THANKS

[Guest]

Try using the OSR instruction - but reverse the logic of the input condition. For example: If you wanted to use: If the input goes OFF, the output will be ON for one scan only.   I:1/0        B3/10         B3/11 ----] [--------[OSF]--------( )---- Try this instead: If the input goes OFF, the output will be ON for one scan only.   I:1/0        B3/10         B3/11 ----]/[--------[OSR]--------( )---- Good luck, Ron

[Keith Menges 0]

Just an added comment to Ron's post. The only issue with this is you will get a oneshot from B3/11 on the first scan through the file when the processor starts. If your application can handle this false oneshot on power-up, this isn't an issue. However, if it can't you can protect against its effects. I don't remember if the 5/03 supports a firstscan bit (it is S:1/15 in a PLC5). If it does, use an XIO of firstscan AFTER the OSR in the rung shown. If it does not, add a rung below the oneshot rung with a standard OTE driven on all the time, for example a B3/12. Put a normally open contact of B3/12 AFTER the OSR in the oneshot rung. Keith

[Guest David]

Placing NC S1:1/15 after OSR instruction along with using NC contact input is the right solution.I misinterpretted AB's instruction help that we can not place any contact after OSR except output instructions.A little programming technic I learned from you.Thank you for both helps. David :-p

[Guest]

Greetings to all. First, thanks to Keith for correctly pointing out that David might have encountered some issues with the solution which I suggested in my earlier post. I guess I need to apologize here – when I told David to “try” my solution, I probably should have gone into more detail. Luckily Keith was reading over our shoulders and was good enough to point out the possible “false one-shot on power-up” issue. Apparently David has incorporated Keith’s recommendation and he’s now happy with what he’s using. Well, I certainly don’t want to say anything to discourage David – but there could STILL be some issues involved in the operation of his use of the OSR. All I’m going to suggest is that David pay particular attention to the “start up” and “power up” tests which I am going to present below. He might want to go back and double-check his application to make SURE that he has all of his bases covered. Other readers might want to keep these issues in mind whenever they check out and commission their own programming projects – or as they debug existing systems that are giving intermittent problems in random “power problem” situations. Anyway, reading Keith’s post got me thinking about some additional concepts – which I’ll try to cover below. 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 SUMMING UP: 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. http://www.ab.com/manuals/cp/1747-um011c-en-p.pdf 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”. Quoting: ================================================================ “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. Best regards, Ron PS - Recognizing that a problem exists is the first step toward finding a solution.

[Keith Menges 0]

Ron, that was SOLID. I hope everyone appreciates the time that went into doing an evaluation like that. You certainly hit some points that I should spend more time thinking about. The one that caught me by surprise was the oneshot storage bits not being reset on a processor start. I assumed (that nasty word) that they were treated like any other non-latch bit and reset on processor start. The fact that this isn't true definitely warrents consideration. Also, the different reactions of AC and DC I/O is not something I have ever really thought about. Thanks again for the evaluation. Keith

[Guest]

Yo, Keith, You’re welcome - and now you’ve brought up one more very interesting point. Something in your earlier post makes me think that you must work a lot more often with the PLC-5 family than you do with the SLC-500 family. If that’s the case, let me share an important difference between these two types of processors. The closest instruction that the PLC-5 has to the SLC-5/03’s OSR (one shot rising) is the ONS (one shot). It looks a lot like the OSR but it works differently - particularly in “start up” situations. The main thing to watch out for is that the addressed bit for the ONS will always be set (to a one) during the PLC-5 processor’s pre-scan. This doesn’t happen with the SLC-5/03’s OSR - which is not affected by the processor’s pre-scan at all. Case in point: If rung 16 in my previous post were converted to a PLC-5 format it would look something like this:                           B4/48                 B3/16   sample rung - not Rung 16 -----------[ONS]---------------(L)--   recommended practice Remember that in my earlier post, bit B3/16 was latched ON after our “fresh-out-of-the-box” test for the SLC-5/03 - but in that case we were using the OSR. BUT! - bit B3/16 will NOT be latched after a “fresh-out-of-the-box” test for the PLC-5 using the ONS. Automatically setting the addressed bit for the ONS (to a one) during pre-scan means that the rung conditions leading up to an ONS must - I repeat must - transition from FALSE-to-TRUE to make the ONS “fire”. There is NO such transition in rung 16 as shown above. Specifically, this rung is simply TRUE - TRUE - TRUE. (Exception to the “must transition” rule: Using the ONS bit somewhere else in the program might override the “marker” function of the bit.) Summing up: With a “fresh-out-of-the-box” test, the unconditional rung 16 for the SLC-5/03 WILL “fire” the OSR. Conversely: With a “fresh-out-of-the-box” test, the unconditional rung 16 for the PLC-5 will NOT “fire” the ONS. This is another one of those “PLC’s and SLC’s ain’t exactly the same” concepts that helps to keep us from getting bored with our jobs. Incidentally, I know that Keith is familiar with the “pre-scan” concept - the clever “home brew” solution for the “First Pass” condition which he suggested in his first post above proves that. But if any other readers are interested enough to ask, then I’ll try to give an overview of “pre-scan” at some time in the future. Best regards to all, Ron

[Keith Menges 0]

Ron- You are correct. I 'cut my teeth' on the classic PLC-5s. So most of my twisted logical concepts are tainted by that experience. Do you know if the pre-scan handling of the ONS status bits changed between the classic and new-platform PLC-5s? As a related point, when you say 'pre-scan' are you specifically referring to housekeeping prior to scanning in a program-to-run transition? Does the 'pre-scan' in your above statement include step housekeeping prior to step transition in an SFC? The reason I bring this up is the first time I used the blocking of the oneshot thing it was relative to an SFC state machine I built for machine mode control. The operator incremented through the modes using a pushbutton press. In my first cut the program simply raced through the state machine any time the button was pressed until I put in the blocking bit. Sorry about bringing PLC-5s and SFCs into a discussion about the SLC 5/03. But I figure it's like court; The PLC-5 was presented into evidence so I get to cross. Keith

[Guest tore]

OK, these replies made me feel very good ...... Last months I was working with a SLC 5/03 and IA16 modules..... the program was ok and worked well .... but two weeks late some one decided to substitute the IA16 with a IB16 modules (with the respective change of voltage signals of course)... but the program ran bad........ I didnt understand was going on !!!! and after few days finally I have had to change many rugs in my program.... The point is : the OSR on some rugs running well with the IA but with the IB not.... and thats made me crazy ...... Now I know... Im not the only one with these kind of problems (thanks god Im not crazy)..

[Guest Guest_twtm]

cool!!!