Fusor remote - the big one

This is somewhat of an admission of failure. You can't easily pigeon-hole everything, and most real projects use commercial software, homebrew, and hardware all at once. So, for you makers out there (including me) - this is where to put whole projects that don't fit well in the other forums.

Fusor remote - the big one

Postby Doug Coulter » Sun Jan 31, 2016 12:10 pm

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:
Database.png
Database, served from fusorpi, overview

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.
FusorMaster.png
Local program to control the stuff in the danger zone from a safe place. Not finished!

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:
Genius.JPG
Danger - crazy man with computers and not afraid to use them.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Fusor remote - the big one - video remote

Postby Doug Coulter » Sun Mar 06, 2016 2:37 pm

Well. the LAN of things has been a good and useful dry run for this - I've been using a nice 2tb NAS I built off a pi-2 to backup and xfer things - like the attachment to this post. Not to mention "sharpening my claws" as it were - the fusor stuff is much more critical to get right, so I'm taking "baby steps".

What I have going so far - all in my op position room for the moment - is a setup intended to go on the fusor that consists of 3 Rpis - one is a pi-2 and is the "data funnel" as well as having a camera. The other two are pi-b1's and are just cameras - might as well use them up and keep the faster ones for fun stuff. While the pi-1's kinda barely make it as video recorders, they make it - so I don't care. I have 3 pi's, an ethernet switch, a fiber converter, and will be adding 2 ttensys, running on one lambda power supply and more or less all in the same chassis (other than the cameras). This in turn runs fiber optic Ethernet back to my LAN so no matter what - my LAN isn't fried. Multi-mode 100 MB fiber cable and converters are relatively cheap, and we're only using a bit over 30 MBit here, so it's enough (the rest of my lan is gigabit).

I have written some code, including a perl module, that allows remote control to the extent of starting and stopping these cameras, and capturing their "boxed" mp4 video back to the commanding pi (in this case the data funnel one, named fusorpi for some odd reason). This is almost as much sysadmin as coding. I am using the NGINX web server throughout, and the /html directory option in the camera software installs, so I "know" where everything is, and it's uniform across all the targets.
Since huge blobs (>1 MB/second of video per cam) don't go into databases well - and are already in the right form for playing (eg, .mp4 files) I created a directory "near" the /var/lib/mysql one, called /var/lib/FusorFiles for the cam videos and audio, with a separate subdir under this for each device. (Audio will be implemented on a teensy 3.2 when I get to that - stereo 44.1khz/16 bit). Heck, if I could have smell-o-vision remotely, I'd do it. All too many of our discoveries have been things we didn't anticipate, and wouldn't have initially done data aq for - they were just things that a human noticed and said the classic "eh, that's funny" that is the root of most cool stuff in science. I'm frankly daunted by trying to duplicate human presence "over the wire" given our experiences so far. And yes, "what's that noise" or "what's that smell" have been relevant at certain times.

This code, a perl module and a simple test for it, will be incorporated into the main run code. The perl module, Rcam, was meant to make it easy to remote-control cameras on pis, and one simply creates a few of them using the network name of each pi as a parameter to the constructor. These object references can then be put into an array and "foreach()" kinds of things done. Each camera has to share its camera media directory as ... media, and it's web software directory (/ver/www/html in this case) as cam, using samba. and cam has to be world-writeable as we are "fooling" the web server code by writing into a command fifo to start and stop cameras. Also, we add a special file, end_box.sh to the /var/www/heml/macros directory, which creates a file in media called cap.txt that has the path of the most recently recorded video in it once it's been "boxed" into .mp4 (I didn't make up that terminology, it's theirs).

One can then say $camobj->start(), stop(), or copy_vid() for each cam object, and the right thing happens. The copy routine returns the name of the resulting file (basically a time stamp with a bunch of cruft removed) so you can then stuff that into the database instead of an enormous video file.

For long videos, the pi's take awhile to get that "boxing" thing done, and I've not yet worked out how best to time that - you shouldn't call copy till that is done, and rough measurements here show 15 seconds for a pi-2 to box 2 min of video, and 1 min for a pi-b1 to do the same. I am hoping I can use other delays that will exist rather than having to put in explicit ones, it's not like there won't be plenty else to do at the end of a run, and I can likely use the time that takes, and the time the copy takes from the faster of the pi's - to let the rest of them get done. Fingers crossed. I'm just working on the pieces of a pretty big systems design at this point, and some details are left for later when I have more experience with how it all works.

Here's the code du jour:
VidSuite.tar.bz2
code for "data funnel" pi and others
(2.58 KiB) Downloaded 888 times
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Fusor remote - the big one

Postby Doug Coulter » Fri Mar 25, 2016 4:02 pm

Bit by bit (heh), hole by hole...coming along. The new ops position is nice, and finally it's warm enough to resume hardware work in my shop without killing my heating budget (since I've moved to another building and the shop takes 2+ days of heat to get reasonable - all that thermal mass).

Not that pretty unless you just drilled all those holes and tapped a few in an age-old wrong-alloy Al chassis. You can almost cut this stuff with an exacto knife, but that's not a good thing when it comes to drills skating, burrs, warping...about the one good thing you can say about this 1950 alloy (inherited from my Dad) is that if you center punch one side, you can then see the bump on the other, re-punch and drill from the easy side after laying it out on the inside.
Already test mounted are two lamba power supplies. One 5v and +/-12, the other 40 and 20v for running solenoids in the gas control system (and to be switched down by "simple switchers" for other uses).

The box will contain:
1. Fiber<>100baseT converter - galvanic isolation from my LAN.
2. 8 port switch - for the internal pi, and two external ones that are basically just video cameras/recorders
3. an arduino uno (running off a separate 9v supply so it's internal 5v regulator is used for a/d ref - more stable than USB) - this is the main numeric data aq and will also do a geiger and one neutron (hornyak) detector. Using an uno for that fast hardware counter for the neutron detector - teensy doesn't have an externally accessible one, and if history is a guide, we have the need for speed - we can't just count interrupts.
4. a teensy 3.2 which is going to be the main pid loop controlling the ion source to keep the main grid inside set parameters for current draw, and also control the gas system to keep things in range for the ion grid control.
5. The local master Pi (with 2 TB disk drive), which runs all this, a mysql database, has a camera of its own, and can drive some servos for tuning "the magic". The sql database will be auto replicated to the op position here and be plotted from that in near real time.
6. A probably useless touchscreen for that pi. In real life, it'll be run via VNC from here. Too cool to leave out for later photos, though.
7. the 800v power supply for our standard geiger tube.
8. signal conditioning and various supply isolators to get clean power for this and that. Various servo drivers and things like reset signal generators to make various computers shut down clean, and a clapboard signal to get time-sync.

Big box, but there will be a lot in it. It's going to be stacked with our big Spellman power supply in what I hope is a fairly quiet EMI environment. Just in case, few holes, galvanic isolation from the LAN, and yes, that piece of copper clad board bolted over the box opening.

Video will be taken through the view port, of the 2.5 ghz 4ch scope screen and the servos. Seems crazy if you're from the days when you did not-human-readable binary over the wire to save bits, but getting scope caps as video is actually a lot faster than using the wimpy microprocessor in the scope that's lucky to hit 9.6kbaud.

I think I have the software design more or less down, else I wouldn't be doing this yet. Details of the sql table structure almost done, but changing that here and there won't affect hardware setup. More like reflect what actually got built.

ControlChassis.JPG
Gotta clean that bench so I'm not working on the floor!
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Fusor remote - the big one - Pi 3 USB power

Postby Doug Coulter » Mon Mar 28, 2016 4:30 pm

I'm pleased to report that after the usual apt-get update and upgrade, the fancy version of debian with only /boot on the SD card and the rest on a 2 tb laptop disk just ported right over to a pi mod-3, no changes required. Well, one...

They did it again. I measure 19.xx k to ground on the pin of the USB power chip where it should be 10k for full spec power (2 amps total). It's still called r50, r4 isn't in the layout anymore (eg no transistor to add conductance via another resistor - r4 - in /boot/config.txt). There's not as much room there so I couldn't replace it with an 0602 (what I've got in stock) 10k, so I put a 20k in parallel with it for this go around. I will order some proper physical size and value resistors to get this right.
My calipers measure these parts ~ 1mm in length, width is the usual ratio (less). I didn't know they made them that small! The 1/16th watt resistor I used is huge in comparison, and there was no way to place a bigger smd R and get the connection due to the layout- not even on-edge.

One wonders if they're trying to stay inside spec of their bad-choice microusb connector, or their too-small fuse? Haven't blown a fuse yet, and I usually just solder power wires to get a better (and less heat) connection for 5v on my projects. I know that when my nexus 10 tries to push a few amps through that microusb, it gets kinda hot like you wouldn't leave your finger on it - heat implies voltage drop...All my pi projects lost any flakey when I went to soldered wires and a sufficient power supply, is all I can say.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Fusor remote - the big one

Postby Doug Coulter » Thu Mar 31, 2016 3:38 pm

Little by little...burning some of this in before moving on to complete the rest. It looks like this now:
FusorMasterTest.JPG
Remote controller, for fusor position

There are two Lamba power supplies to run this - one is +5v and +/-12v, and hiding it on top is one that is 24v and 45v, mainly to run gas control solenoids, but also I will be switching some of the 24v down with "simple switchers" for supplemental 5v and 9v for the Teensy and Arduino Uno that do the real-time work.
The Raspberry Pi in the upper center is to provide ethernet, a camera interface, and to control the real time uP's and put gathered data into a MySQL database - general linux stuff. There is a 5" touchscreen on top (the guy with the blue led) which I will use mostly for debugging and perhaps an emergency "scram", though if I need that, I shouldn't be in the room - the entire point of this exercise.

The grey box in the lower left is a trend-net ethernet to multimode fiber converter (100mbit as is all this in the box). I want galvanic isolation from the rest of my lan in the event of an arc or other EMI. Just to the right of that, with the green lights, is a generic 8 port ethernet switch, for this pi, the fiber converter, and two other pis that will have video cameras recording the scope and the tank insides. The main pi here also has a cam, with pan-tilt, but is just for looking around in the room - you never know what you don't know or will need, it seemed reasonable to provide for "what in the world is going on over there?". As in, should I shut it down, run over with a fire extinguisher, bolt cutters, what? All 3 cams will also be live-streaming to the operating position so I can watch it all and hopefully notice useful things.

The DB connectors on the bottom are for connection to two Spellman power supplies (main and ion source) which will be controlled by the Teensy, which is yet to be mounted on the brown perf board. One other db-9 is for some of the hard wires coming from the op position - for those "just in case" things if the network goes down - safety first. There are some BNC's for the geiger counter, the neutron detector (hornyak) and the tank pressure gage, which will be used as a backup in controlling the gas pressure and ion current (it will handle outlier cases such as a power supply shutting down without warning, so the control loop won't pump in more deuterium wastefully and so on).

The slot in the upper left is for the cables from the slaved pi cameras, including ethernet, power and force clean shutdown signals. The slot in the center right top is for the main pi camera cable and servo wires. Mounted just to the right of the Pi is a 2 terabyte laptop drive. The pi software (Jessie) is configured now so only /boot is on the SD card, the rest is on that drive, including all the data collection. More atoms per bit will be more reliable in noise and radiation flux, and the disk should provide just that. There's every indication this setup is very reliable - but we have belts on top of suspenders and a reserve 'chute just because - that's some expensive gear and I don't want to be helplessly watching it burn up from 70 feet away.
There is therefore also a buried, armored Telco grade 6 pair cable that will provide positive power shutdown to the entire rig, bring back realtime audio for recording at this end (it's getting tight in that box), and give me some other interlocks and indicators that work "no matter what".

I'll be using a modified version of udaq (elsewhere here) for most of the numeric data aq via the Uno, and I'm writing custom code for the Teensy 3.2 for the ion grid power and gas flow control such that it should keep things near my desired, programmable, setpoints.

FWIW, though it doesn't seem to matter here, the pi model 3 IS a bit faster than the model 2, maybe not more mips/watt, though. I only run this when power isn't an issue, so why not have plenty?
It did need a version of the high power USB hack to give me all it could out of the USB jacks, but even so, neither the Uno nor the Teensy will be powered that way - for reasons of noise (and fewer single points of failure), they'll have their own filtered supplies.

Looks pretty good from here at the op position (this stuff is in the next room right now).
SelfPoitrait.png
VNC desktop and self-poitrait shrunk a little to fit on one screen. In real operation, I have 6 high resolution screens - but that's a heck of an up or download to here.


The basic start-stop and retrieve from all 3 cameras is "go" - now for the rest, which is largely duplication of work already done here, most of it should be pretty quick and not too painful. I will be glad when the metal bending stuff is done and it's all mounted in place and wired, for whatever reason, I like the programming parts better than crawling around on the floor trying to get wires soldered to the right pins and pulling metal out of my skin.

All of this is designed such that almost any single piece can fail and I still get most of my data, nearly no matter what. A lot of thought sometimes goes into things that "look simple" or "conceptually trivial" by the time they become a reality.
All this seemed so simple to run in person (after a lot of work to "make it so") but remoting it all - and trying to remember and handle all the edge cases a human does without thinking about it - not so easy.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Fusor remote - the big one

Postby Doug Coulter » Sun Aug 28, 2016 6:58 pm

Time is getting short to finalize the patent filing (whew, I'll be glad to be able to talk more about what we found, finally) but first - replication and nailing down a parameter or two. The "big box" or "Doug robot" at the fusor needed one more arduino to control the ion source and gas supply, which I just got the "hurry up cowboy" version of done today. It's only going to let me do some things by hand (eg click buttons on the remote VNC screen) for the moment, if I have time I'll add the fancy state machine(s) for doing this automatically once enabled.
The resulting code is decent boilerplate for this kind of thing, though, so I thought I'd share it as it is. I did some fairly slick tricks to get 12 bits good out of 10 bit a/d converters (averaging both IIR and FIR), run some things time-deterministic fast and slow while doing output synchronized to a "clapboard" signal with no time-slip. If I have time, adding a couple state machines for the two control functions should be easy (tuning them might be another story).

I'm doing the arduimo development on version 1.6.10 on an odroid XU4 running debian 8 - it's fine for that, and the same code will run on the pi-3 in the box, so I'll be able to make changes easily even after it's all mounted up and across the yard, from here. So I thought it'd be fun to take a pic of the dev system (sans display and keyboard which are on another table).
100_3108.JPG
Dev setup, with some LEDs pretending to be solenoids.

Or just the arduino and ancillary parts on a "screw shield".
100_3109.JPG
About ready to mount up.


Here's the code, share and enjoy - with some minor changes it's a good place to start and get some real time stuff working right.
uFuseControl.zip
Uno sketch
(5.99 KiB) Downloaded 832 times

It's pretty clean stuff (for me). Uses under 25% of rom/ram and time. Reports at 10 hz to the master machine, under command, it's fairly slick (oversampled to get more bits and so forth). I hand-coded some stuff for timer1 interrupts and external even counting as the IDE no longer supports that, as well as a few other nice tricks.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Fusor remote - the big one

Postby Doug Coulter » Mon Aug 29, 2016 11:03 am

And now it's in place, though not totally wired up yet. A couple vanity shots:
Fusorpi.png
Remote arduino dev on nuc via a pi in the fusor control box...heh. A good worker gets the good tools going on.


And here's the box. We have two arduinos (uno) slaved to a pi-3 in here, power supplies, an ethernet switch, fiber converter, and connectors to various things in the outside world, including 2 more pi's in boxes with cameras, a stereo microphone (so I have 3 eyes and two ears out of this), and we can write it all down on that nice SSD in the box (mySQL) and will soon be viewing the collected data remotely via a program at this end on the big 4 monitor box using mySQL's replication function. The idea is to gather data up to any point of failure (assumed it's going to happen despite best effort shielding and so on), so I don't lose any (again) and can finally get a couple of crucial numbers for the patent I'm only able to guess at so far (probably good guesses, but you know how legal things go).
100_3110.JPG
In real life, this has a copper plate screwed over the big hole, ferrites on the ethernet cables to the other pis, and so on and so forth. Fiber to my LAN for galvanic isolation.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Fusor remote - the big one

Postby Donovan Ready » Sun Sep 04, 2016 4:22 am

Very nice, and I hope the lawyers will have fed enough soon, :mrgreen:

You write and document your code excellently, thanks!
Donovan Ready
 
Posts: 239
Joined: Thu Apr 17, 2014 1:22 pm
Location: Austin, Texas

Re: Fusor remote - the big one

Postby Doug Coulter » Sun Sep 04, 2016 1:06 pm

Reeeeeal close now.
Consider this my offsite backup of the code and a couple pix of the current status. The perl code for the pi probably won't run on your system, as it has some dependencies on particular hardware and sysadmin settings on other computers, but it might be fun to look at. I like perl - as you can see it took fewer lines of perl to do this than it took xml to define the GTK screen layout(!) - and I didn't write it in cryptic fashion to save characters - I've got to be able to maintain it myself after I forget things and so on. I like padre or gedit for looking at this stuff for the good syntax highlighting, FWIW.
Nice to have the "parts of speech" in some language all different colors, and it makes syntax errors more obvious while one works.
I did a perl module for the remote pi cameras that handles starting and stopping them and various issues with samba so I can diddle their innards remotely. It would go wherever your system wants to find those. fm (fusor master or fsking magic, your choice) and fm.glade go in your /home/youruser/bin. Later I can paste in the glade and have the program all one file, but while I'm still changing things it's easier to have it in a separate file (there are gui creation subroutines for either way in the main fm code).

A good workman doesn't complain about his tools. What's often left off that saying is "because he sets himself up with good ones". From editors to remote desktops, a shop NAS, plenty of computer horsepower and pixels...I managed somehow :lol: . This actually all works on the bench - and is tested. But...now to move it to the lab and hook it up to the real stuff and...well, we'll see, that's a lot of wires, cabling, and assumptions to all have right on the first go. I'm sure there will be a little "technical adjustment" going on soon. :| Just moving all this is going to be interesting.
FusorPi.zip
The pi code (sans all the sysadmin stuff in /etc)
(12.88 KiB) Downloaded 813 times

Rcam.pm.zip
Perl module to diddle raspi cameras
(3.56 KiB) Downloaded 806 times

Fsr.sql.zip
The pi (and remote) database definition sql
(1.2 KiB) Downloaded 803 times

ardsketch.zip
The code for the two arduinos used
(417.29 KiB) Downloaded 816 times


And a gratuitous pix for grins:
100_3112.JPG
Where I will be when the danger is "over there".


The two leftmost screens are on their own machine, the other 4 are on the fusor main control machine. Most of this can be switched around at will, and I'm using a Kode keyboard, logitech wireless mouse (and camera and headset) tied to all my machines (4 at this spot) via an IOGear 4x4 USB switch to save some desk space for, you know, books and stuff - or pizza and beer.

Edit to add this -you can see why despite it's few bugs and quirks I like padre for perl editing..Easy to navigate big things, and one syntax error and everything after that changes color to warn you that you've messed up. Good tools...
Padre.png
Good for finding stuff. I use gedit too.

And this. I think one reason there aren't more decent GUI programs in linux is few master this tool and know what to do with the crazy XML it creates. Worth the effort for me. Not that this is a great GUI, just one suited to this particular user...
FMGlade.png
What I actually edit for a GUI - not all that nasty XML this makes.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Fusor remote - the big one

Postby Doug Coulter » Tue Sep 06, 2016 2:20 pm

In addition to the more fun computer parts of this, I wanted a "no fail" backup shutdown. One serious exposure was enough. A friend (Thanks Paul) donated a roll of telco armored burial cable.
Bill helped me wire up the tedious parts.
Yes, this might be a little overboard on safety but...like a reserve chute, it's nice to have. I did my best to design and route the critical signals such that either an open or short to ground would force a shutdown, for example. Not quite fission-reactor safety grade, but working on the same kind of idea here - no matter what else should fail, shut this thing down. False positive shutdowns will be tolerated for safety (since I don't lose money, just footsteps on one, I can be even more conservative in some ways).

Doesn't look like much either on paper schematic or this picture, but it sure makes me feel better. There were some wires left, so we push back zero latency audio, and a few indicators from the front panels of the power supplies too. But the stars of the show are those two big solid state relays which sill be in series with the 240v main power - even if either one fails short - we're off when we want it, as nothing goes between a phase and neutral in this design.
100_3113.JPG
This will be bolted to the floor by the fusor and inline with the power to it. Connects to my manual control panel described elsewhere.


Sorry autopilot and IoT fans. I've been around computers WAY too long to trust my life to one. Even if I wrote the code and built the thing.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Next

Return to Combined projects

Who is online

Users browsing this forum: No registered users and 0 guests