Although VXIbus instrumentation and embedded computer boards have long provided a good open foundation for data acquisition and control (DA&C), there have been limitations. First, combining several such cards with an embedded computer does not guarantee an adequate or easy solution.
Second, while high-speed applications requiring stable, msec cycle times across all cards could be implemented via an embedded VXI computer with a real time operating system (RTOS), such solutions were expensive and required expertise.
This feature looks at a development that seems to have resolved many of the real time issues – by providing a DA&C system on a single VXIbus card.
To recap, stand-alone DA&C systems comprising proprietary backplane card cages and integrated processing have been around since the 1980s. They’re attractive to users not expert in programming with UNIX, DOS, Windows, etc because all the difficult tasks are handled directly. Programming is also easy and documentation support good.
There are, however, limitations; the manufacturer has to create a huge range of plug-in modules for just about every conceivable application
So many manufacturers have migrated to VXIbus, offering DA&C with an embedded computer and a variety of VXIbus modules – essentially an open architecture version of a stand-alone DA&C system. Software development packages like HP VEE or LabVIEW are ideal here because all the operations are handled by the DA&C system, and operator interfaces and data analysis, by the software.
The only real data throughput limit becomes the interface between the computer and the card cage. Since these systems typically handle most of the data themselves, there’s less data to transfer – which reduces the severity of this problem too.
However, applications that require msec acquisition and control times, could still not be controlled by assembling a group of VXIbus modules with a high level software package. Even when using development tools like Visual Basic, Visual C++, or Borland C/C++, the embedded computer controlling the DA&C cards could be limited by low resolution clock or jitter and delays caused by exception processing in a multi-tasking OS. And, users that decided to write their own application software and manage the OS peculiarities found the learning curve and cost steep.
Users wanted the open architecture of VXIbus, but were looking for solutions already optimised and modularised. So, how to do it?
Consider this. Multiple modules in VXIbus DA&C systems are controlled by an embedded computer. An ADC measures the sensor outputs, and the embedded CPU acquires the readings over the VXI backplane. It converts these to engineering units, updates the operator display, archives data, calculates new outputs, and writes the values to the DACs. This creates a large comms overhead which limits the scan and update rates – especially in large channel count systems. If more channels are needed, it’s worse.
If you need closed-loop control, sample-update rate is critical (typically, two to 10 times faster than process response). A cycle time of 1msec is typical for controlling dynamometers in automotive applications or hydraulic valves in structure testing. An embedded VXIbus computer controlling the DA&C modules may struggle at that rate because it may be handling other issues – like LAN, disk I/O and program tasks. These can tax the embedded CPU to the point where it is unable predictably to respond to real time needs, such as the control loop update rates. Yet, time stability is important in closed loop control.
A real time embedded computer such as HP’s RADI-EPC7 running LynxOS is good for DA&C. Interrupt response to a VXIbus module IRQ is 200 Micro sec; worst case 500 Micro sec. VXIbus timing modules or ADCs can be used to drive trigger lines on the backplane, and the embedded CPUcan be interrupted at these intervals to process scans. Assuming a cycle time of 1msec and 500 Micro sec response to a timer interrupt, this gives it 500 Micro sec to read the input data, calculate and provide output. Clearly, a thorough understanding of the limitations and performance of the embedded computer/RTOS and the VXIbus cards/drivers is required!
Further, if the system had to be expanded it may not be able to maintain this performance. So another VXIbus cage, embedded computer and card set would have to be configured. This certainly does not simplify the understanding of the system!
Users want a DA&C system that is easy to use, easy to configure, and scaleable. So how about creating subsystems on VXIbus cards that handle all the difficult real time tasks on-board without overloading the embedded computer? The HP E1415A Algorithmic Closed Loop Control Card is one such – with all the DA&C on a single card. It also supports signal conditioning plug-ons (SCPs), and lets you build small channel-count systems. Further scaling can be achieved by adding another E1415 card, with each synchronised via the VXIbus backplane trigger lines. Adding more cards does not slow down the DA&C times.
This is more like it! Backbone for the card is a DSP and ADC; specialised functions are on the SCPs. The DSP handles card configuration during initialisation – and then switches to processing analogue/digital inputs, executing user programs, and writing outputs in run time. The ADC acts as normal, providing raw voltage readings to the DSP for conversion, and the design supports from eight to 64 channels of mixed I/O on a single C-size VXIbus card.
Rather than designing a smaller version of an RTOS, and allowing interrupts from SCPs or special programming for exception processing, this design uses a cyclic trigger-based system. The idea is to run the cycle times at a much faster rate than external electro-mechanical changes. This avoids having to handle digital interrupts, since the user programs can test the state of each input often and quickly. To provide signals to the outside world, the user program can cause the VXIbus card to interrupt the embedded computer (or strobe a VXIbus trigger line) based upon a conditional test of inputs.
And thus you get deterministic operation. Also, since HP chose a limited and simplified subset of C for user programs, you can write and debug algorithms on PCs or UNIX workstations with C compilers – and guarantee that real time determinism. With no language looping constructs, the C compiler can perform a worst-case branch analysis and return the execution time so you know exactly how much may be required.
The programming task is made easy because all the difficult structure of handling I/O is automatic. When programs are compiled, I/O channels are detected and automatically grouped and configured. Algorithms simply access input channels as variables and write to output channels as variables. The rest is handled and optimised by the I/O phases.
The design also uses a shared memory hardware FIFO for all data, and a hardware Current Value Table for most recent data. Algorithms have functions for writing to the FIFO/CVT which can hold any 32-bit real numbers. The CVT concept gives quick access of current data to the embedded CPU and eliminates the need to read and sort data from the FIFO.
As for operator input, HP chose the command register approach because each change to a variable or array can be placed into a holding area until all desired changes are downloaded. When the operator interface signals an end to changes to the DSP, it causes all changes to take place before the next user program execution phase. This is critical to avoid changing some parameters used by programs before others have received their changes.
To conclude, stand-alone operation of such intelligent multi-function VXIbus cards means that high level software can be used to ease programming. The user can now take advantage of powerful operator interfaces, data display/analysis, and concentrate on the application solution rather than the sometimes overwhelming challenge of integrating multiple VXIbus cards.
Conrad Proft is with HP’s Measurement Systems Division. He was lead engineer on the E1415A Algorithmic Closed Loop Control Card. He holds a Masters in Computer Science