Code Standardization

Posted by James Farnham on May 16, 2016 3:15:45 PM

ControlsEngineerforweb.jpg

When Optimation started standardizing code in 1998 for PLC Programming for the Allen Bradley PLC5, not too many others were practicing code standardization in the controls world. Now it’s considered a best practice, but is it always followed? What happens when you work with a systems integrator who doesn’t use standardized code?

As many who have programmed with address based PLCs know, database organization is key to a maintainable program. Therefore, we felt that it was essential that we create a standard method for how we assign addresses and organize a program. Otherwise, it can be miserable to maintain your own code, or have someone else maintain the code.

Our standard was created while working on projects for one of our larger clients, where it was used on many projects being fine-tuned with each subsequent project (a perfect candidate for a reuse strategy). We recognized that our other clients would benefit from this standard as well, and began utilizing the standard throughout the company as a means of creating better, more consistent, maintainable code.

When Allen Bradley went to their ControlLogix platform, we needed to adapt our standard, moving to a tag based database structure. The program structure still held true, but we needed to change how we created the database. The tag based methodology fit very well with the previous standard because now we could take advantage of User Defined Datatypes (UDTs). UDTs allowed us to group like attributes (addresses) into one object and then create a tag with the UDT’s properties. Programmers can create structures within structure, giving you a lot of flexibility. This is something that the higher level (C, C++, C#, VB, etc…) world has been doing for years. By using tags the naming convention was much more standardized and logical.

As part of our standardization, we created a standard tag naming convention – this is a hot topic, because not everyone follows standard naming conventions, and some clients have their own standards. When you’re working on a project where standard naming conventions aren’t mandated, this can be costly.

We recently worked on a project with a process that had multiple machines with different functions, where the naming convention wasn’t followed. So you might have a tag that was named one way, but then on an associated piece equipment, it was named differently. Sorting and naming by type of input or output and using a standard naming convention can make everyone’s life much easier and less confusing, not to mention easier to maintain for the future.

The reality is that the lack of standardization added a factor of 2 by not having standard routines and using a standard. It also made it very complex to debug. These standard things are easy to change. It’s one line of code that you can change very easily.

Our next post in the series will discuss Rockwell’s PlantPAx Add-On Instructions, another way that we save development time on projects.

Topics: Controls, Software

Welcome to the Optimation Blog

Tips, tricks and trends

The goal of this blog is to be helpful to readers by providing useful information about applications in industrial engineering, design and skilled trades, as well as industry knowledge. We're passionate about manufacturing in the United States. We have a little fun with it too.  

Subscribe to Email Updates