Hi Charles,
Nope, don't have it other than in my head...and I should do as you suggest - my head isn't perfect and I forget things if nothing else. We are already at the point where it's good to go down a checklist when setting up and running - there's just a lot of it, and a few different kinds of things to do to get it all working together. Maybe I could at least make a video or something. Of course it's all changing over time, and there are some experiments still done local at the fusor - some risk, not much, but it's so much slower to set up remoting (and in some cases expensive) that it seems worth it to do a "smoke test" here and there for things that will most likely be a one shot test.
I have to say, it was a major breakthrough to get it to this point - push some buttons (metaphorically) and get repeatable result data - every time. I'm unaware of anyone else getting quite this level of that. Key was, looking back on the years - that good HV feed-through that a few pro physics consultants said was impossible to do under the conditions, and a good gas control system, both homebrew. Till those things happened, there was a lot of luck involved, and it was as hard to fly as a helicopter upside down while blindfolded with the controls duct-taped to your shoulder blades.
(I will make up a visual for this fairly soon - it'll be a cool looking chart)
The central actor in the setup is a machine called FusorPi, a raspberry pi mounted in a tight EMI shield right at the fusor. It has 2 arduino unos slaved to it, and those do the data acquisition and control for most things - unos are better at time-deterministic things, while the pi running linux is better for "complex but not so quick" kinds of things - like complex interface protocols, graphical user interface, databases, backups and so on. Initially, I was running mySQL on that pi, and replicating that database on another machine at the operating position (in my living room, more or less), and the heavy lifting like realtime plotting was taking place on that machine to offload the pi. Also, it served as a check for the database replication, as it was plotting from the slave database. I don't do that quite the same way now. After getting a big synology NAS, I have it running the database - the pi writes to it, everyone else reads it. The pi runtime software does data aq and also writes things like my control inputs (what buttons I push and when on the user interface) during a run. The idea is to have it all in one DB, by run. During a run, there are also some video cameras recording (raspi based) which are started by FusorPi, and at the end of each run, their videos are also uploaded to the NAS. One camera shows the insides of the fusor, one shows the scope screen (4ch, 2.5ghz sample rate) and one the room. I also record audio in FusorPi and that file also goes into the DB lashup. The idea here is to use the best tool for each job and get them all to work together in a fairly automated way. Lots of little pieces, and the failure of one might not leave me without any useful data. There are plenty of times when loss of one video or audio wouldn't mean much - and times when say, that video of the scope is all-important, especially in conjunction with the various numeric data. Getting that to stay in time-sync was quite an interesting journey in the sense of "living in interesting times" - not very much fun.
FusorPi uses a fiber optic converter to connect to my LAN, paired with another converter out of EMI range...that whole mess effectively floats. I was toasting NIC interfaces whenever there was any arc before. I do most of the control via this ras-pi, using a remote desktop (VNC) from another machine at a safe distance. Most of the code is actually running on that pi. Other things like scope control run from the operating position - on the network as soon as anything is remoted at all, it doesn't matter so much where it's controlled from if time-sync isn't the big issue.
Since there's a lot of stuff "on the edge" and various safety concerns, I have that panel that is connected to the shop with buried telco cable, and it's a positive control for a couple of power circuits, realtime audio (you'd be surprised how good it is to have that), some interlocks, and a go button. The idea there is that if I turn that panel off, it kills main power to the fusor stuff. There are other options that just "safe" things, but it's nice to have absolute control and "you are OFF for CERTAIN". This is accomplished by having solid state relays in the power at the fusor, and their "coil current" is provided from the living room station - any failure at my end turns off the world - a short, an open, failure of my local 12v power supply...if it's not perfect, it won't come on.
I can see I'm going to have to do another walkthrough video on this at least.
What I now have is kind of built on what is shown here:
https://www.youtube.com/watch?v=zc-r23B6f-8
I just realized I've not shot a video walkaround of the current setup or even anything close to what's there now. I'll fix that. It's in flux, but then it always is..maybe that's the point here - how it's set up to allow experiments with the lowest possible fuss, but with the ability to document accurately what happened in the "we tried this and saw that" sense.
I've just been adding this and that to it, and shifting some things around. In my off-grid situation, keeping a master and slave database going and synced through various real life situations and updates was not super practical and as it turns out, not really needed - once I solved the "frying from lightning on the network" issues - simply putting the database on the NAS works fine. This of course meant changing a ton of software to work with the new setup...A lot of this is like being pecked to death by ducks when you want to be flying with the eagles.
As I'm moving to a dynamic drive to "herd and recirculate" ions and electrons, I'm doing some initial searching for the right conditions with stuff that's kinda hard to really automate, or at least to get it to sweep through some of the parameter space. Some of this stuff is kinda flakey in the sense it might go up in smoke - it's hard to make robust and not worth doing till I'm in the right octave of parameters anyway. This means remote testing is a bear - so what I'm doing is testing at "low settings" up close and personal to eliminate the 99% of chaff that doesn't fly at all - and doing the work to remote at least somewhat, the final testing of things that "make the cut".
For example, our main HV power supply, a really nice SL2KW from Spellman (thanks again CliffS) - looks like being relegated now to bias for what looks more like a quadrupole mass spectrometer drive setup. Thing is...really HV AC arbitrary waveforms are kinda past the current state of the art, if you want some bandwidth, and don't have exact specs in hand for waveform, frequency, voltage. You can make any one thing...but there is nothing that will make "any waveform from 0-50kv, with microsecond to millisecond time resolution" - for any price. I can make things that are "in the room" but very limited in their range of parameters, and maybe not super robust - doing too much work on that before we know what we actually want in more detail would be wasted, but it does make this search more laborious than it would be to program "foreach (x,y,z in try everything){}" and wait for the answer to pop out.
Sure would be nice to have a super mathematician on board to narrow things down further - it would save a ton of perspiration. But this problem of guiding particles to be where we want when we want them there, bunched, and with the electrons showing up at the right time with the right relative velocity too - is not susceptible to being solved with the math tools that exist, for many-particle situations where the particles are charged and thus every particle affects the trajectory of every other particle. In a mass spectrometer or ion trap, there are so few charges in such a big space you can assume there is no effect from Coloumb forces. Here we want to be at the opposite extreme - those forces dominate when you have the density (even if that's more or less instantaneous, things see each other before they get there) we need to make this practical.
I guess I shouldn't have been too surprised at the power supply - this kind of thing was bound to happen at some point - people just plugging together things without really understanding how the pieces (that they stole, in effect) work. It seems like they're good supplies, but...
Upcoming is going to be a replacement of the screwy USB interface board with an ESP8266 using wifi instead of cables, with over the air updates, and by gosh, the ability to return to manual control without a power cycle - I worked out how to do that one too, by finding the reset pin on the other microprocessor that controls the thing.
The ESPs at least will have unique ID's on the network, so there won't be a danger of sending the commands to the wrong one and letting the smoke out of things (on top of the normal risk).
Wifi is better for me anyway in this EMI environment. While they did opto isolate the USB signals...the USB cable ground still grounded their box to your computer...pretty sorry. That's a nice long antenna to make the ground loop from hell with - one that can let the smoke out of things.
.