Sequential control programs can be an easier and more streamlined if the engineer ensures that the sequences have the same architectural model. Three tips are highlighted to make the process easier.
1. Well-defined phases
When phases are defined they are to carry a set of task pertaining to that portion of the application. In many batch applications most of the tasks have well defined operations, for example if mixing must follow agitation then steps pertaining to mixing must complete before agitation can begin. But in semi-batch applications, when implementing batch methodologies in a continuous processes where batch approach would be more suited, it can get tedious to define and breakdown the steps. Defining the phases-including all the steps required-must be taken to the drawing board and eliminate overlaps and inefficiencies. This will eventually result in modular phases and will greatly enhance programming.
2. Using companion modules
Most sequences involve not only action on equipment but also timers, totalizers, and even custom messaging. Most modern platforms support temporary variables for programming the sequences, but some specific calculations are better done in another module at the sequences' command, which can be performed in a companion module. When the user is dealing with many phases, it is easier to assign a companion module to each sequence as part of the initial architecture of the program. This will help aid in modularity, make programming easier, and help in online changes after commissioning without affecting other phases.
3. Efficient exception handling
Next to defining phases, most of the energy in programming is spent in this area. When phases are well defined it is easier to program them, it's usually what happens when something goes wrong at the beginning of the sequence versus at the tail-end can direct a different approach to handle each scenario. Most platforms do provide handlers to accommodate this. The use of these in built handlers like hold, abort, stop, and restart to our advantage is the key here. Developing a state diagram specific to the application in hand and adapting that to the handlers that the platform offers is a great way to break down this task.
Identifying key "points of return" in a phase in the event of an exception must be defined ahead of time. Having an application-specific state diagram will also aid in handling unforeseen exceptions while testing and commissioning.
This post was written by Tony Kolluri. Tony is a senior engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. Maverick delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization, and more.