MatPLC modules will be able to run in one of two modes: normal, and hard real-time. Different modules can run in different modes at the same time. Hard real-time mode is available on any Oprating System, but will only give the hard real-time guarantees if a hard real-time Operating System is being used. Currently this means the QNX hard real-time operating system, as this is the only hard real-time Operating System under which the MatPLC may be compiled. However, since the MatPLC is completely POSIX compliant, other POSIX compliant hard real-time operating systems may probably be used.
You can synch between equal-priority modules, and you can make synch arrows from high priority modules to lower priority ones; but never the other way around.
However, there are some modules which may not run in hard real-time mode, because of the nature of their work. For instance, if a module needs to write to a file, it has to be normal. For the generic and specific modules, this is noted in the manual where appropriate. For custom modules, the module-writer needs to be careful: if any system calls are used, the module may not be run in hard real-time mode.
memlock in the
controls this. When it's 1, all modules will be locked into memory. (Due to
the way the MatPLC works, it's not really sensible do this on a per-module
priority controls this. This is a per-module
setting, i.e. under the section devoted to each module. When it's
greater than PRIORITY_MIN, the module is made hard real-time with the given priority. The
allowable range is from PRIORITY_MIN to PRIORITY_MAX. The values PRIORITY_MIN/MAX differ from operating system to operating system. Under QNX, PRIORITY_MIN = 1, and PRIORITY_MAX = 63.
Only modules started by root will be able to go hard real-time.
Similarly, different versions of the kernel have different default schedulers, which have different features. For instance, see this article on LinuxDevices.com about the linux 2.6 improvements.
Much tighter results still can be obtained by pushing the speed-sensitive parts to FPGA or other hardware; John Storrs's LME Craftsman project (FIXME - add URL) takes this approach, giving nice, clean, jitter-free oscilloscope traces.
As far as the MatPLC is concerned, these would simply be "smart I/O". For instance, the MatPLC could command direction, speed and number of steps, and the kernel-task or FPGA would generate the stepper motor train.
$Date: 2006/05/02 13:53:54 $