Implementation of a Data Pump with Ignition by Inductive Automation
There are many tools on the market for historizing process data. These tools typically treat each point of data individually when historizing, which works great for trend screens and instrumentation reporting. However, it is often desirable to log a “set” or “group” of data together, associating many data points with a single event. This use case is particularly common with batching operations, where detailed records must be kept. This can be accomplished in many different ways. One such approach, that of a so-called “data pump,” is described below.
One of our solutions to this challenge is to create and log a “payload” of data each time an operation is completed on a piece of equipment. For example, consider a bulk material addition into a mix tank. This operation contains several pieces of relevant information that can be historized, such as:
- Start Time
- End Time
- Unit (Ex: Mix Tank 102)
- Batch ID
- Event Description: (Ex: “Sucrose Addition”)
- End Condition (Completed Naturally or Manually Aborted)
- Setpoint Amount (Requested Quantity)
- Actual Amount (Delivered Quantity)
- Error % ( [Actual – Setpoint] / [Setpoint] x 100 )
- Pump Speed
In order to capture this information, PLC logic is built into each operation to collect the pertinent data. At the completion of the operation, this data is then consolidated into a single record object, typically a User Defined Data Type, in the PLC. Then this record is placed into a queue object on a “First In, First Out” basis. Elsewhere in the control system (external to the PLC), this queue is monitored for new records. As new records appear, the control system reads the appropriate data from the front of the queue, logs it to a SQL database table, and handshakes with the PLC to indicate that the record has been successfully processed.
Once the handshake is received at the PLC level, the queue is then indexed to discard the previous record and move the next record forward for processing. No records are removed from the queue until the control system acknowledges successful processing of that record. In this architecture, queued data is essentially guaranteed to be logged. Even if the mechanism processing the queue fails, the PLC (and more importantly, the automated process) can continue to run as normal. In this scenario, the queue may accumulate a backlog of unprocessed records, but once the processing mechanism is brought back online they can be quickly processed. Providing a large enough queue object is important because it gives the data pump a buffer. This allows the control system to weather any interruption of communications that might occur between the PLC and the mechanism that processes the records. (more…)
Case Study: Methodical Approach to a Systems Upgrade
ECS Solutions, Inc. (ECS) recently helped a client with an upgrade by leveraging ECS’ methodical approach to system solutions. Their client has three very similar processing areas known as casting pits. Each was controlled by an independent GE 9030 PLC system, each with a main, and each controlled by a local BLUE Open Studio HMI from ProFace America.
The 9030 PLCs that were installed were robust and accurate for these areas when originally installed. Over a long period of time, the systems were maintained and augmented by several personnel from both inside and outside the organization. The result, as is often the case in legacy automation systems, is system drawings that are littered with hand comments and sketches on paper drawings. These systems also feature code that works…. until it doesn’t due to getting lost in a discarded section of logic that was thought to be disabled but was never removed. These situations are often referred to as “ghosts” or “gremlins” in the code and they can be difficult to troubleshoot. Frequently, the solution is to reboot entire systems to exit from the offending area.
Case Study: Repurposing a Tank Farm
A large US food manufacturing company planned to repurpose a tank farm, originally used in the manufacture of ice cream. The repurposing of the tank farm could be considered a greenfield installation, providing various oils to a new fryer system. The new designs would allow the storage and transfer of (1) newly delivered oil, (2) flavored oil to be reused and (3) waste oil to be discarded.
ECS Solutions was hired to help evaluate the existing system which was controlled by five Allen-Bradley SLC 5/03 PLCs. The ECS engineers determined the IO was sufficient for the planned changes as well as many of the existing valves. ECS redesigned the controls incorporating one new Allen Bradley CompactLogix controller to control the system and an Ethernet network to connect each of the existing SLC racks, which would be repurposed as remote IO racks. In addition, we provided new PowerFlex variable frequency drives to control the pumps that would move the oil from place to place. An existing Inductive Automation Ignition operator interface application was expanded to incorporate the oil storage system. In effect, the scope of the project was to evaluate the control systems available and to incorporate new controls where required.