When a manufacturing or industrial company wants to develop an electrical/ mechanical system that uses microprocessor-based embedded systems to control mechanical movement, it often looks for outside expertise from an engineering firm with both software and hardware experience.
Designing embedded systems is more than just a matter of defining a specification, developing the hardware and software, testing and debugging and, finally, delivering it. It means taking a look at the bigger picture.
Boston Engineering’s multidisciplinary systems approach delivers embedded microprocessor systems that not only fulfill the mechanical controls function but also take into account the entire manufacturing process. A key step in this process is often careful modeling and prototyping that accurately consider all contingency variables.
In this environment, embedded control system development becomes an iterative process and involves ongoing, cross-domain consultation among mechanical engineers, hardware designers, software developers and those knowledgeable about the details of the application within which the design will be used.
This requires moving beyond traditional C, C++ or other languages; debuggers; linkers; and IDE as well as beyond simple prototype boards.
For us, the shift to higher-level modeling tools at every step of the process promotes the generation of “correct by specification” code but in an environment that allows engineers with even minimal coding experience to evaluate the proposed software and to make changes incrementally and interactively.
A key to this process is the availability of tools that we can use to cost-effectively develop computer-based mechanical, electrical and embedded software control simulation; GUI mock-ups; and functional system prototypes. Then we must efficiently render these prototypes into the final solution.
To achieve these goals, we do not depend on just one high-graphical and modeling design tool but several, each of which are optimized for the following specific operations in the development process: (1) simulating the electromechanical environment; (2) modeling the control environment; (3) prototyping the critical human interface on the system under design; and (4) generating the C code for software and the VHDL code for hardware, if necessary.
Building a tension control system
Most recently, we used this multifaceted tool approach for a new customer requiring a tension controller for film developing in a digital printing kiosk. In a film printer (Figure 1 below ), the color media spools are fed through the printer head by a drive motor, with the take-up and feed motors controlling the tension.
Figure 1. Simple graphical display of print spool tension control system
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. In addition, low product cost was a key specification. To this end, we determined that a dual dancer system controlled by inexpensive DC motors would provide the most cost-effective solution.
To indirectly control the substrate tension, we monitored the position of two dancers measured with analog Hall-effect sensors. 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 similar to the Sunday comics effect.
Simulating the system
Because we knew that ourcustomer’s engineering staff memberswouldprobably change their minds several timesduring the design of a systemlike this, we created a mock-up of the systemusing a PC CAD package(in this case, SolidWorks). By doing this, wecould perform our initialwork on the mechanical details virtually andquickly show the customerhow the system would look and behave. Withthis virtual mechanicalprototype, the customer could use the model tocomment or requestchanges in the design.
The mechanical modeling required severaliterations as the customerbetter defined the subsystem mounting andvolume allocation. We alsofurther refined the mechanical model by thecontrol systemspecifications such as motor size, maximuminertia of moving parts andsensor selection, among others.
To model the control system, we used TheMathWorks,MATLAB andSimulink software (Figure 2 below )to determine if the desired closed-loopcontrol could be achieved tothe desired bandwidth and margin. We alsocould have used NationalInstruments LabVIEW modeling and simulationtools for this task, whichinvolved modeling the substrate properties,the motors, the dancersystem dynamics, the feedback and drivesubsystems and the controlalgorithm.
The simulation defined the open- andclosed-loop characteristics ofthe system. We produced more iterations ofthe 3-D model when wedetermined we had to reduce the dancerlongitudinal dimension and somesubstrate travel distances. With theseiterations taking place purelyin the software domain, and feedback comingfrom multidisciplinary teammembers on our side and the client’s end,component rework was greatlyreduced.
The dual dancer system provided interestingcontrol challenges. Thedancers were pivoted in a fashion similar toan inverted pendulum.Unlike an inverted pendulum, however, thecoupling between the motorand dancer was a fairly flexible substratethat traversed through thetop dancer roller. In addition, as thesubstrate traveled from the feedto the take-up rollers, the inertia seen bythe motors changed.
Through modeling and feedback, it becameevident that a simple PIDcontroller would not provide the closed-loopbandwidth with therequired stability margins. To increasestability, we needed small PIDgains, and we could not obtain the requiredclosed-loop bandwidth of 20Hz.
Therefore, we needed a more sophisticatedcontrol algorithm. We useda fourth-order phase-lead controller withintegration implemented inbi-quad form (Figure 3, below ). We chose this implementation to reduce theerrors coming from the fixed, 16-bit word lengths and their inherent arithmetic round- off errors, which can cause instability.
Figure 3. Zero-Pole-Gain Motion Controller
The lead controller shown in Figure 3above provided the capabilityto produce more substantial changes in thesystem frequency response,thus enabling the closed-loop system toreach the specifications of 20Hz bandwidth with a phase margin of 20 to 25degrees.
Once the simulation showed that the systemcould meet the designspecifications, we created the designdocumentation to drive theremaining design stages.
Both internal developers and the customerneeded to see this type ofdetailed documentation. At BostonEngineering, we feel the mosteffective documentation includes detailedgraphs, block diagrams andcharts. We believe text descriptions areineffective in conveying thesystem’s operation and end up boring thecustomer.
When Boston Engineering creates systems thathave a user interface,we typically prototype the user interface inNI LabVIEW, a graphicaltool that we also use during the laterprototyping stages of our designprocess. With LabVIEW, we can easily andquickly drag interfaceelements onto a panel so the customer canadjust the placement, contentand operation of the interface.
This reducesthe number of interfaceadjustment cycles and the amount of churn inthe final code. We havefound this practice also works well withembedded systems, whichtypically have no real user interface. Weuse the prototype interfaceto aid in system tuning for maximumstability.
Prototyping the system
The next step in the design phase was tomake a physical prototype ofthe system. These prototypes perform a fewimportant roles. First, theprototype confirms that our designerscompletely understand theproblem. By comparing the operation of thesimulation to the operationof the prototype, we can observe anydifferences and ensure that weunderstand the reason for those differences.Occasionally, there arehigher-order effects that we do not discoveruntil the prototype isoperational. In rare cases, there is anerror in the model.
The second purpose of the prototype is todiscover opportunities forcost reduction. Once customers have aprototype, it is easier for themto try out lower-cost sensors or motors. Fornearly all of ourcustomers, cost reduction is a keyconsideration. The third purpose ofthe prototype is to determine the componentsnecessary for the finaldesign. Customers iterate on theirmechanical or electrical componentssuch as the castings and the motors.
Boston Engineering traditionally has usedoff-the-shelf developmentboards, usually with some sort ofprogrammable DSP, FPGA ormicroprocessor, for reconfiguration duringthe prototyping stages. Butthese boards normally do not have I/Oappropriate for critical timingcontrol or signal conditioning for that I/O.
And even with the use of areprogrammable element, such as an FPGA, wehave encountered a numberof issues that cause problems during ouriterative design process,including the use of proprietary languages,lack of technicaldocumentation and support and minimumcontroller flexibility, includinginsufficient I/O or a canned controlleralgorithm that we cannot easilymodify.
For this project, we instead chose anFPGA-based rapid prototypinghardware platform with a controller as wellas a modular I/O systemthat is connected to the controller via anFPGA in the modular I/Obackplane. We used the National InstrumentsCompactRIO prototypingsystem which has a backplane with four oreight slots that acceptmodules for digital I/O, analog I/O orcommunication buses.
The tension-control hardware in our design (Figure4 below ) requiredtwo pulse-width modulator (PWM) outputs tocontrol the two motors; twoencoders to provide velocity feedback forthe two motors; two analoginput channels for the Hall-effect sensor todetect the dancerposition; two digital lines for signaling;and channels for thermal andair readings.
Figure 4. System Block diagram
Rather than build custom implementations, we used four off-the-shelf modules that had sufficient I/O for our needs: an ?eight-channel, 24 V, 100 µs, sinking digital input module; an eight-channel, 24 V, 1 µs, sourcing digital output module; a? six-channel, 1 MHz, ±5 to 24 V, differential/single- ended digital input module; and a four-channel, 100 kS/s, 16-bit, ±10 V, simultaneous-sampling analog input module.
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, in particular, of the LabVIEW 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.
And because we programmed the FPGA in the same dataflow language, we could program the entire system in the same language and did not need domain experts to learn VHDL. With the dataflow representation, we could scale between the two targets and achieve true hardware parallelism when we ran it on an FPGA fabric or used it with a traditional threading model on a microprocessor.
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 National Instruments LabVIEW Digital Filter Design Toolkit, as shown in Figure 5, below.
Figure 5. LabView Digital Filter Design
With the toolkit, we converted the filter into code that would execute on the FPGA. Because floating-point arithmetic is very resource-intensive on an FPGA, we used the toolkit to generate fixed-point code. Then we could test quantization options so that the final filter was stable.
We also used the FPGA to implement the PWM function needed to drive the motors (Figure 6, below ). By having a programmable FPGA connected to the I/O, we were able to overcome the lack of a standard PWM module and create a very flexible PWM module with high precision edge placement.
Figure 6: Source code visualization for motor control code in FPGA
In addition, we took advantage of the fact that we used LabVIEW in both the design of the system interface and for 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 and can be used for monitoring the system’s internal state or for adjusting parameters of the program. A bonus for us is that we were able to use the front panel for the code running on the embedded microprocessor to tune the system while it was running, as shown in Figure 7, below .
Figure 7. Embedded Controller Tuning Panel
The code used to implement the prototype system is not currently used on the final deployed system. We are planning to deploy the code on a final system in early 2006 to test this hypothesis.
Our use of rapid prototype modeling tools helped us provide more accurate, timely predictions of the system’s reaction and gave us greater team-wide input in developing a system that would meet higher-level customer goals – not just function at a process-specific level.
Goethert, Erik, “LabVIEW in theDesign Cycle from Modelto Chip,” NIWeek 2005, Austin, TX, August2005.
 Gomez,Alexander, and Treiber,Robert II, “A ModernDesign Approach to Motion Control,” July2002.
Baroth, E., and Hartsough, C.(1995). Visual programming inthe real world. In. M. Burnett, A.Goldberg and T. Lewis(Eds.), Visual Object-OrientedProgramming: Concepts andEnvironments, pp. 21-42. ManningPublications Co., Greenwich, CT.
 DesignAutomation Conference ’06,July 24-28, 2006, San Francisco