Future Upgrade Considerations

A Re-evaluation of Current Hardware

The transputer system described here has been in use since Aug. 1992. At that time, it was considered "state of the art"; after a long search, it was selected over other possibilities, such as PC's with DSP boards, or specialized embedded microcontrollers. In general, it is still quite a sophisticated system which hasn't been explored to its full potential; unfortunately, there are two problems, one minor and one quite serious:

• minor problem: the A/D converter board cannot latch and convert all channels simultaneously. This presents a bottleneck: a fairly simple nonlinear control law requiring four channels of input cannot run much faster than 5kHz.
• serious problem: occasionally, when the PC host boots, it fails to recognize the transputer board. This is manifested as "hangage" at boot-time, when the Network Configuration Software (NCS) is run. NCS, for some reason, fails to find the transputer link, and suspends indefinitely. Many causes for this have been proposed (from a short circuit in the PC case, to a timing problem between the transputer and PC bus, to old software drivers...), but nobody has been able to correct the problem. Even more frustrating is that it is a Heisenbug, and cannot be reproduced at will.

Possible Solutions

The first problem can be solved by buying and A/D which has the ability to latch and convert all inputs simultaneously, instead of having to multiplex the input channels:

Improving analog I/O bandwidth

The second problem will be harder to fix, because there is no known cause. Perhaps the solution is extremely simple and someone will stumble upon it in the near future. If not, the only recourse (apart from obtaining another TMB16 motherboard from Transtech and testing that out) will be to buy new controller hardware:

New Hardware for Real-Time Control

Since 1992, there has been an increase in the number of possible hardware platforms for inexpensive real-time controllers:

• PC with DSP board: this is still an option. However, one of the reasons this wasn't pursued originally is that PC's are not really suited for implementing control systems, if the internal PC timer will be used for controlling the sampling period. Due to memory refreshes, hard-disk accesses, screen and keyboard services (which all cause interrupts), interrupt latency will arise, which can cause the clock (which is also on an interrupt) to jitter by as much as 400 microseconds (so if the controller is running at 5kHz, this jitter is twice the sampling period!). A solution to this problem would be to disable interrupts; unfortunately, this would also disable the timer, and make timing (as well well as some I/O!) impossible.
• Inmos T9000: this is the next-generation Transputer, which has a few very attractive features; it should be compared with:
• TMS320C40: a parallel DSP from Texas Instruments. Just like a transputer, this processor can be linked to others to form a MIMD parallel processor. A comparison of the two systems follows:

Inmos T9000 or TexasInstruments TMS320C40

• PowerMac running LabView: LabView is a software package from National Instruments, which lets the user build complex control systems by drawing block diagrams (similar to MATLAB's Simulink). Analog I/O cards are available to plug into the the Mac expansion slots (a Mac with at least 3 expansion slots should be considered!), LabView also includes interfaces for GPIB boards; with a bit of programming, such a controller could be easily integrated into the current server488 setup. It seems that Macintosh computers would not have the same problem as PC's do with interrupts; the Mac OS is not a pre-emptive multitasking environment, which means that all of the CPU can be dedicated to the control task. LabView is reported to be a "slow" piece of software (this is why it was not considered in 1992, even though we had a demo copy); however, with the new PowerMac systems, this should not be a significant deterrent (price, on the other hand, may be).

Recommendations

If the PC booting problem is solved, the next step should be to buy a faster A/D TRAM for the existing system. Otherwise, a PowerMac with LabView seems to be a very attractive idea; the software would allow someone no C-programming background to design control systems for their experiments. This might be an expensive proposition, though, since a large PowerMac with more than one expansion is needed. However, one could forgo a fancy screen and large hard disk in favour of RAM and a fast CPU (programs could be stored on one of the other lab Macs over AppleShare). According to preliminary conversations with satisfied LabView users, the most expensive part of the system (apart from the Mac) is LabView itself; the analog I/O is fairly cheap in comparison (consult the latest NI catalog).

References

• NI catalog
• Sunnyside Systems (A/D, D/A) manuals
• T9000 info on www

Back

Index