Closed loop analog control

Process networks can implement a control algorithm that regulates water flow through the heat exchangers. A well-designed algorithm can decrease settling time and reduce downtime during changeovers. These algorithms may involve solving integral equations in real-time, and therefore, programming models that follow continuous or discrete-time semantics are most suitable.

Control design tools model and simulate a physical system, transfer algorithms into real-time processing targets for interfacing with I/O, and deploy embedded code into production. Simulation loops can create algorithms in the LaPlace, state space, discrete time, or frequency domains and execute them using integral solvers. With this approach, designers employ one development environment when producing algorithms and performing I/O.

Digital and analog measurements

Measurements from thermocouples, flowmeters, pressure transducers, and load cells typically involve analog signals, which entail I/O operations such as buffering and scaling. While temperature measurements don't need high sampling rates, acquiring data from accelerometers for vibration monitoring does require high-speed analog I/O. For such measurements in the air-cooling application, data flow programming with integrated I/O is most applicable.

Analysis

Programming models that analyze and predict maintenance must execute all functions in real-time while gathering data. For predictive maintenance in the air-cooling example, development environments offering tight I/O integration and libraries with order and spectrum analysis are recommended. Data flow models suit applications involving acquisition, signal processing, and decision-making based on processed data.

Discrete logic

Discrete logic operations assist with sensing and turning valves, pumps, proximity switches, and light curtains. Programming models such as ladder logic can execute logic parameters at greater than millisecond intervals. When loops must run at precise intervals, a timed sequence structure can be implemented.

Operator interface, real-time reporting

Typically, IEC 61131-3-based development environments require a different programming model for human-machine-interface (HMI). However, some imperative and declarative languages, such as Visual Basic and LabVIEW, provide integrated HMI capability.

Development platforms

Besides matching an application's requirements to an appropriate programming model, designers must also consider a software development platform. Important considerations are handling I/O, setting up scheduling and synchronization, and available hardware targets.

I/O and program logic are tightly coupled functions in many development environments relying on text-based and data flow programming models. Declarative programming works best for analog I/O operations because parameters are defined as relationships among components. This improves buffering, simultaneous sampling, anti-aliasing, scaling, and triggering.

In models such as ladder logic, function-block diagrams, structured text, or sequential-function charts, I/O and program logic are decoupled — meaning functions for I/O do not exist in the main program. Instead, variables, or tags, are used to link to I/O, which is configured separately. On a PLC, for instance, a scanner reads physical inputs and stores them in a memory area called the process image. The scanner periodically reads these tag values and writes them to physical outputs.

Each program must share its given processor bandwidth with simultaneous tasks. This is similar to a multitasking operating system that allocates CPU time to each process running on the system. Some examples are user-interface updates, multiple “while” loops, and I/O processing.

In text-based models, programmers schedule tasks by using constructs for multithreads. With some models, constructs inherently support multithreaded programming. For example, the Thread Class and Runnable Interface in Java use monitors to support multiple threads, priorities, and synchronization. Multiple “while” loops in LabVIEW generate many threads to execute commands in each loop.

While ladder logic, function-block diagrams, structured text, and sequential-function charts have no concept of multithreading, PLCs offer built-in support for it. On a PLC, task scheduling is defined outside of a control program so designers can modify control-loop timing at the system level, rather than accessing individual programs.

Hardware is also an important choice, as each programming model executes differently on each target. Designers can choose from PLCs, programmable automation controllers (PAC), microprocessors, digital signal processors (DSP), and field programmable gate array (FPGA) targets.

Models such as ladder logic, function-block diagrams, and sequence structures performing many digital I/O, simple arithmetic, and comparison logic should run on PLCs or PACs. Text-based models, event structures, and data flow models that execute processor intensive calculations run best on industrial PCs and single-board computers. Sequential function charts and state diagrams are best targeted on PLCs and PACs. Process networks work well when programming DSPs. Finally, discrete event-based languages such as VHDL and Verilog are traditionally used when programming FPGAs.

For more information, contact National Instruments at (800) 531-5066, visit www.ni.com, or email the editor at ctelling@penton.com.