As with any type of programming, there is no one way to develop logic for an application or a process. This of course leads to the ability to make decisions that are based on the specific tasks or operations that need to occur. However, the flexibility of PLC programming environments provide ample opportunity to create a colossal mess.
At Turner Integrated Systems we adhere to specific guidelines for PLC programming practices. Not only has this proven to serve our customers well, but it has also been an asset to ensuring our team is consistent with each other allowing for simple diagnostics and clear understanding of modifications when changes need to be made.
In addition to simplifying future changes and troubleshooting, some of these best practices have drastically improved HMI and SCADA development times.
Top 5 Guidelines
Here are just a few of the main guidelines we follow:
On most modern PLC platforms, PLC tags are name-based and not just register-based addresses. This evolution has certainly made great improvements in interpreting logic and development efficiency, but it can get messy quickly without a proper naming convention for the tags. Aside from that, it can even lead to misdiagnosing logic issues if a tag is considered to be missing, but in reality it wasn’t named as expected.
On a basic level, tag names should begin with the device or process that the tag is associated with, followed by the function of the tag. This makes it simple when determining the full list of tags in play with a search for a device.
Also, many tag naming systems have a limit to the number of characters allowed. Even if a character limit didn’t exist, long tag names gets difficult to manage. This being the case, it’s a good idea to have well documented short-codes for functions. We use codes that have been around in the process control world for decades.
Device identification should also be as simple as possible. We use the device ID as found on the process and instrumentation diagram. For example, a run status input for Pump 1 should be titled P1.YI, P1/YI or P1_YI depending on the tag organization structure of the PLC in use. Along with each tag a description should be included in the tag properties that clearly explains the function of the tag.
UDTs or “User Defined Tags” is another tool that should be considered when developing PLC software. UDTs help group the key tags of a device or a logic function to allow for the building of tag templates.
This concept aids significantly in the assurance that tag names are consistent. When using UDTs an instance of the UDT can be created which automatically creates all of the related tags required for the device or process.
Logic Routine Structure
It is up to the programmer to decide the layout and scan order of logic routines. Our own guidelines require logic to have a basic organization that separates process related logic from device control logic.
Alarm logic is to be grouped depending on the type of alarm. Device related alarms should be in the logic area of the device. Process related alarms should be in the logic area of the process control logic. Miscellaneous alarms are to be in a separate routine.
As with any programming language, documentation in the form of commenting throughout the code is an expectation. Having the ability to read the intentions of a logic section helps to understand the importance of what the program is doing.
This not only helps with diagnostics, but it provides a clear path for understanding the best way to approach future modifications.
Change Management / Logging
Comments outside of the logic file in a dedicated change log is an important tool in understanding the evolution of a control system. When changes are requested, it’s not always understood what the complete effect of the change will be.
Some changes can involve ripping away logic that took hours to build. This is why it’s important to archive versions of a project file that can be tracked with a list of modifications that have been made. Some manufacturers provide software utilities to examine differences between logic files. These can be very useful but do not replace the need for a change tracking document.
These are just a few of the guidelines we have built into our workflow to guarantee our systems will perform as designed and allow our team to easily support our systems in the field for years down the road. This is not an exhaustive list, and we expect that as technology keeps moving forward with new logic control software and hardware solutions, our procedures will evolve along with them as necessary.