PLC/DCS Best Practices

I started programming A-B MLX1000 PLCs when I was about 18. In 1993-4. I never had any formal training, but my boss at the time gave me a A-B test kit, with a manual, and basically said "Figure it out." I've taken some classes at college over the years familiarizing myself with newer technologies, and a little over 20 years later, and worked on many PLC and DCS systems, programming logic. mostly ladder on PLCs with some FBD, and mostly FBD on DCS systems. Most everything I've learned, I've had to read in manuals, and has helped looking at others logic at times on engineered skids that come to my existing workplace.
I've been curious though if there is any book out there, or good reference for best practices when writing logic. One I've personally been doing is setting up program files for managing I/O. I typically have a program file for discrete inputs, one for discrete outputs, and two more for managing the analogs. The discrete program files look nothing more than a Boolean bit that writes to the I/O, but the analog may incorporate setting limits from an internal tag that writes to output, or vice-versa for inputs. This way all logic written is with internal tags, or bits. Whether this is a good practice, I have no idea.
As far as my DCS programming, I rely on my own companies "best practices"
Thoughts?

DBurnum

dburnum said:

I started programming A-B MLX1000 PLCs when I was about 18. In 1993-4. I never had any formal training, but my boss at the time gave me a A-B test kit, with a manual, and basically said "Figure it out." I've taken some classes at college over the years familiarizing myself with newer technologies, and a little over 20 years later, and worked on many PLC and DCS systems, programming logic. mostly ladder on PLCs with some FBD, and mostly FBD on DCS systems. Most everything I've learned, I've had to read in manuals, and has helped looking at others logic at times on engineered skids that come to my existing workplace.
I've been curious though if there is any book out there, or good reference for best practices when writing logic. One I've personally been doing is setting up program files for managing I/O. I typically have a program file for discrete inputs, one for discrete outputs, and two more for managing the analogs. The discrete program files look nothing more than a Boolean bit that writes to the I/O, but the analog may incorporate setting limits from an internal tag that writes to output, or vice-versa for inputs. This way all logic written is with internal tags, or bits. Whether this is a good practice, I have no idea.
As far as my DCS programming, I rely on my own companies "best practices"
Thoughts?

DBurnum

Click to expand...

PLC/DCS programming best practices often rely on the type of PLC and the customer requirements. Most people prefer easily diagnosed ladder logic with no jumps or loops, so that an untrained programmer can look at what is going on to fix it. I don't disagree with that, but I've also found that if someone has to jump straight to the code to troubleshoot every issue, it means that there isn't nearly enough information on the HMI. I'm also a fan of modular code, which means using lots of FBs or AOIs if the PLC system allows it. If you can prove out that chunk of code, theoretically no one should need to dig inside of it, if it passes good diagnostics to the HMI.

As far as HMI best practices, I've heard many recommendations for "High Performance HMI", instead of the traditional plant flow diagram. Some of the concepts include only using colors to indicate warnings and faults, instead of the traditional green/red for motors on/off. I haven't gotten to involved in this before, althoguh it's on my list to learn more about.