disable a rung in RS Logix 5

I was wondering what would be the most convenient way of disabling a rung of logic. In GE PLCs you can put an always_off but as contact at the beginning of the rung and that rung does not get scanned. So I was thinking if RS Logix 5 had something to that effect?

RS 5 has an AFI (always false instruction) that you can put ahead of the other instructions on the rung....

An Always Off contact in a GE processor does not prevent the rung from being scanned, it just causes the rung to be false. There's a big difference if there is an output coil on the rung.

In a PLC5 the AFI instruction does the same thing as a normally open contact addressed to Always Off in a GE. Anything after the AFI will evaluate as false.

If you want to truly disable a rung you can jump around it using the JMP instruction, or move it to the end of the ladder and use either a RTN (Return) or TND (Temporary End) in the rung preceding it, depending on whether the rung is in the main routine or a subroutine.

Do you have a JSR routine in your organiser for the specific ladder you want to disable ?

I would normally use a blocking bit in front of the JSR command to disable that part of the ladder. But then that all depends how the programme has been written and setup !

Greetings Indrani ...

I know it's been awhile, but remember we covered that ... for a "quick temporary" method for just a few minutes of online troubleshooting in the Run mode, one way is to Delete the rung - and Test the edits - but do NOT Assemble the edits ...

when the "power rails" turn white, the rung is not being acted upon - (it is essentially "disabled") ...

once you're through testing, then Untest the edits - and Cancel them ... the processor will start executing the rung again ...

if you need something that you can leave in place for a little while longer, I recommend the JMP/LBL method suggested by danny.michael ... just be sure to put the LBL in BEFORE you execute the JMP rung or the processor will fault ...

going further ... suppose that you have a rung which ONLY has something like an ADD, or an MOV, or a COP instruction for an output ... in cases like that, then an AFI will give the same effect as "disabling" or "deactivating" the rung ... remember to look at it this way: "What does an ADD do when False logic comes in?" ... since the answer is "Nothing" then you could certainly make the argument that the rung has been "disabled" or "deactivated" ...

on the other hand, for rungs with an OTE or a TON, or a CTU, etc. an AFI will not usually give the results that you're looking for ... specifically, those instructions DO SOMETHING whenever False logic comes in ...

give me a call if you need more explanation ... it will be good to talk with you again ...

PS Edit ...

there's more about the AFI "errors" in this old post ...

http://www.plctalk.net/qanda/showthread.php?p=5992&postcount=32

and some other "good stuff" too - if you have time to read the whole thread ...

I've also seen it done like so:

Assume an XIC is the first rung condition. If an XIO referencing the same address as the XIC is added in series the rung will never go true since a bit cannot be true and false at the same time.

This has somewhat limited usefulness but has the advantage that the original contact remains as a form of documentation.

.02

When Pigs Fly.....Lock it Out

:site:I always create a dummy contact way high up in the input list, say x600, and label it " When Pigs Fly" , then just insert it as an 'Examine On'..-II-, contact in any rung I want to lock out...:site:

David

no offense, but I think that some of you guys are missing the point ... the OP's request was how to "disable" a rung ... many of the methods that you're suggesting will NOT “disable” a rung – at least not in the sense that MOST people use the word “disabled” ...

instead what many of you are suggesting will allow the processor to still execute the rung – only the rung will be executed with FALSE logic ...

now many of you have been doing this sort of work long enough to have a general sense of what’s really going on during the processor’s execution of the ladder logic ... what you’re saying might indeed make perfect sense (and be perfectly correct) to YOU - based on how YOU personally interpret the word “disabled” ... please stop for a moment though and consider how misleading your suggestions might be to someone who doesn’t share your experience ... to MOST people, the word “disabled” means that the rung “won’t do ANYTHING” ... more specifically, the “disabled” rung will have NO effect on the operation of the program ...

now for SOME rungs (like a simple ADD rung) the methods that you’re suggesting will indeed cause the rung to have NO effect on the program ... but (and here’s my point) ... using the same techniques on something like an OTE rung will NOT cause the rung to have NO effect ... indeed the rung WILL still affect the program’s operation – specifically by writing a ZERO status into the associated bit ...

trust me, I have seen grown men SUFFER over these same concepts which might seem trivial to you ... if I had to put my finger on the one, single, most misunderstood concept in ladder logic it would be the confusion that exists between “NO logic” and “FALSE logic” ... to many people, even some with years of PLC experience, these two terms seem to be one-and-the-same thing ... trust me, they are NOT the same ...

I cover this particular topic in this lesson if you’d like to take a look ...

the whole video is only about eight minutes long – but if you’re short on time, just zoom ahead to the portion from 4:44 to 6:52 ...

as I’m probably going to be leaving this trade (regrettably) in the next few weeks, I’d like to leave behind at least a few of the things that I’ve learned over the years ... one of those things is that DIFFERENT people come away with DIFFERENT perceptions - even when hearing EXACTLY THE SAME words ...

again, I mean no offense – but I know from experience that MANY people can easily be confused and misled by the suggestions that some of you are making ...

so finally ... just making a rung FALSE does NOT “disable” the rung – at least not in the same sense that MOST people interpret the word “disable” ...

Ron Beaufort said:

as I’m probably going to be leaving this trade (regrettably) in the next few weeks,

Click to expand...

Say its not so. Where? retiring?
I have a extra lawn chair and more cool ones to share.

Greetings Mickey ...

hopefully (prayerfully) I’ll still be around for quite awhile ... but lately ALL of my customers are telling me: “Yes, we ARE going to be sending students to you – but it will be AT LEAST the third or fourth quarter before we can spend any money.” ...

the problem is that my expenses keep right on rolling along ...

this weekend I’ll be working on my resume ... I don’t WANT to give this up – it’s way too much fun ... but at the same time, I’ve got to make a living ... many of my regular customers were manufacturers of building materials ... most of those plants are completely shut down ... most of the rest of the plants are running at a much-reduced capacity ... this economy thing is hurting a lot of people ... seems like everybody’s afraid to spend any money ...

my crystal ball is cloudy ... I guess we’ll all just have to wait and see what happens next ... in the meantime I'm trying to come to grips with the possibilty that I might have to sell of my toys and go back to work for a change ...

Greetings jtn ...

there’s no documentation here - so I can’t tell exactly what this is supposed to accomplish ... but based on what you’ve posted:

if TestBit1 contains a ONE status, then the bit DisableRungOutputCoil will also contain a ONE status ...

if TestBit1 contains a ZERO status, then the bit DisableRungOutputCoil will also contain a ZERO status ...

in simplest terms, the status of DisableRungOutputCoil will simply “follow/mimic/duplicate/match” the status of TestBit1 ...

so ... the status of TestBit2, TestBit3, and TestBit4 become “don’t care” conditions – and therefore none of those bits will affect the status of DisableRungOutputCoil ...

is that what you were shooting for? ...

Ron Beaufort said:

Greetings jtn ...

there’s no documentation here - so I can’t tell exactly what this is supposed to accomplish ... but based on what you’ve posted:

if TestBit1 contains a ONE status, then the bit DisableRungOutputCoil will also contain a ONE status ...

if TestBit1 contains a ZERO status, then the bit DisableRungOutputCoil will also contain a ZERO status ...

in simplest terms, the status of DisableRungOutputCoil will simply “follow/mimic/duplicate/match” the status of TestBit1 ...

so ... the status of TestBit2, TestBit3, and TestBit4 become “don’t care” conditions – and therefore none of those bits will affect the status of DisableRungOutputCoil ...

is that what you were shooting for? ...

Click to expand...

That is what I was trying to do. If the lower rung was the original rung, it has essentially been disabled and new rung above it was put in that now controls the output of the coil. I have always used the test function to try code before assembling, but if you needed to test it over a weeks time before deleting the old rung this seems that it would work.