Previously, I’ve written about our history with code standardization and Rockwell’s support of standardization with Add-On Instructions and Plant PAx. But how do you go about developing and following a standard in the first place?
Standards are created over a period of time by experienced engineers; this could be over years with inputs from many people. For traceability and version control, one person should the gatekeeper of the standard. They manage and gather the inputs and suggestions of the other engineers and use a process to determine if the standard should be updated. Once the standard is modified, fellow developers should be trained on the changes and told where the updated standard and object are placed. You can have all of these great standards, but if no one knows where they are, or people choose not use them, they are wasted.
There are so many different ways of doing the same thing, how do you determine what is the best way? That’s the issue that haunts many– what’s the best way or what’s the method that we’re going to use? For example, some people have embraced Plant PAx, and some people are feel that its bloat ware. It’s best to pick a method or two options and hold employees to the standard. This requires time investments from management in ensuring the standards are followed.
But your standard is not the only standard out there, and you should be prepared to work within other standard constraints. When we approach a controls project the first question that should be asked is, “Do you have a programming standard?” If the customer says, “Yes” than that’s what should be followed. If the customer says, “No,” then we offer to share ours with them and use it.
The key is actually using these valuable tools that we have created. These standards really do make the job easier and using them offers much less risk to the customer. It also allows us to use multiple resources on the job, or for repeat business if something needs to be changed in the future, it allows any of our engineers to go in and immediately be able to understand the code and where to find things.
Programmers can be moved on and off PLC projects without having to relearn different programming styles. One of our favorite saying is: “Clone and clobber” – that’s what a standard is all about. You clone what’s worked, and go back and modify what you need to. Don’t reinvent the wheel if you don’t have to!
