TLP LogixPro Simulator - How to Comment out rung?

[ProgRambo]

It doesn't seem like the program supports it, but I'd like to be able to comment out a rung to troubleshoot the rung above it. I normally use the 'Cut Rung' option and paste it back in when I'm ready. But If I'd like to temporarily remove more than 1 rung, 'Cut' isn't an option.

I've tried cutting and pasting a rung past the END rung, but no dice there. I really hope I don't have to revert to completely removing the two rungs and rebuilding from scratch. Hopefully someone has a better idea out there.

Thanks!

 

[sparkie]

Use a bit that is always zero. I like to tag the bit "AlwaysOff" or something similar. Then when you want to "comment out of a rung" you just place an XIC with that bit at the very beginning of the rung and it will always be false when evaluated.

 

[ASF]

Just because a rung has an always false at the start, doesn't mean it doesn't do anything. Think about a timer. If it's rung-in condition is false, then it sets it's .EN bit to zero, it's .DN bit to zero, it's .ACC to zero, and it's .TT bit to zero.

There's a difference between a rung being false and a rung being not there. Unfortunately, there's no way that I know of to "comment out" a rung of ladder code - only in ST (which doesn't apply to LogixPro).

 

[FJaeger]

You could use a JMP and LBL pair around the rung(s) you want to comment out. It'll get ugly real quick, but it works fine for troubleshooting.

I don't think you can program past the end rung, but you could use a "Temporary End" (TND) to get around that. I'm not sure if Logix Pro supports a TND but RS500 does.

 

[ASF]

You could use a JMP and LBL pair around the rung(s) you want to comment out. It'll get ugly real quick, but it works fine for troubleshooting.

Of course! JMP and LBL is a great idea! I mean, yes, ugly as hell and if I catch you leaving them in a finished program I'll slap you across the face with a salmon, but it'll have the effect of cutting/commenting the rungs out.

 

[ProgRambo]

Wow, didn't expect to get so many comments so quickly!

Great idea about the always zero bit for simpler rungs. I think that'll do for the specific rungs I have in mind. I'll give it a shot tomorrow.

I'm still in the learning stages so I haven't yet got to JMP and LBL, but I'll look into them if it'll be able to do what I'm hoping.

Great advice so far, thanks!

 

[sparkie]

Just because a rung has an always false at the start, doesn't mean it doesn't do anything. Think about a timer. If it's rung-in condition is false, then it sets it's .EN bit to zero, it's .DN bit to zero, it's .ACC to zero, and it's .TT bit to zero.

There's a difference between a rung being false and a rung being not there. Unfortunately, there's no way that I know of to "comment out" a rung of ladder code - only in ST (which doesn't apply to LogixPro).

You are absolutely right on this one, but I can't think of any example where you would have something energize with a single XIO Timer.TT alone controlling a bit. Of course, that doesn't mean it isn't out there, but I wouldn't consider it a good programming practice.

Thinking back on it though, I can see this changing other logic if the rung is parsed after another rung using a counter or timer. I guess I have just never used it on a timer, counter, etc so I have never ran into the issue. I always used online edits for testing logic like that. Of course, that is why I visit these forums every day.

 

[ASF]

The timer was just an example - there are much more, uhm, "creative" ways of finding out this difference. I learned it after I put some diagnostic code in a PLC from my hotel room in Papua New Guinea, only to find that it caused the PLC to fault the next day (that'll teach me for trying to write overly complex diagnostic code after a 12 hour day on a terrible internet connection). I whacked an AFI in front of the rung to "disable" it until I was back in Australia to look at it properly, but 20 minutes later, the PLC faulted again, on the same rung.

I was using indirect addressing to fill an array with diagnostic data. Turns out that I was re-using a pointer that was occasionally used elsewhere in the code. On those occasions, if it happened to get to a value higher than the size of my diagnostic array, my rung all of a sudden had an indirect address to an array element that doesn't exist. And even if your rung is completely false, it'll still evaluate everything on the rung to determine if something needs to be done with it. So, my MOV instruction was evaluated - it wasn't going to actually do anything with it, but it still went as far as determining what the values are that it's not going to do anything with. So as soon as it encountered the out of range pointer - PLC fault.

Interestingly, you can do this trick on a SoftLogix PLC, and it won't crash unless the rung goes true. But Control Logix will.


That's why I'm so adamant about there being a difference between a rung being "disabled" and a rung being "false"