Customer Solutions

Using High-Level Prototyping Hardware and Software in Machine Control Applications

Author(s):

Erik Goethert, Boston Engineering

Industry:

Machines/Mechanics

Product:

CompactRIO, LabVIEW, LabVIEW Embedded Module for ADI Blackfin, LabVIEW FPGA, LabVIEW Real-Time

The Challenge:

Developing embedded microprocessor systems that not only fulfill the mechanical controls function, but also take into account the entire manufacturing process.

The Solution:

Shifting to higher-level modeling tools that promote the generation of “correct by specification” code in an environment in which engineers with limited coding experience can evaluate the proposed software and make changes incrementally and interactively.

At Boston Engineering, we provide multidisciplinary engineering services to companies that need to design electrical and mechanical systems using microprocessor-based embedded systems to control mechanical movement. This requires moving beyond traditional programming languages, debuggers, linkers, and IDEs, as well as beyond simple board prototypes.

To meet our customers’ needs, we need tools we can use to cost-effectively develop computer-based mechanical, electrical, and embedded software control simulations, graphical user interface (GUI) mock-ups, and functional system prototypes that we can then efficiently render into final solutions.

Building a Tension-Control System
We used a multifaceted approach to build a tension controller for film developing in a digital printing kiosk. In a film printer, the color media spools are fed through the printer head by a drive motor, with the take-up and feed motors controlling the tension. Vibrations from the cutter head, the varying number of photos printed at a time, and variances in the speed of either motor can affect the tension on the substrate. Developing a low-cost product was one of this project’s key objectives.

We monitored the position of two dancers measured with analog Hall-effect sensors to indirectly control the substrate tension. The control system adjusts the position of both motors to keep the feed and take-up tensions within a commanded set point. If this tension is not precisely controlled, the registration error causes a photo to have offset colors.

Simulating the System
The mechanical modeling required several iterations as the customer better defined the subsystem mounting and volume allocation. We also further refined the mechanical model based on control system specifications such as motor size, maximum inertia of moving parts, and sensor selection.

The simulation defined the open- and closed-loop characteristics of the system. We produced iterations of the 3-D model when we determined we had to reduce the dancer longitudinal dimension and some substrate travel distances. Through modeling and feedback, it became evident that a simple PID controller would not provide the closed-loop bandwidth with the required stability margins. To increase stability, we needed small PID gains, but we could not obtain the required closed-loop bandwidth of 20 Hz.

Therefore, we needed a more sophisticated control algorithm. We used a fourth-order phase-lead controller with integration implemented in bi-quad form. We chose this implementation to reduce the errors coming from the fixed, 16-bit word lengths and their inherent arithmetic round-off errors, which can cause instability.

When we create systems that have a user interface, we typically prototype the user interface in National Instruments LabVIEW, a graphical tool that we also use during the later prototyping and deployment stages of our design process. With NI LabVIEW, we can easily and quickly drag interface elements onto a panel so the customer can customize the placement, content, and operation of the interface. This reduces the number of interface adjustment cycles and the amount of churn in the final code. We have found that this practice also works well with embedded systems, which typically have no real user interface. We use the prototype interface to aid in system tuning for maximum stability.

Prototyping the System
The next step in the design phase was to make a physical prototype of the system. Prototyping serves several important functions. Most importantly, the prototype confirms that our designers completely understand the problem. By comparing the operation of the simulation to the operation of the prototype, we can observe any differences and figure out why they’re occurring. Occasionally, there are higher-order effects that we do not discover until the prototype is operational.

We have traditionally used off-the-shelf development boards, usually with some sort of programmable DSP, FPGA, or microprocessor for reconfiguration during the prototyping stage. But these boards normally do not have I/O appropriate for critical timing control, or signal conditioning for that I/O. And even with the use of a reprogrammable element, such as an FPGA, we have encountered a number of issues that cause problems during our iterative design process, including use of proprietary language, lack of technical documentation and support, and minimum controller flexibility, including insufficient I/O or a canned controller algorithm that we cannot easily modify.

For this project, we instead chose the LabVIEW FPGA rapid prototyping hardware platform with a controller, as well as a modular I/O system connected to the controller via an FPGA in the modular I/O backplane. We also used the National Instruments CompactRIO prototyping system, which has a backplane with four or eight slots that accept modules for digital I/O, analog I/O, or communication buses.

The tension-control hardware in our design required two pulse-width modulator outputs to control the two motors; two encoders to provide velocity feedback for the two motors; two analog input channels for the Hall-effect sensor to detect the dancer position; two digital lines for signaling; and channels for thermal and air readings.

We used custom signal conditioning circuitry to connect these modules to the hardware on the NI CompactRIO module, which incorporates two controllers. The first is an embedded microprocessor running at 266 MHz connected to the Ethernet controller and the solid-state disk drive. The second controller, a 1M gate FPGA located in the backplane of the chassis, connects the I/O modules and the embedded microprocessor.

We took advantage of the LabVIEW graphical dataflow language not only to program the module’s embedded microcontroller but also to manage the FPGA in the backplane. Because the code is at a higher level than C, our control, mechanical, and electrical engineers could work directly on the code in the MCU.

We chose to run the supervisory program on the embedded controller and the motor control algorithm on the FPGA to provide the greatest similarity in programming models between the prototype and the end system. To run the control algorithm on the FPGA, we converted the zero-pole-gain model into a filter similar to the one in the LabVIEW Digital Filter Design Toolkit. We easily converted the filter into code that would execute on the FPGA with the toolkit. Because floating-point arithmetic is very resource-intensive on an FPGA, we used the toolkit to automatically generate fixed-point code. We could then test quantization options so that the final filter was stable.

We also took advantage of the fact that we used LabVIEW for both the system interface design and the underlying hardware. Each LabVIEW function contains both a block diagram representation of the code as well as a GUI with controls and indicators for that function. When cross-targeting, the GUI appears as a window on the system under design, which can be used to monitor the system’s internal state or to adjust the program’s parameters. We were able to use the front panel for the code running on the embedded microprocessor to tune the system while it was running, which was a great benefit.

With the open, productive graphical system design platform of LabVIEW, we save a tremendous amount of time from design to prototype to deployment. In our industry, time savings means cost savings, and LabVIEW Embedded technology makes us much more valuable to our customers and competitive in the marketplace. To address a complicated, embedded motion control system, we used standard design tools and integrated those simulations with real-world data in LabVIEW to optimize the designs.

Instead of many tools and environments for model, design, test, and target, LabVIEW Embedded, and now the NI LabVIEW Embedded Module for ADI Blackfin Processors, gives us one integrated tool chain so we spend time on the engineering, not on the syntax.

For more information, contact:

Erik Goethert, Program Manager

Boston Engineering

411 Waverley Oaks Road, Suite 114
Waltham, MA 02452

Tel: (781) 466-8010

Fax: (781) 466-8020

E-mail: egoethert@boston-engineering.com