Conversation

Notices

1. Embed this notice
   Elia :verifiedtrans: (elia@fedi.quiescent.nexus)'s status on Monday, 05-Feb-2024 11:06:56 JST Elia :verifiedtrans:
   picking up where we left off in the previous thread: https://fedi.quiescent.nexus/notice/AeRV7KpDmnSI2Ewg4G
   
   the hardware part o this story seems to be mostly done. it powers up and works. I have yet to test the actual servo drive, robot is not even connected at this point, but I'd say we're most of the way there.
   
   let's look at the boot sequence: https://www.youtube.com/watch?v=LWHW8WK4cDk
   
   00:03 - powerup.
   00:07 - low voltage supply status led check.
   00:14 - computer starts post sequence.
   00:26 - windows 95 starts booting.
   00:34 - wait what? yes, wxwrt.vxd. wxworks.
   00:40 - at about this point the external monitor starts getting output, as the kvga driver is loaded and enables the vga port, which is normally disabled.
   00:50 - windows boots, autostart kicks off kuka software.
   01:16 - the control software proper starts up and begins hardware initialization.
   01:39 - "download" begins - the digital signal processors on the mfc card are "downloading" firmware.
   02:00 - dsps boot, last stage of startup begins.
   02:20 - startup complete.
   
   now, this is actually not the correct software for the krc1 control encosure. it's the volkswagen software that was configured for the vkrc1 hardware (see the linked thread). this is why it immediately throws a ton of errors.
   
   next step: reinstall proper software.
   
   more posts in this thread incoming soon.
   • Roy Tam likes this.
   • Roy Tam repeated this.
   • Embed this notice
     Elia :verifiedtrans: (elia@fedi.quiescent.nexus)'s status on Monday, 05-Feb-2024 11:07:07 JST Elia :verifiedtrans:

     in reply to

     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.

     Roy Tam likes this.