best programming practice

[rQx]

F) Do not code to save using memory at the expense of complicating the code.

THIS!! Is one important thing I have come to appreciate more and more.
Don't make "to smart" code, it will likely be more complicated to follow.

 

[James Mcquade]

you can also use subroutines to separate different parts of the machines.

Do NOT program multiple outputs !!
do not have multiple latch / unlatch rungs !!
Do NOT program anything in ladder logic if you cannot wire it that way, you confuse maintenance. Logix 5000 allows you to program everything in series. Please don't.

Make sure you can view the entire rung on a single screen!
know the plc rung logic limitations! for example, slc 500 is 18 items in series, 8 nested branches, and 10 parallel branches.

james

 

[ganutenator]

break the task into its simplest components.
aka the hard part also known as keep it simple stupid (KISS)

this way, the motor doesn't depend on the led working if you later remove or change the logic for the led. for lack of a better example.

don't try and build the entire car in one program. build the car parts at the smallest level, so they can be re used for the next model car.

side note: My customer has a ford escape. He has to pull over to the side of the road and turn his car off, and back on again when his radio stops working.

 

[proof]

Would it be better to configure each remote to read the master? This can get a bit hairy when you don't want radios to step on each other (read/write at the same time).

I forgot to list rule 0. Use the stuff between your ears. I listed my guidelines, but I didn't list all the reasons why I try to follow them. It is good to ask why when the answer isn't obvious. To many people are happy to take a rule of thumb and misuse it because they don't understand the limits to the rule. If you think the rule is too restrictive or its basis does not apply for your circumstances, don't use it.

Communications can get complicated. Do you need to know when the communications fails? On either or both ends? I was thinking more of communication between PLCs using Ethernet. Ease of troubleshooting is one of my high goals, but having a reliable system that doesn't need troubleshooting is even better. Unfortunately, most of the time things will eventually break. When that happens, good design makes troubleshooting easier. If making the communications all reads makes things hairy, that seems to violate the rule to make thing easy to maintain the system.

 

[nmambre]

I'm working with a system right now which has a master PLC at the main office, and several remotes connected by serial radio. This master PLC reads all the remotes, then writes pertinent data to the remotes which need it. The master is the only PLC that performs any reading or writing in the entire setup.

Would it be better to configure each remote to read the master? This can get a bit hairy when you don't want radios to step on each other (read/write at the same time).

I wouldn't change your setup, it makes sense the way it is right now. Moreover, there are systems where the Master PLC would be polling functional data, but maybe the polling cycle would take much time. Any slave can send an alarm as an exception/unsolicited (for example DNP3). It all depends on the system and when the data is needed.

 

[ganutenator]

since this mostly AB. resetting the EN bit or EU bit for a false to true instruction that you wanted to happen every scan.

 

[ganutenator]

RsLogix using an addressing structure that referenced the subroutine so that you knew w/o a cross ref if the the address was only used in the routine.