Double output coils - Micrologix 1000

[lc03]

I have always been led to believe that double output coils are unpredictable and that I should avoid them like the plague, but is the the case, or are they totally predictable, and bearing this in mind could I use them to my advantage in the program.

My thoughts are that if I want to disable bits or outputs on an existing program on occasion, without making large changes to the logic I could use an extra subroutine with always off (or on if required) output coils and only scan the subroutine when required.

 

[PhilipW]

You are quite right, multiple OTE's to the same address are not so much unpredictable, as unlovely. They operate according to the rule: "last condition scanned always wins". The trouble is that if the instances of the address in use are scattered at random throughout the program (and not documented as such!!!) then the next poor sod who comes along has to search on all them all to find out which one is the last one being scanned at the moment. And if you are turning subroutines on and off dymanically this can become rapidly more trouble than it was worth.

Here are two ok ways to achieve what you want (and more exist I am sure):

1 In each subroutine create a unique flag to drive the output, and then in some section at the end of the program parallel them all together to drive the actual physical output. This method has the merit of making it easy to see which condition is actively driving the output and would be the approach I would normally take. (Remember that when you stop scanning a subroutine the last values you write will remain until overwritten by some other logic, ie you need to make sure each of these flags is turned off before you stop calling the subroutine!)

2. Another neat way around this is to allow multiple instances of the physical output address, BUT the first instance is implemented with an OTE, and ALL the subsequent instances are implemented with an OTL. This allows the address to be used mulitple times but the rule now is "any true condition scanned wins", which is what you want. This method is a little harder to troubleshoot and some folk would object to it, but if documented decently it does work quite well.

What I suggest is setting up a small test program to try both of the methods out and see which makes best sense in your application.

 

[jstolaruk]

You are quite right, multiple OTE's to the same address are not so much unpredictable, as unlovely. They operate according to the rule: "last condition scanned always wins". The trouble is that if the instances of the address in use are scattered at random throughout the program (and not documented as such!!!) then the next poor sod who comes along has to search on all them all to find out which one is the last one being scanned at the moment. And if you are turning subroutines on and off dymanically this can become rapidly more trouble than it was worth.

Here are two ok ways to achieve what you want (and more exist I am sure):

1 In each subroutine create a unique flag to drive the output, and then in some section at the end of the program parallel them all together to drive the actual physical output. This method has the merit of making it easy to see which condition is actively driving the output and would be the approach I would normally take. (Remember that when you stop scanning a subroutine the last values you write will remain until overwritten by some other logic, ie you need to make sure each of these flags is turned off before you stop calling the subroutine!)

2. Another neat way around this is to allow multiple instances of the physical output address, BUT the first instance is implemented with an OTE, and ALL the subsequent instances are implemented with an OTL. This allows the address to be used mulitple times but the rule now is "any true condition scanned wins", which is what you want. This method is a little harder to troubleshoot and some folk would object to it, but if documented decently it does work quite well.

What I suggest is setting up a small test program to try both of the methods out and see which makes best sense in your application.

Option #1 is okay and many facilities I work in will often have in their specification that #2 is not allowed.

If I find that any addresses has multiple OTE instructions other than the OTU/OTL pair, I know I'm dealing with a mess and that I'm in for a rough time editting it.

Use the rule that a bit address gets no more than OTE instruction and the guy that has to edit your code later will thank you (or at least will not be swearing at you under his breath).

PS: Personally I find conditional use of subroutines bad form too but thats just me.

 

[Tom Jenkins]

I use Phillip's method #1. I quite frankly can't imagine why you would NEED to address the output more than once in a program. It's not like using the extra coils as flags will cost you anything, and sitting there an extra few hours trying to debug spaghetti code with multiple output coils WILL cost you.

 

[Terry Woods]

Just an example of where multiple instances of a particular output is reasonable...

A particular combination of logic produces a pseudo one-shot call for..."Check for Case".



    ?

---| |---- * * * -----(     )  Check for Case



The routine is looking for the highest priority case of such-n-such.

The Cases are A, B,... X, from highest to lowest priority.





  Check

   For                    +--------------+

  Case        Case-A      |    Write     |

---| |----------| |-------+ Case-Code-A  +---( RST ) Check for Case

                          |   to V100    |

                          +--------------+



  Check

   For                    +--------------+

  Case        Case-B      |    Write     |

---| |----------| |-------+ Case-Code-B  +---( RST ) Check for Case

                          |   to V100    |

                          +--------------+

                                 *

                                 *

                                 *

  Check                          *

   For                    +--------------+

  Case        Case-X      |    Write     |

---| |----------| |-------+ Case-Code-X  +---( RST ) Check for Case

                          |   to V100    |

                          +--------------+



  Check                           

   For                                       

  Case                                    

---| |---------------------------------------( RST ) Check for Case

As soon as the first (highest priority) is found and recorded, Check for Case is Reset and the routine is cancelled - immediately. If no Cases are found by the end of the routine then the final rung of the routine cancels the call.

If Check for Case was not reset as soon as the first case was detected then any subsequent case would overwrite the previous case-code in V100.

Sure... there are other ways to do this... maybe some better... maybe not.


Multiple instances of a particular output is not against the law...
It only requires practical consideration and wise employment.

 

[jstolaruk]

I imagine that would work fine for PLCs that scan left to right, top to bottom. But I believe a 984 scans top to bottom, left to right in each network and that code would not work unless each rung used its own network.

 

[Terry Woods]

I'm pretty sure that my example shows one rung per network.

 

[lc03]

OK,


Thanks everyone for the replies, my reasoning for using the double output coil method is that there are lot of outputs to deal with, and it is only a temporary change, therefore I didn't want to change the original code, but just add an extra subroutine that could be removed again later.

jstolaruk:
Why do you think it is bad form to use subroutines conditionally? Apart from the fact that they enable you to use the same code multiple times, I think the fact that you can call them conditionally is the next biggest attraction

 

[jstolaruk]

The biggest reason: I have to turn over code to plant maintenence which is normally electricians with no in-depth programming experience. They're generally not comfortable with subroutines to begin with. Conditional JSRs real play havic. You'd be surprised how many plants I work with that do NOT allow any subroutine programming. When I install a machine, just before turning over to the plant, I have to get rid of all of the subroutines and move the code into one file. If there were multiple calls to subroutines, it gets real messy.

IMHO, for true machine control of real world devices, multiple JSR calls doesn't have a big list of advantages. For data processing it does.

As I said, its just a personal preference.

 

[Tom Jenkins]

Personal Preference

It seems to me that, in the long hours of debugging, this version will work as well and be easier to track:

  

 Check



   For                    +--------------+



  Case        Case-A      |    Write     |



---| |----------| |-----+--+ Case-Code-A  |



                        | |   to V100    |



                        | +--------------+

                        |

                        |

                        +------(Case A)



  Check



   For                    +--------------+



  Case     Case-B  Case A |    Write     



---| |----------| |---|\|-+ Case-Code-B  +



                          |   to V100    |



                          +--------------+



                                 *

 

[Terry Woods]

  Check

   For  Case  Case  Case  Case  Case  Case       Case  +--------------+

  Case   Z     Y     X     W     V     U          A    |    Write     |

---| |--| |---|/|---|/|---|/|---|/|---|/|- *** - |/|-+-+ Case-Code-Z  |

                                                       |   to V100    |

                                                       +--------------+

C'mon... are you kidding?

There is no troubleshooting problem with my code. It is simple, straight forward and local.

I know you hate SET/RST Tom.

I can appreciate that a SET might exist anywhere in the program, although searching for a particular output repeatedly until the single instance is verified or, all instances are found, is not an abnormal thing to do. In fact, it is a normal thing to do.

However, a RST ain't no SET.

I know, after these several years, I'll never change your mind about SET/RST... OK, whatever.

However, they exist and they work. All it takes is reasonable usage.

As Peter said a long time ago... "Tom is too rigid."

 

[CaseyK]

Tom's posts have given me an idea. Rather then have students write (hehe) programs for "their" projects, why not give them 5 real life programs for machines that may or may not work, and let them figure it out. Then give them 5 that have problems insterterd, and try to figure them out. The double coil would be a good one, perhaps a few "always_off".

But then, new posts will show up, eg "Can someone held me debug my program".

oh well, it was just a thought.

regards.....casey