so what’s up with that vxworks?
this is what happens:
- windows loads the vxworks “driver” which is actually a vxworks bootloader.
- vxworks kernel starts booting, preempts win95 kernel and takes over.
- vxworks kernel installs its own interrupt service routines.
- vxworks finishes booting, then turns windows into its subprocess.
- win95 is allowed to finish booting, unaware that it’s no longer really controlling the machine.
from that point on, win95 is handling gui and some pheripherals (disk, network, etc.) and runs the non-realtime parts of control software.
vxworks, meanwhile, runs some of the realtime part of the entire thing, on the same 400mhz celeron. those include motion planning and axis position feedback loops.
the final part of the puzzle is the texas instruments tms320c32 digital signal processor that runs the hard realtime tasks including servo phase waveform generation.
this is not entirely unlike other industrial realtime control systems, but it is admittedly a bit wacky and unique. to the best of my knowledge, this vxworks port was not used by anyone beyond kuka.