Well it seems I definitely have my software developer hat back on now, so I'm going to run with it.  I hope I don't lose my hat.

Updated the BBG in prep for setting up my build environment, which broke Machinekit.  I'm bailing again, and starting over now with a fresh disk image about 1.5 years newer than what I was running.  When I worked on that image last, Stretch was brand new and I had to do all sorts of nonsense to get it to work.  Undoing that is likely more work than just starting over.  To that end, I've backed up my Machinekit config thus far here.

<EDIT> Up and running on a new image, minus the updated kinematics.  That was relatively painless.  I now *have* to recompile tripodkins though, as my previously compiled .so for itripodkins (inverted) doesn't work anymore. So now my Z axis is upside down as tripodkins seems to ignore my negative HOME position, and so it doesn't flip the math on it's own.

</EDIT>

<EDIT_2:> Ok... Hats off to the Machinekit folks.  Realized it's all setup to cross compile right from the git repo, using docker.  That's probably what I did before and forgot about it.  Make a fork, made my changes, and ran the docker build using 

scripts/build_docker -t armhf_9 -c deb

Thanks to being able to use my room heater of an i7, less than 5 minutes later I had two .deb packages.  

I ignored those and went looking for the 'itripodkins.so' file I just built, and found it in machinekit/rtlib/modules/.  That compile would have taken at least an hour using the BBG processor.

I copied that into my freshly built image at /usr/lib/linuxcnc/rt-preempt/, and it works.  I now have the rc servo for part rotation as a proper axis, with limits, scale compensation, and the trajectory planner knowing exactly how fast things can move.

Made a script to do the rest of the needed configuration.  I think I'll package up my own image from this.

</EDIT_2>

In other news, I think I've found a nice way to split the video stream going into Openpnp using Gstreamer vfl2sink, and the vfl2loopback kernel module.  Right now I can setup either the top camera, or the bottom camera in Openpnp, but not both.  They both expect exclusive access to the camera and since my implementation has only one camera... uh... that won't work.. but this might. If all goes well, it will even use DMA copies to do the split so basically no CPU penalty.  I'm psyched, but it's still early.  :)