Re: [PLUG] Serial & parallel ports; lack thereof

["Eric H. Johnson" <ejohnson@camalytics.com>]

Rich,

>> Honestly, if you're interested in real-time, then an OS designed for
this should be used.  I think linux can be used in this capacity, but in
some cases there are better tools for the job. <<

There is an OS designed for this, Linux with the rtai or rtlinux extensions.
The software we were discussing requires these extensions.

>> In theory a PC can be a good realtime platform. A realtime OS would
probably start by ditching the BIOS completely (just wipe out the IDT
and write your own low-level routines).  Realtime operations really
requires a bare-hardware level of engineering. <<

It actually works quite well with the rtai extensions on many processors.
Here are latency test figures for many common motherboards:
http://wiki.linuxcnc.org/emcinfo.pl?Latency-Test

>> I'd tend to think that for an application like this the easier solution
would be to have a desktop that runs a more normal linux install, but
optimized for near-realtime performance.  That would be coupled with a
hardware controller that would be interfaced by something modern like
USB or ethernet.  The software would send high-level commands to the
controller, and the controller would execute those commands in realtime.
 The controller would be a completely embedded realtime system. <<

That was basically what we suggested last night. The controller can be run
headless, which allows the user interface to be run remotely over the
network. Additionally the user interface is not limited to the Linux
platform so long as the necessary libraries are loaded for the desired user
interface. Multiple user interfaces are available, the two most common
require Python or Tk/TCL respectively.

>> A really simple example of this would be a controller that accepted USB
serial commands and had a number of outputs.  The command set would
support creating a sequential set of instructions in the device's
memory.  Each instruction would be a time index, an output, and an
output setting or something similarly low-level.  So the PC might tell
the controller to emit a 10ms 1v pulse on line 5 at clock=358ms.  Then
the controller is given the go command and it runs the program in realtime.
<<

Actually there is a much more sophisticated interface available, well two
actually, but the both work on the same principle. There is a module called
"emcrsh" which implements a protocol of machine commands, i.e. start / stop
/ abort, get machine positions, load a file (G-Code), see:
http://wiki.linuxcnc.org/emcinfo.pl?Emcrsh

And another called "halrmt" which allows accessing the "components" of the
system, I/O, etc. See:
http://wiki.linuxcnc.org/emcinfo.pl?Halrmt

It is basically a telnet like interface making it very easy to automate with
simple scripts or as an interface for completely custom user interfaces.

>> This kind of combination approach would let you run a more normal OS
with a fancy GUI on the PC, but still have full realtime control over
anything that is time-critical.

Disclaimer - I am NOT an expert on realtime anything, or CNCs in
particular.  However, it wouldn't surprise me if most realtime systems
already work in a similar fashion.  I know that most scientific
instruments tend to take an approach like this for anything that is
actually time-sensitive. <<

Separating the user interface from the control system also has other
benefits, because there are also problems between rtai and certain video
controllers, particularly NVidia.

Regards,
Eric

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug