MicroLogix JSR's outputs staying on

Skidood · Feb 14, 2019

Hi there, apparently when a subroutine is suddenly no longer being called up in your program scan, the energized outputs in the subroutine will stay on.
In my case these outputs are valves. Not good!
Is it possible to eliminate this problem (have the outputs de-energize) by using bits for each physical output vs. direct outputs ? I would then place in the main ladder the needed rungs where if the bit is ON then it will energize the output (valve).
Or will bits stay on as well?

James Mcquade · Feb 14, 2019

I am assuming an Allen Bradley plc.
if possible, I would let the subroutine scan every scan. let the logic solve itself and operate the outputs based on the program logic. you will have a better program and less heartache in the future.
placing the outputs in the main program while the bits that turn the outputs is in the subroutine that is not called will accomplish nothing, the outputs will still be on if those bits are on.
if I am incorrect, someone please correct me.
james

harryting · Feb 14, 2019

James is right.

With AB PLC, it's bad practice to have conditional subroutine for many, many reasons. One of which OP already found out. I wouldn't even put non physical output in subroutine.

Skidood · Feb 14, 2019

Hmmm...well due to the complexity of the machine, and the fact that its operation takes the form of many different sequenced phases over an hour or more, (think dishwasher but 100 times more complicated) I hate the idea of the PLC scanning hundreds of rungs that are not relevant at that moment in time...and I can foresee that if I shouldn't be using subroutines that only get scanned at certain times, (such as during a particular phase of operation) I have a lot more programming work to do, and the subroutines will all be longer and more complicated. Hmm.

Bit_Bucket_07 · Feb 14, 2019

I don't have a problem with using subroutines in a program, and I see no reason to avoid calling a subroutine conditionally. One simply needs to reset any outputs that should be left in an off state when the subroutine is not being called.

daba · Feb 15, 2019

Bit_Bucket_07 said:
I don't have a problem with using subroutines in a program, and I see no reason to avoid calling a subroutine conditionally. One simply needs to reset any outputs that should be left in an off state when the subroutine is not being called.

I think the opposite way... The subroutines should be solving logic, and part of that logic is to determine what the output bits and words should be at any particular time.

Forcing bits OFF when they shouldn't be ON by any other means is just daft if the logic in the subroutines can do it.

When I started in PLC software control systems back in the 80's, my mentor specifically told me not to make subroutines conditional, "... scan all of the logic, all of the time - it makes things easier."

One other factor to consider is that debugging is easier, if code is not being scanned, your ladder view of it in the programming software can look weird, and give you the false impression that something else in the code is overwriting what the code you are looking at is doing. If you make your subroutines unconditional, you don't get false impressions, and if a rung is solving true, but the result is not what you expect, then something IS overwriting ....

Christoff84 · Feb 15, 2019

Skidood said:
Hmmm...well due to the complexity of the machine, and the fact that its operation takes the form of many different sequenced phases over an hour or more, (think dishwasher but 100 times more complicated) I hate the idea of the PLC scanning hundreds of rungs that are not relevant at that moment in time...and I can foresee that if I shouldn't be using subroutines that only get scanned at certain times, (such as during a particular phase of operation) I have a lot more programming work to do, and the subroutines will all be longer and more complicated. Hmm.

I agree with most of the sentiments in this thread. Yes you can make conditional subroutines, but at 3am on saturday morning, the person who has to troubleshoot why something isn't working, is going to curse your name up and down. Longer is not always more complicated, sometimes it helps. I like to think of subroutines as just a way to organise your thoughts when programming.

Another thing to watch for, please don't have your outputs on more then 1 rung. If you need multiple areas to turn an output on, use bits and have a master rung with all the bits needed to turn that output on, that will make troubleshooting so much easier.

When you're programming, always think of the next person who has to troubleshoot it (think of the very first time you had to read/troubleshoot someone elses programming)

Ken Moore · Feb 15, 2019

I have used conditional subroutines many times, it really comes into play on overloaded systems. You just have to beware that outputs and timers are no longer being processed. So they retain the last state they were in on the last scan.

I always map my IO to bits anyway. So...outside when the subroutine is not being called. Reset all your timers, and have your outputs go to the desired state, usually off.

cardosocea · Feb 15, 2019

harryting said:
James is right.

With AB PLC, it's bad practice to have conditional subroutine for many, many reasons. One of which OP already found out. I wouldn't even put non physical output in subroutine.

As far as I'm aware this is true for all PLC's. Also, jumps in the logic are to be avoided for the same reasons... particularly implementing logic loops with a jump.

Skidood · Feb 15, 2019

OP here...OK I have decided to make all my subroutines non-conditional. I can see why this might make troubleshooting easier if there's a problem. So now, the majority of the rungs in each sub are controlled by the same bit (as an input XIC) I was using to call or not call the sub in the main ladder. This way, if the bit is off, the rungs will be false and the outputs/ will not stay energized, the timers and one-shots will reset, etc. Thanks so much.

daba · Feb 15, 2019

Skidood said:
OP here...OK I have decided to make all my subroutines non-conditional. I can see why this might make troubleshooting easier if there's a problem. So now, the majority of the rungs in each sub are controlled by the same bit (as an input XIC) I was using to call or not call the sub in the main ladder. This way, if the bit is off, the rungs will be false and the outputs/ will not stay energized, the timers and one-shots will reset, etc. Thanks so much.

You could consider using MCR "zones" to put your outputs and timers in.

Read up on it, then realise it shouldn't be called Master Control Reset, quite the reverse, as it ENABLES the rungs in the zone when the opening MCR is TRUE. Might be better to think of it just as a rung power rail switch. Switch OFF (a FALSE conditional MCR) then the following rungs are all FALSE, switch back ON (i.e. the unconditional closing MCR), and the power rail is re-energised.

However, you won't see the power rail go off in the programming software, that is just an indication of Run Mode.

A much-hated instruction however, but it "does what it says on the tin", without additional conditionals in every rung.

mk42 · Feb 15, 2019

The only times I've seen conditional logic really make sense are when you are flipping between modes, and all the modes use the same tags/IO etc. This could be something like having one section of logic for manual, and a different section for auto. Maybe you need one set of logic while a process is ramping up, and different logic while it is ramping down. The same devices are controlled either way, so there are no risks about leaving a coil unattended.

HOWEVER, this is not a best practice. At a minimum, it makes the code harder for someone else to follow, especially if that person is either newer or not used to that programming style. If you program with jumps or conditionally calling code, odds are you'll be stuck supporting it yourself. 99% of the time, there is another way to solve the problem where there is only 1 coil per output, and all the conditional logic is built into one big rung. This is generally considered easier to read, and it is less likely to have wierd side effects like you experienced.

Skidood · Feb 15, 2019

Christoff84 Thank you. Someone else also told me to use bits for my valve outputs such rather than direct outputs. Yes there are several instances in my program where the same output is present on many different rungs in several other subroutines. However, I am absolutely certain that the output would not be energized by a different rung elsewhere in the program at any undesired time. Having said that, I already have set up bits for each output in a special IO Mode test routine where I can manually energize any output for testing purposes as needed. So if I am certain that an output is not going to energized by some other rung I have forgotten about, is there still a benefit to using output bits and another ladder where the bits will energize the output, as opposed to just using direct output addressing in my logic? Thanks so much. I appreciate it a lot.

Christoff84 said:
I agree with most of the sentiments in this thread. Yes you can make conditional subroutines, but at 3am on saturday morning, the person who has to troubleshoot why something isn't working, is going to curse your name up and down. Longer is not always more complicated, sometimes it helps. I like to think of subroutines as just a way to organise your thoughts when programming.

Another thing to watch for, please don't have your outputs on more then 1 rung. If you need multiple areas to turn an output on, use bits and have a master rung with all the bits needed to turn that output on, that will make troubleshooting so much easier.

When you're programming, always think of the next person who has to troubleshoot it (think of the very first time you had to read/troubleshoot someone elses programming)

Skidood · Feb 15, 2019

Hmm..interesting....

daba said:
You could consider using MCR "zones" to put your outputs and timers in.

Read up on it, then realise it shouldn't be called Master Control Reset, quite the reverse, as it ENABLES the rungs in the zone when the opening MCR is TRUE. Might be better to think of it just as a rung power rail switch. Switch OFF (a FALSE conditional MCR) then the following rungs are all FALSE, switch back ON (i.e. the unconditional closing MCR), and the power rail is re-energised.

However, you won't see the power rail go off in the programming software, that is just an indication of Run Mode.

A much-hated instruction however, but it "does what it says on the tin", without additional conditionals in every rung.

Skidood · Feb 15, 2019

Yes in my application the machine will run in several different modes which occur one after the other in a mostly fixed sequence. There are about 10 different modes. Each mode or "phase of operation" has its own subroutine. When the phase is complete, the subroutine unlatches itself and latches the next mode/subroutine. Each subroutine was called or not called in the main ladder by the latched bit for that particular subroutine. This was my "conditional logic" but I have now changed this so that all subroutines are called and evaluated but had to add these "subroutine ON or OFF" bits into each sub on most of the rungs. Looks messier on the screen but I can't have outputs or other instructions being left on when the program jumps to the next phase and stops calling the sub.

mk42 said:
The only times I've seen conditional logic really make sense are when you are flipping between modes, and all the modes use the same tags/IO etc. This could be something like having one section of logic for manual, and a different section for auto. Maybe you need one set of logic while a process is ramping up, and different logic while it is ramping down. The same devices are controlled either way, so there are no risks about leaving a coil unattended.

HOWEVER, this is not a best practice. At a minimum, it makes the code harder for someone else to follow, especially if that person is either newer or not used to that programming style. If you program with jumps or conditionally calling code, odds are you'll be stuck supporting it yourself. 99% of the time, there is another way to solve the problem where there is only 1 coil per output, and all the conditional logic is built into one big rung. This is generally considered easier to read, and it is less likely to have wierd side effects like you experienced.

MicroLogix JSR's outputs staying on

Skidood

Member

James Mcquade

Member

harryting

Lifetime Supporting Member

Skidood

Member

Bit_Bucket_07

Member

daba

Lifetime Supporting Member

Christoff84

Lifetime Supporting Member + Moderator

Ken Moore

Lifetime Supporting Member

cardosocea

Member

Skidood

Member

daba

Lifetime Supporting Member

mk42

Lifetime Supporting Member

Skidood

Member

Skidood

Member

Skidood

Member

Similar Topics