If your systems work differently from plant to plant or machine to machine, you have experienced the downside of a lack of standardization. PLC programming standards are a great tool to ensure that functionality and operator experience are identical within your organization. This reduces training time and prevents costly mistakes. This is a custom world, though, and systems tend to be “the same except.” How do you maintain the benefits of standardized code while remaining flexible enough to handle inevitable equipment differences?
Throughout this discussion I’ll refer to standardized blocks of code as a FB or function block. This is Siemens terminology, but think AOI if you use Rockwell or DFB if you use Schneider PLCs.
Figure 1 shows the basic philosophy we recommend when making decisions about how much functionality and flexibility to build into one FB. As the graph moves from left to right, internal complexity of the FB increases. The Y axis represents the subjective usefulness of the FB created.
Figure 1
The far left of the graph represents completely unstructured code using only the native instruction set with no FBs. This approach does have a degree of usefulness of course, and systems can absolutely be programmed this way. On the far right, you have the “one FB to rule them all” approach. This mythical creature is the configurable FB that can handle any exception you throw at it. We argue that it has no usefulness because it doesn’t exist.
Utilities and Advanced Instructions
As we start to put some logic into FBs, we begin to gain some usefulness. The area between unstructured code and the first dashed line contains what could be categorized as utilities and complex instructions. These FBs are functionally oriented to solve specific and repetitive coding problems that are not addressed by the standard instruction set. Examples would include an analog alarm FB, a setpoint ramping FB, or an FB to handle a repetitive calculation like flow totalization.
The Sweet Spot
The sweet spot in the middle is where the most value is attained. In this area the programmer thinks in terms of the functions required by the physical system (pump, conveyor, indexing table) as the organizational unit rather than in terms of creating a more advanced instruction set. Here FBs would be created for repetitive physical components and high-level control functions. The key is to successfully discern where to draw the line between components, and that line is not always obvious.
A brand-new FB in the sweet spot always starts out on the left dotted line. It successfully encapsulates the code required to control the specific component for which it was designed. As exceptions are encountered, the FB gets more complex as configurable code is added to accommodate the exceptions. Initially, this makes the FB more useful as it can be applied to more applications.
Frankencode
There is a point, however, where the FB gets so complex that it begins to lose its usefulness, and at some point, it becomes Frankencode. Depending on the application, FBs like this can have significant amounts of non-functional code when running. This makes the code hard to troubleshoot and unnecessarily consumes memory. Overly configurable FBs are also difficult for programmers new to the standard since it is unclear exactly what the FB does.
So where exactly do you cross the right hand dotted line? Our best practice is that FB’s cross the line when they move beyond accounting for nuances in an identical system component. If the FB modification requires functionality never envisioned in revision 1, then it’s time to start fresh. A “nuance” might be accommodating both normally open and normally closed inputs or pulsed vs maintained outputs.
Example
A single FB is created to handle control for a pump including start/stop, associated alarming, run time and cycle counters, and manual control. This FB is deployed several times to control the pumps in a single plant. A second plant is constructed, and this time the MCC latches the run command from the PLC. So the FB is modified to provide pulsed start and stop outputs instead of just a single run command.
The plans for the second plant call for two of the pumps to be controlled by Variable Frequency Drives (VFD). This would require the addition of all the code to send a speed command, monitor speed feedback, and monitor for VFD faults. Because all this code would be useless in a non-VFD application, the programmer should create an entirely separate FB that controls VFD driven pumps.
Conclusion
Managing the tradeoff between standards and flexibility can be an art form, but it is important to apply a consistent philosophy to the decision-making process. Over time, a consistent approach will produce a manageable and highly functional standard code library.
COMMENTS