RSLogix 500 Instruction Help

mdeltat

Member
Join Date
May 2007
Location
Los Angeles, Ca
Posts
84
  1. What is the equivalent to an AFI in RSL500?
  2. An OTL will remain energized if the rung returns to a false condition. But, will the OTL de-energize then re-energize if the rung returns to a true condition before the OTU rung goes true? Or, will it just stay latched the whole time?
  3. Where can I find a tutorial or instruction on sequencers?
  4. Thank you for the coaching!
Joe
 
1) Create an Always Off bit. Choose an unused bit, make it zero, assign a symbol name sich as ALWAYS_OFF. To guarantee that someone doesn't set the bit you can program an unconditonal unlatch.
For example:

| ALWAYS_OFF
| B3/0
+-------------------------(OTU)---
|
| ALWAYS_OFF
| B3/0 O:2/0
+-----] [-------------------( )---- <- XIC B3/0 IS EQUIV TO AFI
|



2)It will stay latched until explicitly unlatched.

3)Search the forum using the keywords SQO and or SEQUENCER
 
The ONS instruction is not available within RSLogix500. However, they have the OSR instruction. OSR = One Shot Rising.

Depending on what you need to to, this hopefully will help you with your programming.
 
Last edited:
probably MORE than you wanted to know ...

Greetings Joe ...



let’s look at this part your post in detail ...



An OTL will remain energized if the rung returns to a false condition.



I know exactly what you mean ... but (no offense) your understanding of ladder logic is flawed ... you have a LOT of company in what you’re thinking - many people miss the underlying truth of what’s going on here ...



let’s dig deeper ... an OTL (latch) is an “instruction” which tells the PLC processor what to do ... specifically, when TRUE logic comes into the OTL instruction, the processor is instructed to “go write a ONE into a bit/box” in the processor’s data table ... more specifically, the OTL instruction does NOT become “energized” ... even more specifically, the bit/box identified by the OTL’s address is the ONLY “thing” that is affected by the OTL instruction - and (as I said) that bit/box takes on the status of ONE whenever the OTL tells the processor to “go write a ONE into the bit/box” ...



nailing down where we are so far ... an OTL does NOT become “energized” ... it only tells the processor to “go write a ONE into a particular bit/box” whenever TRUE logic comes into the OTL ... common cause of confusion: the OTL lights up green on the screen ... many people (including many instructors) point to the OTL and say “the green means that the OTL is energized” ... that is erroneous ... the only reason that the OTL turns green is because there happens to be a ONE in the associated bit/box ...



now let’s rephrase your original question to reflect this deeper understanding ...



if an OTL on a TRUE rung writes a status of ONE into a bit/box, the bit/box will retain its ONE status even if the OTL’s rung later returns to a false condition ...



now that latest statement is much nearer the truth of what actually goes on inside the PLC ... the main thing that’s still missing is that we haven’t covered what will happen if something else (usually an OTU instruction) happens to come along and change the status of the bit/box ... we’ll move on to that discussion next - but first notice something critical ...



the statement that I just made above concentrates on the STATUS OF A BIT/BOX located in the processor’s memory ... specifically, it does NOT concentrate on the STATUS OF THE OTL INSTRUCTION ... that subtle but critical difference is what makes me say that your understanding of ladder logic is flawed ... nailing it down: like most people, you’re looking mainly at the OTL on the ladder rung ... you SHOULD be looking at the ONE/ZERO status of the bit/box located in the processor’s data table ... that’s where the rubber meets the road ...



next let’s take a look at an OTU (unlatch) instruction - using the same explanation techniques that we used above ...





an OTU (unlatch) is an “instruction” which tells the PLC processor what to do ... specifically, when TRUE logic comes into the OTU instruction, the processor is instructed to “go write a ZERO into a bit/box” in the processor’s data table ... more specifically, the OTU instruction does NOT become “energized” or “de-energized” ... even more specifically, the bit/box identified by the OTU’s address is the ONLY “thing” that is affected by the OTU instruction - and (as I said) that bit/box takes on the status of ZERO whenever the OTU tells the processor to “go write a ZERO into the bit/box” ...



nailing down where we are so far ... an OTU does NOT become “energized” - or “de-energized” ... it only tells the processor to “go write a ZERO into a particular bit/box” whenever TRUE logic comes into the OTU ... common cause of confusion: the OTU sometimes lights up green on the screen - even when the rung condition is FALSE ... many people (including many instructors) are totally confused by this effect ... the only reason that the OTU turns green is because there happens to be a ONE in the associated bit/box ...



hardcore learning exercise: do NOT take my word for anything that I’m saying ... prove it to yourself ... open a spare OFFLINE file and program two simple rungs ... end one of the rungs with an OTL - addressed to ANY bit that you choose ... end the other rung with an OTU - and address it to the SAME bit as the other rung ... you can use ANY condition that you choose for the left end of the rungs ... you may even leave the rungs completely empty except for the OTL and OTU instructions ... none of this will make any difference ...


deeper.JPG



now right-click the OTL and “toggle the bit” ... notice that the OTL turns green on the screen ... ask yourself why that happens ... look at the OTU ... suddenly it’s green too ... why? ... now look at the status of the bit back in the processor’s data table ... you’ll see a ONE stored there ... why? ...



next right-click on the OTL again (not the OTU just yet) and “toggle the bit” again ... notice that the OTL loses its green highlight ... why? ... look at the OTU ... it’s lost its green highlight too ... why? ... now look at the status of the bit back in the processor’s data table ... you’ll see a ZERO stored there ... why? ...



during all of these experiments, don’t lose track of this critical concept: since you’re OFFLINE, there is NO processor involved in this experiment ... only you - and the RSLogix software ... specifically, NOTHING is being “energized” or “de-energized” ... it’s the SOFTWARE who’s painting the screen green - NOT (I repeat NOT) the processor ...



now do the same “toggle bit” trick on the OTU - and then on the actual bit/box back in the processor’s data table ... notice that the effect on the green highlights for BOTH the OTL and the OTU will ALWAYS be the same - regardless of where you right-click and toggle ...



the point: there is NO WAY to explain what you’re seeing with your own eyes by using your original view of ladder logic ... that’s why I said that it was “flawed” ... but the method that I’m teaching you here is perfectly able to analyze, understand, and predict EXACTLY what will happen - EVEN when you put the program into a processor and actually run it ...


continued in next post ...
 
now where were we? ... let’s rephrase your original quote for an OTL into something that fits an OTU ...



if an OTU on a TRUE rung writes a status of ZERO into a bit/box, the bit/box will retain its ZERO status even if the OTU’s rung later returns to a false condition ...



tricky questions: does the OTU become highlighted in green when it’s “actively” affecting the status of the bit/box? ... how about when it’s “energized” into action? ... how about when its rung is TRUE and it’s “de-energizing” the bit/box to a ZERO? ... notice how confusing questions like these can be - when using your original way of looking at things ... but once you look at it my way, things become very simple ...



in normal situations, if there’s a ONE in the bit/box then the OTL and the OTU will be highlighted in green ... specifically, the green has NOTHING to do with whether the rung is TRUE or whether the rung is FALSE ... it’s the status of the associated bit/box which tells the software (not the processor) when to highlight the instructions on the screen ...



going even deeper: the screen display often LIES to us ...



explanation: when you’re ONLINE (communicating with the processor) the display that you see on the screen is NOT quite “real-time” ... in other words, the RSLogix500 software is (usually) only able to communicate with the processor at the very end of the ladder rungs ... the point: the status of the bit/box may actually change MANY times during the execution of the ladder rungs ... what you see on the screen will (usually) be only the LAST status ... specifically, you normally won’t see the intermittent status conditions on your screen - but they DO happen inside the processor ...



once again, the main thing that’s missing from my quoted OTU statement above, is that we haven’t covered what will happen if something else (usually an OTL instruction) happens to come along and change the status of the bit/box ... but at least we’ve totally nailed down the normal operation of the OTU ...



and again, notice that the statement that I made above concentrates on the STATUS OF A BIT/BOX located in the processor’s memory ... specifically, it does NOT concentrate on the STATUS OF THE OTU INSTRUCTION ... as I said earlier, most people look only at the OTU on the ladder rung ... they SHOULD be looking at the ONE/ZERO status of the bit/box located in the processor’s data table ... that’s the part that really counts ...



here for convenience, is your original question:



An OTL will remain energized if the rung returns to a false condition. But, will the OTL de-energize then re-energize if the rung returns to a true condition before the OTU rung goes true? Or, will it just stay latched the whole time?



no offense - but your understanding was so flawed that there’s really no way to give a yes or no answer to that ... but here’s something to hang your hat on from all of this ...



EACH and EVERY time that the processor executes an OTL (latch) instruction with TRUE logic, then a status of ONE will be written into the associated bit/box ... it’s really as simple as that ...



and ... EACH and EVERY time that the processor executes an OTU (unlatch) instruction with TRUE logic, then a status of ZERO will be written into the associated bit/box ... and that’s all that there is to it ...



now ... for the magic EUREKA! moment ... take those two statements and apply them to ANY set of rungs and you should be able to accurately understand - and predict - EXACTLY what will happen as the processor executes its program ... if you can’t, then pick up the phone and give me a call ... I’ll be glad to walk you through the steps ...



what this all means to you - from a philosophical standpoint ...



suppose that you told me that “the world is flat” ... I would tell you that your understanding is flawed ... I could prove my point by sailing completely around the world ... but you could still choose to ignore me - as long as you never have to travel too far in any one direction ... so ... believing that “the world is flat” is OK in many cases ...



suppose that you told me that “what goes up must come down”... I would tell you that your understanding is flawed ... I could prove my point by placing a satellite into orbit ... but you could still choose to ignore me - as long as you never have to deal with rockets ... so ... believing that “what goes up must come down” is OK in many cases ...



suppose that you told me that “OTL and OTU instructions become energized and de-energized” ...



I would tell you that your understanding is flawed ... I could prove my point by programming a few simple rungs and using just a few switches and lamp bulbs ... but you could still choose to ignore me - as long as you never have to deal with “problem situations” in a PLC-controlled system ... so ... believing that “OTL and OTU instructions become energized and de-energized” is OK in many cases ...



now the question becomes: how many times will you ever have to deal with “problem situations” in a PLC-controlled system? ... and the answer to THAT question is what will determine whether you choose to ignore what I’m saying ... or whether you decide to go further down the path of enlightenment ...



choose wisely ...
 
Last edited:
smohamed said:
The ONS instruction is not available within RSLogix500. However, they have the OSR instruction. OSR = One Shot Rising.

Depending on what you need to to, this hopefully will help you with your programming.

Thats not exactly true. The ONS instruction is available with RSLogix500 but only with the ML1100,ML1200 and ML1500 controllers.
 
Whew! Well I,m glad you set me straight now before years of agony resulted from my misconception. It seems that asking you to expand could sound ridiculous, however, that is what I must do. Further down the rabbit hole...
What if anythig are the implications of addressing an OTE as an Output(O:3/0), in the this case would the output have power as long as the OTL and OTU were green (1 in O:3/0)? Also, can you speak further of these LIES? How can we monitor these latches to be confident that we are witnessing their current state?


It's as if the electrons know their being watched!
 
Depends on placement of the OTE in relation to an OTL or OTU of the same address. There's lots of permutations so in short, you don't typically use an OTL/OTU with an OTE. But, as I understand it:

If the OTE is after the OTL or OTU, then it will turn on/off the bit accordingly. If the OTE rung is true, the bit will turn ON, no matter what the previous OTL/OTU state is. If the OTE rung is false, the bit will turn OFF, no matter what the previous OTL/OTU state is.

On the flip side, if the OTE is before an OTL or OTU then it depends. If the OTE rung is true then the bit turns On. Then if an OTL is True or False or an OTU is false, the bit stays On. If the OTU is True, then the bit turns off. Conversely, if the OTE rung is False then the bit turns Off. Then if an OTL is False or an OTU is True or False, the bit stays Off. If the OTL is True, the bit turns back on.

That's the way I understand it, but of course Ron will prove me wrong :)
 
Whew! Well I’m glad you set me straight now before years of agony resulted from my misconception.



I appreciate your humor - but it is quite common to have “seasoned” technicians arrive in my classes with the following attitude:



“OK ... I’ve got 10 years of PLC experience behind me ... this five-day class starts at the basic beginner level ... that means I’ll have at least two or three days of slack before the “green” guys catch up ... I’ll just kick back and take it easy until Thursday or so ... then MAYBE I’ll start to pick up a few things ... I’d better take a book to read” ...



then first thing Monday morning we start getting into how the screen can lie to us - and many other things along those lines ... there have been SEVERAL cases where the “experienced” guy has literally slammed his book down against the desk and then paced around the room - and finally demanded, “Do you mean to tell me that I’ve been misunderstanding this stuff for 10 years?” ... now I certainly don’t want to start a fight - and he’s scaring the children ... so as calmly as I can, I say something like, “No, sir, I’m not TELLING you anything. I’m just programming a few simple rungs - with a couple of simple switches - and a couple of simple lamp bulbs ... all I’m asking you to do is use your experience to tell me whether the lamps are going to be ON, or OFF, or FLICKERING.” ... after the guy settles down and starts to really listen to what I’m teaching him, then he usually becomes a model student ... you’ll hear things like, “so THAT’S why we couldn’t get machine #2 to run” ... and “NOW I see why I couldn’t use a force in that situation” ... and so on and on ... read through the student comments on my website and you’ll find case after case where “experienced” technicians have had their eyes opened by learning the “basic” concepts that we’re talking about here ...



so it’s OK to laugh - but to a frustrated technician who’s trying to get a machine back in operation, these are NOT humorous topics ...



It seems that asking you to expand could sound ridiculous, however, that is what I must do. Further down the rabbit hole ...



actually there’s quite a bit that I’ve been forced to leave out ... and I know that SOUNDS like what I’m teaching is very complicated - but it’s not really ... all of this material normally takes less than ten minutes of explanation in a classroom with a couple of hands-on demonstrations ... but we’ll do the best that we can over the forum ...



What if anything are the implications of addressing an OTE as an Output(O:3/0), in this case would the output have power as long as the OTL and OTU were green (1 in O:3/0)?



your question is more complicated to answer than I have time to type - but my distinguished colleague robertmee has done an excellent job in his post ... the only thing “un-good” about his explanation is that he doesn’t draw an obvious distinction between the “BIT” (which is a box in the processor’s data table) and the output “DEVICE” (which is located in the field) ... that is an extremely common way of looking at things ... and it works well enough in MOST cases ... the “problem” surfaces when we’re dealing with a machine which is NOT functioning correctly ... in other words, when we’re actually TROUBLESHOOTING a system, the distinction between a “bit” and a “device” in the field may become “NOT trivial” matters ...



side trip: suppose that the plant’s technicians have been working for quite awhile on a machine that they are unable to repair ... the boss finally calls in reinforcements - an expensive outside contractor ... (a “guru” so to speak) ... the guy goes online with the processor and, sure enough, in ten minutes he’s pinpointed the problem ... now the question: what secret knowledge does the guru possess that allows him to succeed where the merely talented and experienced plant technicians failed? ... in many cases, the answer is that he fully understands the difference between the “bits” and the “devices” in the field ... specifically, they are NOT one and the same thing ...



Also, can you speak further of these LIES?



certainly ... here’s a quick demonstration along the lines of those that I use in my classes ...



mdt.JPG




first, notice that in the LEFT panel the switch I:2/0 is turned ON ... but in the RIGHT panel the switch is turned OFF ... notice that there are FOUR actual output addresses being used - O:6/0 through O:6/3 ... and here is a chart showing what ACTUALLY happens in the FIELD ... try this yourself with a spare system and you should be able to duplicate the results ... (notice that we’re using an SLC-500 system here ... you can get different results with a PLC-5 or a ControlLogix system) ...



Left Panel

------------

I:2/0 = ON

O:6/0 = ON

O:6/1 = ON

O:6/2 = OFF

O:6/3 = ON



Right Panel

------------

I:2/0 = OFF

O:6/0 = OFF

O:6/1 = ON

O:6/2 = OFF

O:6/3 = ON



IMPORTANT: remember that the chart above shows the ACTUAL conditions of the devices IN THE FIELD ... specifically, these are NOT necessarily the status of the bits in the processor’s DATA TABLE ... and THAT’S what we’re trying to demonstrate ...



compare the two panels side by side and notice that the screen is clearly LYING to us from time to time ... for one specific example: the actual ON/OFF conditions of the output devices IN THE FIELD for outputs 1, 2, and 3 NEVER CHANGE regardless of the green highlights shown on the controlling rungs ... now THAT’S a clear-cut case of LYING no matter how you slice it ... and we could go on - but I think that I’ve made my point ...



specifically, if ALL that you consider is the “green highlighting” on the screen while you’re troubleshooting, then there are going to be some cases where your conclusions will be WRONG ... how embarrassing could it be for a “guru” to show up - and have him nail a problem in ten minutes that you’d been working on for hours? ...



How can we monitor these latches to be confident that we are witnessing their current state?



a better way to phrase that question would be: “How can we monitor these BITS to be confident that we are witnessing their current state?”



this is one of the most reliable methods ...



mdt_2.JPG





notice that I’ve used “floating point” variables - and NOT integers ... the integers will quickly overflow and could cause a processor fault ... the floating point variables won’t do that ...



here the value of F8:1 is increasing like crazy - because the bit/box for O:6/0 contains a ONE each time the XIC on rung 0001 is scanned ... therefore the ADD gets executed with TRUE logic - and increases the value of F8:1 on each scan ... the fact that the XIC is NOT highlighted with green is totally meaningless ... the “add test” tells the truth ... the screen lies ...



on the other hand, the value of F8:2 is NOT increasing at all - because the bit/box for O:6/0 contains a ZERO each time the XIC on rung 0003 is scanned ... therefore the ADD gets executed with FALSE logic on each scan - and does NOT increase the value of F8:2 ...



the “trick” is that the OTE in rung 0000 always writes a ONE into the bit/box BEFORE the XIC on rung 0001 looks in the bit/box for a ONE ...



then the OTU on rung 0002 always writes a ZERO into the bit/box BEFORE the XIC on rung 0003 looks in the bit/box for a ONE ...



so the bit/box is rapidly flip/flopping between a state of ONE and a state of ZERO during each and every scan ...



the actual output device for bit/box O:6/0 - located in the field - remains OFF ... that’s because only the “last” value stored in the bit/box is sent to the output module at the end of the ladder logic ...



PS Edit ... if you haven't seen the Email Quizzes that I have on my website, you might find them interesting ... they cover subjects like this in quite a bit of detail ... look in the "Sample Lessons" area ...
 
Last edited:
I really hate it when people use the same addressed Output more then once in a program. Really makes it hard to troubleshoot in the middle of the night. Please do all you can to discourage this practice.
 
excellent point, Chris S ...

I'm sorry if I didn't make myself more clear ... these programs are NOT intended for use in actual production machines ... instead they are for EDUCATIONAL USE ONLY! ... they are only intended to show what happens when things are done WRONG! ... hopefully covering them here will keep people from making similar mistakes in “real life” ... and possibly help in troubleshooting situations where the inevitable errors “just happen” ...
 
yup I understood that but just want to point out that the example was an incorrect Real-World way of programming. Besides I know people who have been working with PLC for around 15 years that forget to check if the relay card went bad only to find out 8 hours later that O:3/8 was on but the relay inside the card died on us.

Opps
 
Ron,

I was in one of those advanced PLC5 Class in Knoxville a few years back. On the first day the instructor asks us "how do we turn off a bit in a PLC?" Only two of us had an answer. Unlatch. But, point is, unless you use latches, you never think about "turning a bit off" only what "turns it on", then it's off the rest of the time.
 

Similar Topics

I'm trying to fix a mess of code on an older machine that's running a Micrologix 1400 and an RS232 ASCII barcode scanner. The previous guy had...
Replies
3
Views
308
Can someone explain to me the purpose of this IOM instruction? N10:8 is fed from a PID and as you can see, when the PID Control bit is enabled...
Replies
2
Views
1,382
Is there a way to increase the size of the instructions in the tool bar?
Replies
2
Views
1,885
Hi All, this forum has been of a great help for me in learning. i have two problems 1- I have setup an alarm so i want to calculate the number...
Replies
4
Views
2,886
Hi All, I am new to plc programming. I have created a ladder logic in rslogix 500. Now I want to give input at one plc and get the output on the...
Replies
16
Views
10,957
Back
Top Bottom