The general scheme used in the Real Time Controls Laboratory is shown
is Figure 1.6. A devoted display or host computer
() is networked via 10 or 100 Mb/s TCP/IP network to a set of
devoted controls computers (
).
The controls engineer sits at the (which may or may not necessarily
be at the same room or even building as the
) and coordinates,
codes, and synchronizes all
from the
. Run time parameters, such
as sampling rate, startup delay, and networking parameters can be set
for each of the
from the
.
Each of the 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
.
An AMB example of RTiC-Lab is shown in Figure 1.7. A
single interfaces with three
which in turn interface to
the AMB rotor system. The first
handles all radial control of
the AMB, while a second (and slower)
controls the thrust
direction of the AMB, and a third
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
.
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 ) includes all tasks having hard timing
constraints:
The reactive task (resident in both and
) 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:
Alternatively, in a multi-node environment, the ' reactive
system is charged with communicating with both the local embedded tasks
via RT-FIFOs and with the remote
through the LAN. It would also be
used to trap some vital errors from the local real time tasks, such as
missed deadlines. The
- 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
would be used to coordinate all networked
.