Let’s take a minute to dissect some problems that occur with most batch engines.

The core software that resides in a standard weight indicator is composed of several basic processes. These processes read the A-D (Analog to Digital Converter), provide updates to the display, monitor and read the keypad input or other user interfaces, write and read memory, transmit/receive serial data, monitor digital inputs and update digital outputs. In an indicator with digital I/O, it is typical for core software to also include a batch engine.

A batch engine is designed to control processes; however, in the past some have been rather clunky and under-powered. Instead of having intricate features, they have often been too general to meet demands, or too specific to embrace all the requirements of the applications they are intended to be used on. This stems from limited expectations that were present in past decades when control was simply a reed switch on a dial or the control sequence was mostly reliant on external logic. In today’s environment, just passing this responsibility on to someone else’s equipment is no longer cost effective or competitive.

Controllers based only on weight reaching a setpoint have evolved from what used to be very crude methods to code and languages that require an extensive programming knowledge. In addition, the controllers required a programmer who had a deep understanding of weightbased technologies. Across the spectrum of weight-based control are a number of methodologies that are utilized to meet the needs of weighing applications. These methods have often fallen short of performing exactly what is required, especially if there is any upstream or downstream control. It seems that setpoints are either too basic or have evolved to become specialized objects that are strung together in an attempt to be one-size-fits-all. In the 1980s, a diagram in a manual typically showed graphically the basic concept of control and offered some “canned” sequences for single or multiple products with target, preact, dribble and zero band.In the last 20 years, little has changed with regards to the basic weight setpoint, despite an ever increasing set of expectations in control applications. Because of this, much of the marketplace is inundated by the implementation of programmable logic controllers, even when the application is completely weight based.

Another problem with using most weight indicators as controllers is there are far too many variables in customer applications to meet the majority of the controlling processes needs. Some examples may be applications that involve such things as impact loads, free fall, and head pressure. Although most batching indicators can deal with those variables, when you actually compound them with operator prompts or inputs, formulas or recipe storage and simultaneous control — then add data capture and reports — it starts to become a daunting application. And to think we still haven’t dealt with scenarios like what to do when the system is paused, idled or aborted.

In general, a setpoint can be thought of as having a condition that is evaluated, with actions that occur based on the condition being satisfied. Most setpoints in an indicator actually have true or false conditions or actions that have been predefined. These predefined setpoint events typically are assumptions that have limited flexibility. It is common to find that these setpoints are limited, especially where multiple conditions may need to be addressed simultaneously, and the predefined actions are far beyond simple control.

Now, let’s consider a simple, yet unique solution. Rice Lake Weighing Systems has introduced a new type of batch engine. We prefer to call it a control engine. This new ProAction PCEE control engine has easy-to-configure steps and selectable conditions and actions. This allows the user to perform multiple processes or steps sequentially, concurrently, or both. The steps have a condition list, which is scanned and evaluated as simply satisfied or not satisfied. When each step is enabled to be evaluated, all conditions are required to be true in order for the action list to be performed. If these sets of true conditions are not met, then the false action list is performed. In addition, there is a paused action list. If a step needs to perform specific actions during a pause function, all steps can be enabled to be evaluated or disabled throughout the routine.

The condition and action lists allow for very high level setpoints to be created, with the details catered to the specific needs of most customers. In addition, Pro- Action PCEE interfaces to the unit specific database through a record pointer and a selection of ondition/action functions.These steps for writing or reading data function without using an independent programming language and allow the user to perform complex database access from within a special routine.

The new control engine is configured using a new, simple-to-use program editor to define steps, step details and detail parameters with a simple selection. There is also a database editor, ProAction DBE, that can be used to define the schema, name the database tables, and define the number of fields and the number of records necessary to the application at hand.As the science of control and the design of batch engines continue to evolve, we will see increased flexibility, functionality and speed. Machine-to-machine communication will be seamless. User-friendly interfaces will make human-to-machine communication a common, universal language. The future is here.