Duplicating Outputs General Question

[deanfran]

Reading Bering C Sparky's thread about his seafaring adventures (Congrats on the new job by the way),led me to the discussion about Stage Programming. So I worked through Ron's grinder example for the Do-More platform. See attached. Of course I received the messages about reusing outputs. In this case, I believe I can "judiciously" ignore the messages. I am trying to better understand this concept. I get the basics about not generally not reusing an output in multiple rungs, and the "unexpected" behavior that could result. In addition the idea of repeating an output in multiple program blocks might result in similar problems. I have developed the habit of using C bits on the coil side pretty much exclusively if its anything beyond this simple example. What are other general rules that make for smart practices?

 

[seth350]

Others have seen more, and I have seen some.

We have machines here running with multiple outputs addressed to different rungs and have had no trouble. I don't personally do it, but the integrator did. Should I change it? No. Why shouldn't I? Because it works, and the whole world isn't having to follow the code.

I also normally don't write in cursive, but others always do. It would be so nice if everyone's handwriting were the same. But that is not so, and never will be. So should you try to write your letters as I do? However, there are some common industry "rules of thumb" that will vary from person to person. Don't get hung up trying to spit code out like the next guy. Spit out code that works and that any Joe Smoe could comprehend.

Here are some mantras for your reading enjoyment...
1.Don't control an MCR with a PLC.

2.Don't password protect the processor.

3.Always add comments to rungs/instructions.

4.Don't program anything so that ONLY you know how it works. (There are other people who live at work at night.)

4a.If you must program something that only you will know how it works, then keep it away from the other code. And write at the top... "Nothing to see here.."

5.Save all programs somewhere so that all can access it. It keeps heat off of you the next morning.

6.Try to not install Windows Updates on your programming machine.

6a.IT is not your friend.

7.Never give completion dates without a contingency plan.

**** don't run uphill.
Payday is on Friday.
Don't chew on your finger nails.

 

[kwade]

Others have seen more, and I have seen some.
...
**** don't run uphill.
Payday is on Friday.
Don't chew on your finger nails.

Seth, you should go over to mrplc forum and post some of your mantras for inclusion into PLC-LAW.
The 2016 edition has already been posted, you may make it into the 2017 edition.

 

[seth350]

LOL, thanks for the link those are some good "rules".

 

[James Mcquade]

Do not have multiple latch / unlatch rungs for the same bit.

Generally speaking, IT in most cases is not your friend. Where I am now, I am one of the IT guys and we do the plc, MMI, and HMI programming.

Maintenance is your best friend and worst enemy. If you work with them and explain how your code works, they will bend over backwards to fix the problem. If you DON'T work with them, the machine most likely can't get fixed by maintenance and you get the call at all hours of the day and NIGHT !!.

Maintenance cannot read your mind, so have good plc documentation and work instruction manuals.

james

 

[seth350]

Unless your in my boat and maintenance can't even go online with a micrologix 1000. Then do what you want! lol j/k dont do that...

 

[Pete.S.]

I like duplicated outputs.

If it's a complicated system I know it was a pro who made the programming.
If it's a simple program I know it was someone very inexperienced.