commenting out a rung (similar to # in c++)

[TConnolly]

If the old logic is for reference only, move it to a new ladder. Make it clear in your comments that the ladder is not to be called elsewhere in the program. You might go so far as to create a rung with an AFI and JSR to the new ladder.

If you go that way then put a RET instruction on the first line of the ladder. That way if someone ever does call it then it returns immediately.

 

[Ken Moore]

Coming from a TI 500/505 background, all my programs have an always false bit, in TI it was always C511, last bit on early processors,. So to this day, even in RS Logix, I still have an always false bit, usually B3:0/0 that is always false. Then you can use this bit to trouble shoot, simulate, etc..

 

[thingstodo]

Move the logic if you can

Adding a RET or a TND to the end of your program or subroutine and moving the logic to be commented out after that RET or TND will not let the logic execute and does not require additional logic added.

It does not help if you need the logic to stay in place for context

 

[daba]

Let us all get several things absolutely straight, there is too much discussion of MCR, AFI, and custom "Always False Bits" taking place....

Bernie hit the nail firmly on the head earlier....

1. MCR zoning a rung does not stop the processor executing the rung, i.e. it is not ignored. If you place an MCR zone around a rung of logic, then when the opening MCR instruction is FALSE, the following rungs are executed as normal, but the rung-in condition (the power-rail, if you like) is made FALSE. This will have the effect of turning OFF all non-retentive outputs, resetting TONs, freezing RTOs, starting TOFs timing, and preconditioning false-to-true transition triggered instructions to execute again when the MCR is made true again. I don't class this as "ignoring the code".

2. Putting an AFI on a rung does not stop the processor executing the rung, i.e. it is not ignored. The AFI will do exactly the same as a false MCR zone - see the above description.

Neither the MCR or AFI (or equivalent) will "comment out" a rung so that it is ignored. The ONLY way to achieve this is to stop the rung being scanned.

If you really, really, want the rung to stay in the executed code, but be ignored, then you will have to place a JMP in front of it it to a LBL rung after it. I would prefer to do this over moving the rung to the end of the file and using a TND in front of it. You can, of course, make the JMP conditional so you can "switch" the rung in or out.

Or you could simply remove the rung from the subroutine file into another that isn't JSR'd from anywhere.

Or delete the rung from the program completely. I would not advocate putting the deleted rung into "Test Edits" mode for anything longer than your own online session!

 

[Clay B.]

Coming from a TI 500/505 background, all my programs have an always false bit, in TI it was always C511, last bit on early processors,. So to this day, even in RS Logix, I still have an always false bit, usually B3:0/0 that is always false. Then you can use this bit to trouble shoot, simulate, etc..

I only use the B3 file for test bits so I can have more than one and only open one file when I need to "play" with them. On several of the machines I have built over the years this comes in handy for sensor/drive setup where I did not want normal operation. It also makes it easy when I review the program later because if I see a Bit with a B3 address or a integer with a N7 addresses (I only use these for testing and non normal operation also) I know that is a test function and not part of normal operation.

 

[AdamG8GXP]

I'm trying to do something similar with RSLogix 5000 V20.12, 1769-L36ERM PLC.
What I am trying to do is to do major changes to the subroutine, but I want to keep original for reference to troubleshoot.
I've made a backup copy of it with different name that is does not have a JSR to it from main routine. Yet the backup still have green rails when it doesn't have JSR to it from main.
I know that AFI will turn off OTE bit, rung in false condition will also turn off OTE bit.
Both subroutines have the same OTE bits. I want the PLC to only turn on/off the same OTE bits in one subroutine and ignore them in the backup. Is that possible?

I could keep back up ACD with one of those routines in each but then I would lose online state of the XIC, XIO bits in the back up.

Sorry about asking before trying but I would like to find out also if there consequences I don't know about if it actually works.

 

[AustralIan]

In logix5000, move the subroutine to a program in the unscheduled tasks folder.

Also, please standby for a forum moderator to lecture you about digging up old threads rather than starting a new thread.

 

[joseph_e2]

If the subroutine isn't being called, the code won't execute and it won't affect the machine. If it were me (and it has been), I would make a copy of the subroutine in question with a different name. Have a single rung in the main routine that has a single bit as input condition. If the bit is set, the new code is run; if not, the old code. That way only one JSR will be executed at at time.

 

[ASF]

I've made a backup copy of it with different name that is does not have a JSR to it from main routine. Yet the backup still have green rails when it doesn't have JSR to it from main.

I believe that it was only in quite a recent version of Logix Designer that they added the feature to turn off the "green rails" if the routine is never being called. Perhaps v27 or 28, someone like Geospark will probably know off the top of his head. I'm pretty certain it wasn't as far back as v20, so yes, even if your routine is not being scanned you will still have the green rails.

I know that AFI will turn off OTE bit, rung in false condition will also turn off OTE bit.
Both subroutines have the same OTE bits. I want the PLC to only turn on/off the same OTE bits in one subroutine and ignore them in the backup. Is that possible?

Certainly possible - but ONLY if you do not call the routine that contains the logic you want to ignore (as you've done) or you use a JMP to skip over it. If it's called at all - even if everything is AFI'd out - you're Not Gonna Have A Good Time.

Also, make sure you clean up after yourself when you've finished and delete the backup logic, because duplicating OTE's is in general bad practice, confusing, and makes me grumpy

 

[AdamG8GXP]

In logix5000, move the subroutine to a program in the unscheduled tasks folder.

Also, please standby for a forum moderator to lecture you about digging up old threads rather than starting a new thread.

Usually I get the lecture for starting a new thread on similar topic

 

[thingstodo]

I'm trying to do something similar with RSLogix 5000 V20.12, 1769-L36ERM PLC.
What I am trying to do is to do major changes to the subroutine, but I want to keep original for reference to troubleshoot.
I've made a backup copy of it with different name that is does not have a JSR to it from main routine. Yet the backup still have green rails when it doesn't have JSR to it from main.
I know that AFI will turn off OTE bit, rung in false condition will also turn off OTE bit.
Both subroutines have the same OTE bits. I want the PLC to only turn on/off the same OTE bits in one subroutine and ignore them in the backup. Is that possible?

I could keep back up ACD with one of those routines in each but then I would lose online state of the XIC, XIO bits in the back up.

Sorry about asking before trying but I would like to find out also if there consequences I don't know about if it actually works.

So far I agree with pretty much all of the comments ... to summarize:
- if the subroutine is not called, you don't have to worry about 'commenting out' the code - it is not executing
- to be paranoid, add a TND or RET as the first rung of the backup copy so that the subroutine returns immediately after being called instead of executing
- a separate unscheduled task works fine as well
- as mentioned, multiple OTEs to a single bit give warnings and make experienced programmers 'CRAZY' as they try to figure out what you did and why

My own comments, to add a bit ..
- I like using a NOP in the first rung, then tying a big comment to it to explain that the logic is not executing but is kept for reference
- My single bits, used to switch between 'old method' logic and 'new method' logic are called Upgrade, a boolean array of maybe 10 - 16 bits. Once you get past 16 upgrades at a time, you need to clean stuff up!
XIO Upgrade[1] JSR Old_SBR
XIC Upgrade[1] JSR New_SBR

- After your New_SBR has been running for a week/month/year you need to remove the old one, get rid of the Uprade[1] condition on the new one .. some housekeeping.
- If you don't clean house at least yearly, you begin to look at the old code and ask questions like 'did I DO THIS?' or 'Man, is this OLD CODE'.

I would like to think that I can point to my present code as an example of what a newbie should do ... not a list of things that a newbie should avoid!

This takes time .. but it's worth it when you are trying to bring a new contractor or new employee up to speed on how things are done. If there is no style or rules for them to follow, they will make up new stuff!! Exceptions drive *EVERYONE* crazy.