The LAN of things, while useful on its own, is/was really a dry run for something larger and more important. I wanted to get my feet under me, so to speak, and get all the obvious bugs and issues worked out before applying this tech to something where a mistake can be costly and dangerous...the fusor. I really don't want to have to buy more expensive physics gear, lose data from a run due to whatever reason (EMI can crash computers, for example), and of course, I need to know when it's safe to re-enter the "reactor room". And yes, the wiring is going to include some hard remote shutdown and interlock stuff that doesn't depend on any computer being up whatever - I've seen those Star Trek episodes, and have enough real-life experience not to bet my own safety and money on even good code and hardware past a certain complexity level. That stuff is nice when it works, but most people don't unnecessarily test their air-bags or perfectly good parachutes - though one has them for good reasons! Even my day-to-day "LAN of things" stuff has manual backup/override provisions for good reasons. When something simply has to work - you make sure there's more than one way to get 'er done.
Where to begin? This is such a complex setup, that was the first question I had to answer for myself, along with needing it for this post.
I decided to start with a relational database model. This defines what I want to acquire, what I store about how I acquired it (things like what's connected to what data aq input and scaling factors, units, you name it), and which data aq happens to be going on which run, along with comments and the usual other stuff one wants for documentation. Having done that, the rest is a lot easier, the tasks divide themselves up fairly well - I could even get software help to write some of the pieces now, not having to totally depend on "great mind runs in the same track" at this point, though for now, it's all me doing it. Along the way, I have and will continue to find gotchas and workarounds, which I will document here on the board to save others from some of the grief I've had getting this all going, there are a few oddball things one has to do "not quite like the web tutorials" say. Those may not go in this thread if they have more general applicability - I'll try (it's impossible to get it perfect) to put them someplace meaningful, given what they are about.
Some of this isn't ready enough for prime time to post up here, but rest assured that as soon as things get to "production" I will share them here - and not only for the reader's good, unless you count me as one of the readers. This board is a great "cloud backup" that is searchable...it's saved my bacon more than once. We all win.
My tools for this are Perl, Glade, NGINX, MySQL, RPi_Cam_Web_Interface, phpMyAdmin, gedit, shell (and whatever else, these are the main ones).
Here are some screenshots of the current state of things:
Yup, I'm using a raspberry pi for the fusor-proximate main computer at this point. It provides ethernet for the setup (wireless) and controls the slave data aq boxes, which are a PIC (what we've been using all along) an Arudino UNO - described elsewhere here to get some more inputs, a Teensy 3.2 for the gas and ion grid control, and a couple other raspis for cameras, controlled over ethernet themselves. I have a backup if the pi should choke on this workload, but if I can, it's good to use a pi - expendable, harder to crash than a PC with EMI, and it's good to develop knowing you don't have gawds own computer to run on - makes you efficient. Really, all it does is start slaves, suck up data, put it in a database, and pass commands through from my remote computer in the control room. Should be a piece of cake? I added a 64gb Sandisk "extreme" USB3 stick to it for most of the storage that'll get pounded on - much faster than the fastest SD card in actual tests here. Most USB2 sticks won't actually keep up with full USB2 speeds, especially in writing. This one does (it wasn't cheap but these things FLY). I'm using these or magnetic spinners for any pi around here that needs a lot of reliable storage...it's worth it.
This is my main screen (not finished!) for the control room, running on a computer local the the room. In real life, it will run on the fusor-proximate machine and be used via xTightVNC.
The 3 or so live vidcams will be both recording at their local cpu, and live streaming the the control room. There's plenty of horsepower here to handle a few video/audio streams (6 large monitors and a few gamer-class PC's). After a run, the video files will be copied to here in a directory "next to" the MySQL one, and their path names placed in the "blobs" table indexed by the run number, to keep it all together. Yes, this violates some ideas of design purity, but MySQL really doesn't like enormous binary blobs...and it's a time-waster to read them, stuff them in, then later have to pull them out, make files again, so they can be played. A question of balance, as always when doing this sort of thing.
I'll come back after I've posted some of the tricks I needed to learn to get:
Glade and GTK3 working on perl - again. Was easy with GTK2 but it's getting hard to find a glade for that version, and nope, they aren't compatible in either direction, either in data or coding.
Pi cam install to work and not wipe out all the other pi web content. NGINX and RPi_Cam_Web stream tricks. (one useful resource for that)
Remote control of pi cam, and collecting files from it (samba and perl tricks) Some of the modules you need to write a remote FIFO with commands don't install too easily in the normal ways.
I didn't want to have to click a bunch of stuff to start a run, can't do it all at once anyway, and I'd forget to start some important thing if I had to do them all separately, so automation is the way I'm going here.
Just grab it all and let Doug sort it out later...
Since all this stuff is in kind of a fluid state, I'm not yet posting the SQL for the database structure, or most of the code yet. If someone is in a hurry to see it, let me know, but you can count on it not being compete yet.
I'm just cranking this out on one of my dev stations for now: