During the development of the C30 based QMotor 1.0, we ran some benchmarks. The benchmark consisted of a nonlinear control program for a rigid link flexible joint two degree of freedom planer revolute arm. With stubs replacing all input and output functions, the control program was benchmarked on several computing platforms. It was found that a 486DX2/66 could run the control as quickly as the C30 DSP board. A Sun sparc 1 was a little slower. A 90MHz pentium was about 3 times as fast as the C30 board.
With the availability of QNX, and it's real time capabilities (priority based scheduling, hardware interrupt proxies, etc.) it became apparent that the control program as well as the GUI might be able to execute on the same processor concurrently. This would eliminate the cost and complexity of the C30 DSP board altogether (along with it's DOS based compiler).
A server program was written to interface with a Quanser Consulting MultiQ board (8 A/D, 8 D/A, 3 timers, 6 encoder channels, 16 digital in/out lines). One of the timers is used to generate an ISA bus interrupt which the server catches. The user control program is triggered by a proxy which the server activates. Since the control does not execute in the context of a hardware interrupt service routine, it may call any kernel or library functions it wants, and will not lock up if it does not complete in time for the next interrupt (though the proxy messages will queue up).
A network interface for the control program was developed. A GUI, almost identical to the QMotor 1.0 GUI was developed to connect to this network interface from any X/Motif and sockets enabled machine - the GUI is 100% UNIX portable code, using internet domain sockets for communication. It has been compiled on QNX and Irix (Silicon Graphics).
With this design, the GUI can be executed on the same PC as the control, or on a remote UNIX workstation (PC, Sun, Silicon Graphics, etc.) over the Internet or any IP based network. Alternately, it can run on the QNX pc, and simply use X Windows built in network remote display capabilities to display on any operating system/platform which supports an X server (ie. MS Windows 3.1, 3.11, 95, NT, DOS, MacOS, etc.)
The C30 board and interface library were completely eliminated. This is a tremendous advantage, not only cost wise, but it simplifies the task of writing the control program. The hardware on the MultiQ board was virtualized, so that to read an encoder, the user simply uses code such as...
encodervalue=G_ENCODER[channel];
To write to a DAC channel, the user simply does...
G_DAC[channel]=voltage;
The MultiQ server handles reading and writing from/to the MultiQ hardware on each timer interrupt, hiding the process from the user completely.
The user edits and compiles his control program under QNX. He may use any library and kernel functions. If his program takes too long to execute in one control period, he is notified, and may change the control frequency.
The user then executes the control, logs data, and plots log variables in real time, all from within the GUI (running on QNX or UNIX, or remotely displaying from the QNX PC to any X enabled machine, such as a Windows based PC, Macintosh, etc.).
Process priorities are used to ensure that the control program and the MultiQ server execute whenever they need to. The GUI and other normal priority programs only execute if/when the control is not executing, ensuring that rock solid timing is maintained during the control run.
The user control program, multiq server, and network interface communicate using QNX messages and shared memory. The network interface communicates with the GUI using Internet domain sockets.
Below are screen shots of the QMotor 2.0 GUI.
