next up previous
Next: RTiC-Lab for the Impatient Up: The Real Time Controls Previous: The Real Time Linux

RTiC-Lab Design

The general scheme used in the Real Time Controls Laboratory is shown is Figure 1.6. A devoted display or host computer ($DHC$) is networked via 10 or 100 Mb/s TCP/IP network to a set of devoted controls computers ($DCC_j$).

Figure 1.6: Overview of the Real Time Controls Laboratory network environment
\includegraphics[width=0.6\textwidth]{Figures/scheme.eps}

The controls engineer sits at the $DHC$ (which may or may not necessarily be at the same room or even building as the $DCC_j$) and coordinates, codes, and synchronizes all $DCC_j$ from the $DHC$. Run time parameters, such as sampling rate, startup delay, and networking parameters can be set for each of the $DCC_j$ from the $DHC$.

Each of the $DCC_j$ is a stripped down computer system having no keyboard, mouse, video card, or monitor. These only have both the necessary I/O cards which are used to interface to the plant hardware and the necessary Ethernet card to communicate with the $DHC$.

An AMB example of RTiC-Lab is shown in Figure 1.7. A single $DHC$ interfaces with three $DCC_j$ which in turn interface to the AMB rotor system. The first $DCC_1$ handles all radial control of the AMB, while a second (and slower) $DCC_2$ controls the thrust direction of the AMB, and a third $DCC_3$ is used to add either some excitation or synchronous forces to cancel out rotor imbalances at the midspan. Both controller parameters can be updated through the graphical user interface, and all data is plotted in soft real time at the $DHC$.

Figure 1.7: Example of the applicability of RTiC-Lab on an AMB system.
\includegraphics[width=0.7\textwidth]{Figures/mimoBRG.eps}

Figure 1.8: Example of a simpler application of RTiC-Lab
\includegraphics[width=0.7\textwidth]{Figures/sisoBRG.eps}

In the event that the controlled plant is computationally simple enough (and safe enough!) to be handled exclusively in a single computer, then RTiC-Lab will collapse into one computer as shown in Figure 1.8. Again, the same computer is used to both plot all incoming data and to update controller parameters in soft real time.

In accordance with the RTLinux paradigm, RTiC-Lab separates the AMB controller into the hard real time or ``embedded'' part and the soft real time or ``reactive'' part. The embedded part of the controller (resident exclusively in the $DCC_j$) includes all tasks having hard timing constraints:

  1. the AMB suspension controller(s) (both periodic and event driven),
  2. a software watchdog, and
  3. a set of interrupt service routines that are used for communication with the reactive task.

The reactive task (resident in both $DHC$ and $DCC_j$) is a multi-threaded, user-space application which runs within the Linux kernel. In a stand-alone system, the reactive task would perform the following functions:

  1. communicate with the embedded tasks via RT-FIFOs,
  2. display a graphical user interface for the user,
  3. perform error checking of the user's controller code,
  4. send parameter updates to the embedded tasks as requested by user,
  5. plot data to either screen, save to a file, or print to stdout,

Alternatively, in a multi-node environment, the $DCC_j$' reactive system is charged with communicating with both the local embedded tasks via RT-FIFOs and with the remote $DHC$ through the LAN. It would also be used to trap some vital errors from the local real time tasks, such as missed deadlines. The $DHC$ - which does not necessarily have real time support - would then receive the incoming data through the network and would perform all of the necessary graphical duties as described above. In addition, the $DHC$ would be used to coordinate all networked $DCC_j$.


next up previous
Next: RTiC-Lab for the Impatient Up: The Real Time Controls Previous: The Real Time Linux
Michael Barabanov 2001-06-19