PLC Programming Best Practices [closed]

StackOverflow https://stackoverflow.com//questions/21031065

  •  21-12-2019
  •  | 
  •  

Question

I have recently inherited a PLC project. We are using Automation Direct PLCs and using the C-more software for writing ladder logic.

C-more allows me to add rungs for "Execute on every scan", "Execute when called", etc.

It also allows me to break out separate sections under each of these headings to attempt some organization.

Are there some agreed upon best practices for structuring ladder logic programs? I'm trying to bring some sanity to the development process.

Was it helpful?

Solution

There are no established norms in the PLC programming realm, I've been developing, commissioning, maintaining (and reverse-engineering) PLC programs for 26 years. Many organizations develop in-house standards, but there are no accepted industry-wide standards. However, a method I gleaned from an old pro dictates placing decision-making rungs first (evaluating conditions and setting flags), making control decisions in the next segment, turning outputs on/off in the next section, and monitoring performance/upset conditions in the last.

It's based on how older machines evaluated I/O and handled ladder execution. The advent of ladder 'sub-routines' has helped enormously; I generally treat each motor as a 'sub-system' element and assign its' own sub-routine.

Hope this helps!

OTHER TIPS

Document as you go. Logic, elements, memory map, etc. Document for "the other person", even if that person is YOU. PLCs and their programs tend to have a LONG life, so you will be glad 1 year, 5 years or even 20 years down the road when you have to tweak/debug that PLC. You'll be glad you explained things in a little more detail by documenting it for "the other person".

Do NOT wait until "the end" to document. Yes, that implies that you need to keep the documentation up-to-date.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top