I compiled the burt binaries on c1auxex2 which took a little fiddling with dependencies and paths but nothing too major. The complete local epics folder (/opt/epics/) which contains the base epics binaries, modbus and burt for 32-bit linux has been copied to the shared drive at /opt/rtapps/epics-3.15.5. They belong to the most recent stable release. This was so we can now automatically call burt after the IOC initialization on c1auxex2 to restore the backed-up channel values.
I also copied the database definition and modbus instruction files to /cvs/cds/caltech/target/c1auxex2, from where they are now being read upon IOC initialization. This is an excerpt of the service file:
#ExecStart=/usr/bin/procServ -f -L /home/controls/modbusIOC/modbusIOC.log -p /run/modbusioc.pid 8008 /opt/epics/modules/modbus/bin/linux-x86/modbusApp /cvs/cds/caltech/target/c1auxex2/ETMXaux2.cmd <-- Contains logging to file, see note 1)
ExecStart=/usr/bin/procServ -f -p /run/modbusioc.pid 8008 /opt/epics/modules/modbus/bin/linux-x86/modbusApp /cvs/cds/caltech/target/c1auxex2/ETMXaux2.cmd <-- Initializes the EPICS IOC with Modbus support
ExecStop=/bin/kill -9 ` cat /run/modbusioc.pid` <-- Kills the detached process by its process ID
ExecStartPost=/bin/bash -c "/opt/epics/extensions/bin/linux-x86/burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/latest/c1auxex.snap" <-- Restores general channel values
ExecStartPost=/bin/bash -c "/opt/epics/extensions/bin/linux-x86/burtwb -f /opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt/ETMX.snap" <-- Restores PIT and YAW values from align MEDM screen
ExecStartPost=/bin/bash -c ". /home/controls/modbusIOC/ETMXaux2.sh" <-- Enables writing to PIT and YAW DAC channels, see note 2)
Note 1) I removed the logging to file for now because I noticed that if there are Acromag communication issues the logfile tends to grow in size VERY fast. In the cryo lab is had gotten to over 70GB just over the winter break. I don't think it's absolutely necessary to have it, and if diagnostics are needed we can easily uncomment it temporarily.
Note 2) I modified the static EPICS records of the four OSEM bias adjust channels so they won't start updating as soon as the IOC starts up (and before the channel defaults are restored by burt). This was done by setting the OMSL (output mode select) field from "closed_loop" to "supervisory". Sample record:
field(DESC,"Bias Adjust for ETMX UL Coil Output")
field(OUT, "@asynMask(C1AUXEX_XT1541A_DAC, 0, -16)MODBUS_DATA")
field(OMSL,"supervisory") <-- Used to be "closed_loop"
field(DOL, "C1:SUS-ETMX_ULBiasSet PP")
Now, on reboort/IOC re-initialization the physical DAC channels are performing a one-time readback of the last stored value in the Acromag's register, then idle until the last StartPost statement executes the script ETMXaux.sh, which changes their OMSL field back to "closed_loop". This causes them to start updating their output from the calc records defined in their DOL field (which have by then recovered their default values curtesy of burt). The result is a smooth transition from idling to the controlled state with no sudden or large offset changes.
The result is a smooth transition from idling to the controlled state with no sudden or large offset changes.
While checking how smooth the transition is we still noticed significant motion of ETMX by looking at the locked green laser and OpLevs. We found that this motion was not caused by interruption of the slow offset adjust, but rather the Watchdog being re-initialized to its OFF state, which cuts the fast channels OFF. On other optics this is observed too, but not as severe. The cause is a rather large offset on the LR coil coming from the fast DAQ, which was reported as 50mV by the slow readback channel (while other readback values are <10mV). It is present even when turning the output of the CDS model OFF, but vanishes when the watchdog is triggered. This helped us trace it to an offset of the DAC output itself: it is present at the output of the AI board but vanishes when the DAC is disconnected. The actual offset is ~40mV, as opposed to other channels on the same board, which ahve offsets in the range 3-7mV.
While we can compensate for this offset in software - it made us wonder if the DAC channel is somehow busted and if that's what causing the 'wandering' of ETMX that we have been observing recently. There are two free DAC channels on the AI chassis that has the side coil and the green temperature control signals. We could re-route the LR signal through a different DAC channel to fix this.
gautam: 40mV offset at the AI board output gets multiplied by 3 in the dewhitening board, so there is a 120mV DC offset going to the coil (measured at dewhite board output with DMM). The offset itself isn't hurting us, but the fact that it is several times larger than other channels led us to wonder if it could be drifting around as well. From my SOS pitch balancing forays, in my head I have the number 30mrad as being the full range of the OSEM actuation - so if the offset swings by 120mV, that's ~150urad of motion, which is quite large, and is of the order of magnitude I'm used to seeing ETMX move around by.
I moved the epics IOC server process for the single Acromag ADC that monitors the PSL signals from megatron to c1auxex2.
First, I disabled the legacy support on all channels as explained in elog 13565. Then I copied the files npro_config.cmd and NPRO.db from /opt/rtcds/caltech/c1/scripts/Acromag to /cvs/cds/caltech/target/c1psl2/ following the pattern of the old Motorola machines and the new c1auxex2. I had to make some edits for correct paths and expanded the epics records to the standard we're using for ETMX.
I then added a service to systemd on c1auxex2 that runs the epics IOC for the Acromag PSL channels: /etc/systemd/system/modbusPSL.service. No more tmux on megatron.
Running two IOCs on a signle machine at the same time did not produce any errors and seems fine so far.
I wired the six available BNC connectors on the front panel of the new XEND slow DAQ to physical Acromag channels. There were two unused ADC channels and eight DAC channels, of which I connected four. The following entries were added to /cvs/cds/caltech/target/c1auxex2/ETMXAUX2.db /caltech/target/c1auxex2/ETMXaux2.db
C1:Vac-CC1_HORNET_PRESSURE_VOLT is converted to the additional soft channel C1:Vac-CC1_HORNET_PRESSURE in units of torr using the conversion stated in the manual. A quick check showed that the resulting number and the displayed pressure on the vacuum gauge itself agree to ~1e-8 torr. Gautam added the new EPICS calc channel to the C0EDCU and restarted FB, now the data is being recorded.
Three of the output channels do not have a purpose yet, so their epics records were created but remain inactive for the time being.
I assembled the rack-mount server that will long-term replace c1auxex, so we can return the borrowed unit to Larry.
SUPERMICRO SYS-5017A-EP Specs:
I installed a standard Debian Jessie distribution, with option LXDE for minimal resource usage. Steps taken after fresh install
iface eth0 inet static
dns-nameservers 192.168.113.104 126.96.36.199 188.8.131.52
apt-get install libmotif-common libmotif4 libxp6 (
required to run burtwb utility)
The server is ready to take over for c1auxex2 and does not need any local epics compiled, since it can run the 184.108.40.206_long binaries in /cvs/cds.
I replaced the borrowed server with the permanent one today. Before Removing the current server, Before, I performed several additional preparations:
apt-get install procserv
Then I replaced the server:
I returned c1auxex2 to Larry, who needed it back asap because of some hardware failure
Steve: Acromag XT1221 ordered 3-15-18
The temperature control output channel for the XEND seismometer wasn't working properly. The EPICS channel existed, could be written to and read from, but no physical voltage was observed on the (confirmed properly) wired connector.
The Acromag DAC that outputs this channel was completely spare in the original scheme and does not serve any other channels at the moment. We found it to be unresponsive to ping from the host machine (reminder: the Acromags are on their own subnet with IPs 192.168.114.xxx connected to the secondary ethernet adapter of c1auxex), while all others returned the ping just fine. The modules have daisy-chained ethernet connections, and the one Acromag unit behind the unresponsive one in the chain was still responding to ping and its channels were working, so it couldn't have been a problem with the (ethernet) cabling.
Gautam and I power-cycled the chassis and server, which resolved the issue. The channel is now outputting the requested voltage on the Out1 BNC connector of the chassis (front). When I was setting up the whole system and did frequent rebooting and IP-redefinitions I have seen network issues arise between server and Acromags. In particular, when changing the network settings server-side, the Acromags needed to reboot occasionally. So this whole problem was probably due to the recent server-swap, as the chassis had not been power-cycled since.
During the debugging we also found that the c1psl2 channels were not working. This was because I had overlooked to update the epics environment variables for the modbus path defined in /cvs/cds/caltech/target/c1psl2/npro_config.cmd from the local installation /opt/epics/ (which doesn't exist on the new server anymore) to the network location /cvs/cds/rtapps/epics-220.127.116.11_long/. This has been fixed and the slow diagnostic PSL channels are recording again.
I made a list of all the physical c1psl channels to get a better idea for how many acromags we need to replace it eventually. There 3123 unit is the one whose failure had prevented c1psl from booting, which is why it was unplugged (elog post 12852), and its channels have been inactive since. Are the 126MOPA channels used for the current mephisto? 126 tells me it's for an old lightwave laser, but I was checking a few and found that they have non-zero, changing values, so they may have been rewired.
It also hosts some virtual channels for the ISS with root C1:PSL-ISS_ defined in iss.db and dc.db, the PSL particle counter with root C1:PEM- defined in PCount.db and a whole lot of PSL status channels defined in pslstatus.db. Transfering these virtual channels to a different machine is almost trivial, but the serial readout of the particle counter would have to find a new home.
Long story short - we need:
Using Gautam's Finesse file and the cad files for the 40m optical setup I propagated the arm mode out of the AS port. For the location of the 3.04 mm waist I used the average distance to the ITMs, which is 11.321 m from the beam spot on the 2 inch mirror on the AS table close to the viewport. The 2inch lens focuses the IFO mode to a 82.6 μm waist at a distance of 81 cm, which is what we have to match the aux laser fiber output to.
I profiled the fiber output and obtained a waist of 289.4 μm at a distance of 93.3 cm from the front edge of the base of the fiber mount. Next step is to figure out the lens placement and how to merge the beam paths. We could use a simple mirror if we don't need AS110 and AS55, we could use a polarizing BS and work with s polarization, or we find a Faraday Isolator.
While doing a beam scan with the razor blade method I noticed that the aux laser has significant intensity noise. This is seen on the New Focus 1611 that is used for the beat signal between PSL and aux laser, as well as on the fiber output PD. There is a strong oscillation around 210 kHz. The oscillation frequency decreases when the output power is turned down, the noise eater has no effect. Koji suggested it could be light scattering back into the laser because I couldn't find a usable Faraday Isolator back when I installed the aux laser in the PSL enclosure. I'll have to investigate this a little further, look at the spectrum, etc. This intensity noise will appear as amplitude noise of the beat note, which worries me a little.
In September 2017 I measured ~150mW output power, which was already kind of low. What are the chances of getting this one repaired? Steve, can you please check the serial number? It's probably too old like the other ones.
I suspect that the LD of the aux laser is dying.
- The max power we obtain from this laser (700mW NPRO) is 33mW. Yes, 33mW. (See attachment 1)
Instead of trying to couple the fiber output into the interferometer, I'm doing the reverse and maximize the amount of interferometer light going into the fiber. I set up the mode-matching solution shown in attachment #1 and started tweaking the lens positions. Attachment #2 shows the setup on the AS table. After the initial placement I kept moving the lenses in the green arrow directions and got more and more light into the fiber.
When I stopped this work yesterday I measured 86% of the AS port light coming out the other fiber end, and I have not yet reached a turning point with moving the lenses, so it's possible I can tickle out a little more than that.
It occured to me though that I may have been a little hasty with the placement of the mirror that in attachment #2 redirects the beam which would ordinarily go to AS55. For my arm ringdown measurements this doesn't matter, I could actually place it even before the 50/50 beamsplitter that sends light onto AS110 and double the amount of light going into the IFO. What signals are needed for the Guoy phase measurement? Is AS 110 sufficient, or do we need AS55?
The replacement Acromag we scooped from the West Bridge E-Shop does actually seem to work, although we thought it was broken - at first it was just outputting zeros, but after I did the calibration procedure, applying +10 V and -10 V, respectively, it was reporting voltage correctly, over the full range. I don't know why the factory settings would be messed up, but it had been out of the box before. I did this only with channel 7, so you need to calibrate channels 0-6 and confirm that they indeed also work properly.
I think the root of the problem is that the /opt/rtapps/ and /cvs/cds/rtapps/ mounting locations point to the same directory on the nfs server. Gautam and I were cleaning up the /cvs/cds/caltech/target/ directory, placing the previous contents of /cvs/cds/caltech/target/c1auxex/, including database files and startup instructions in /cvs/cds/caltech/target/c1auxex_oldVME/, and then moved /cvs/cds/caltech/target/c1auxex2/, which has the channel database and initialization files for the Acromac DAQ, to /cvs/cds/caltech/target/c1auxex/.
This also required updating the systemd entries on c1auxex to point to the changed directory. While confirming that everything worked as before we noticed that upon startup the EPICS IOC complains about not being able to find the caRepeater binary. This was not new and has not limited DAQ functionality in the past, but we wanted to fix this, as it seemed to be some simple PATH issue. While the paths are all correctly defined in the user login shell, systemd runs on a lower level and doesn't know about them. One thing we tried was to let systemd execute /cvs/cds/rtapps/epics-18.104.22.168_long/etc/epics-user-env.sh initializing EPICS. It was strange that the content of that file was pointing to /opt/rtapps/epics-22.214.171.124_long/base, which is not mounted on the slow machines, so we changed the /opt/ it to /cvs/cds/, not realizing that the frontends read from the same directory (as Gautam said, /cvs/cds does not exist as a mount point on the frontend). It ended up not working this way, and apparently I forgot to change it back during clean up. But worse, never elogged it!
In the end, we managed to to give systemd the correct path definitions by explicitly calling them out in /cvs/cds/caltech/target/c1auxex/ETMXenv, to which a reference was added in the systemd service file. The caRepeater warning no longer appears.
I was planning to set up the additions to the AS table that are outlined in Attachment #1. Unfortunately the beam is too large for the 2mm clear aperture Faraday rotators that we have available at that position. I checked the 40m and QIL and found 5 Faraday isolators/rotators for 1064 nm total, but none have large enough aperture for the current setup. Some options for buying a larger aperture isolator are:
I wanted to leave the rest of the setup undisturbed at first, but I think a much easier solution would be to move the 2" focusing lens up by about 12", which moves the beam focus away from AS55 to where the Faraday will be placed, but we can re-focus it with another lens. I may have to change the mode-matching for the aux laser fiber slightly to accomodate this change, but if there are no other concerns I would like to start this work tomorrow (Wednesday).
The AUX laser is down to 5.4 mW output power
What's worse, because we wanted those fast switching times by the AOM for ringdowns, I made the beam really small, which
When going though the labs with Koji last week I discovered a stash of modulators in the Crackle lab. Among them there's an 80 MHz AOM with compact driver that had a modulation bandwidth of 30MHz. The fall time with this one should be around 100ns, and since the arm cavities have linewidths of ~10kHz their ringdown times are a few microseconds, so that would be sufficient. I suggest we swap this or a similar one in for the current one, make the beam larger, and redo the fiber modematching. That way we may get ~3mW onto the AS table.
I think I want to use AS110 for the ringdowns, so in the next couple days I'll look into its noise to get a better idea about what power we need for the arm ringdowns.
I brought the NPRO from the Crackle experiment over to the 40m Lab and set it up on the PSL table to replace the slowly dying AUX laser. I also brought along a Faraday isolator, broadband EOM, and an ISOMET AOM with driver electronics from the optics storage in the Crackle Lab.
This laser is a much newer model, made in 2008, and still has all its mojo, but we should probably keep up the practice of turning it off when it's not going to be used for a while. I measured 320 mW leaving the laser, and 299mW of that going through the Faraday isolator, whose Brewster-angle polarizer I had to clean because they were a little dusty. While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted. This is a completely different failure mode from what we've seen with the other NPROs that we can hopefully get repaired at some point, particularly because the laser is newer, but for now it's installed on the PSL table. This likely means that the noise eater isn't working on this unit either, for different reasons, but at least we have plenty of optical power.
The setup is very similar to before, with the addition of a Faraday isolator and a broadband EOM, in case we decide to get more bandwidth in the PLL. I changed the Crystal Technologies 3200-113 200 MHz AOM for an ISOMET 80 MHz AOM with RF driver from the Crackle lab's optics storage and sized the AUX beam to a diameter of 200 micron. I couldn't locate an appropriate heat sink for the driver, which is still in factory condiction, but since the PSL AOM also runs on 80MHz I used that one instead. The two AOMs saturate at different RF powers, so care must be taken to not drive the AUX AOM too high. At 600 mV input to the driver the deflection into the first order was maximal at 73 % of the input power, with the second order beam and the first order on the other side cleary visible.
In order to speed things up I didn't spend too much time on mode-matching, but the advantage of the fiber setup is that we can always improve later if need be without affecting things downstream. I coupled the first order beam into the fiber to the AS table with 58% efficiency, and restored the beat with the PSL laser on the NewFocus 1611. The contrast there is only about 20%, netting a -20 dBm beat note. This is only a marginal improvement from before, so the PLL will work as usual, but if we get the visibility up a little in the future we won't need to amplify the PD signal for the PLL anymore.
Some more things I wanted to do but didn't get to today are
I'll resume this work tomorrow. I turned the aux laser and the AOM driver input off. For the PSL beat the AOM drive is not needed, and the power in the optical fiber should not exceed 100 mW, so the offset voltage to the AOM RF driver has to remain below 300 mV.
> While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted.
NPRO internal power monitor often shows smaller value than the actual due to a broken PD or misalignment. I don't think we need to fix it.
STEVE: Aux Lightwave M126-1064-200, sn259 [July 2009] 1.76A, ADJ 9, 9mW on it's display should not mislead you. It's output 320mW
Among the things that we hadn't taken care of yesterday before beginning to look for transmission signals were the polarization of the AUX beam on the AS table and optimizing the PLL feedback. The AUX beam is s-polarized on the PSL table (choice due to availablility of mirrors), and I added a half waveplate in front of the fiber to match it's axes. I placed another half-waveplate at the fiber output and send the reflection port of a PBS cube onto a PDA1CS photodetector. By alternatingly turning the waveplates I minimized the reflected light, giving strongly p-polarized light on the AS table for best results when interfering with the IFO beam. I wiggled the fiber and found no strong dependency of the output polarization on fiber bending. Attachment 2 shows the current layout.
The beat signal between AUX and PSL table is at -20dBm, and I adjusted the PLL gain and PI-corner to get reliable locking behavior. I think it's a good idea to keep the AUX beam on the AS table blocked while it's not in use, and only unblock it when it is phaselocked to avoid a rogue beam with no fixed phase relation to the PSL in the IFO.I blocked the beam after completing this work today.
I used the signal chain that Keerthana, Koji, and I set up yesterday to look for mode flashed of the AUX light in the YARM using the RF beat with the PSL carrier in transmission. To align the AUX beam to the arm the following steps were performed:
This was followed by a sweep over two full FSRs. Attachment #1 shows the trace recorded by the AG4395 using the max data hold setting during the sweep. Essentially the beat between AUX and PSL carrier traced out the arm's transmission curve. At minimum transmission there was still a ~82dB beat on the transmission PD visible.
The YEND QPD is currently blocked and sees no light.
I went through the wiring of the c1auxex crate today to disentangle the pin assignments. The full detail can be found in attachment #1, #2 has less detail but is more eye candy. The red flagged channels are now marked for removal at the next opportunity. This will free up DAQ channels as follows:
This should be enough for temperature sensing, NPRO diagnostics, and even eventual remote PDH control with new servo boxes.
Bad wording, sorry. Should have been channels in excess of ETMX controls. I'll add the others to the list as well.
Updated channel list and wiring diagram attached. Labels are 'F' for 'Front' and 'R' for - you guessed it - 'Rear', the number identifies the slot panel the breakout is attached to.
[Jon, Gautam, Johannes]
Jon spent some time trying to align the AUX beam to the SRC today, I got to the game kind of late so maybe others can add more detail.
The AUX beam that is reflected by the SRM looks terribly misshapen - it is quite elongated in vertical direction. Unfortunately I didn't snap a picture of it - anybody? It seemed at first as if this could be clipping - but after confirming the alignment of the AUX beam with the PSL output beam with aligned SRM, a slow dither of the SRM just moved the ugly pattern on the AS camera with no change to its shape - so clipping is unlikely. I'm now thinking that this is just the output beam of the fiber coupler after propagating ~15 meters to the SRM and back - even though this aspheric lens triplet coupler is supposed to be super-duper. I found that if I loosen the fiber slightly and pull it back just a bit at least the spot on the AS camera becomes nice and round - so maybe the fiber just doesn't sit well in this collimator? Not sure why that would be. I checked the fiber tip with the microscope, and while there was some gunk present, the central region and the core were clear (still cleaned using the fiber cleaning kit, which got rid of the debris). Either way, before switching to a different collimator I think we should give the Guoy phase measurement a shot - after all there was plenty of RF signal present on both AS110 and the PDA10CF placed at the YEND.
Looking for rogue beams on the AS table, I started placing some beam dumps. There was one particularly strong source of stray beams - a lens that was labeled with KPX094AR.33_F100. It became apparent after alignment efforts to the IFO had moved the AUX beam signifcantly off-center on this lens. According to the label it should have an AR coating for 1064nm, however judging by the amount of reflected light, it was certainly NOT AR-coated for 1064nm. I replaced it with a bi-convex f=100mm lens with confirmed AR-behavior.
The AUX laser is currently shuttered.
Per our Wednesday meeting, some items to work on are
I'm running a comsol job on optimus in a tmux session named cryocavs. Should be done in less than 24 hours, judging by past durations.
Furthermore, I believe we are losing more than 10% of the light due to this BS. The ASDC (which is derived from AS55 PD) level is down at ~110cts as the Michelson is fringing, while it used to be ~200 cts. I will update with a power measurement shortly. But I think we should move ahead with the plan to combine the beam into the IFO's AS mode as discussed at the meeting last week.
Is the 10% specified for P-Pol or for UNP? I contacted CVI about beamsplitters, since their website doesn't list a BS1-1064-90-... option on the website. They say a R=90% beamsplitter would be a custom job. The closest stock item they got is BS1-1064-95-2025-45UNP specified at R=95% for UNPolarized beams. They were kind enough to sent me the measured transmission curves for a recent lot of these, which is attached was uploaded to the wiki [Elog Police K: NO PROPRIETARY DOCUMENTS ON THE ELOG, which is public. Put it on our wiki and put the link here]. The figure is not labeled, but according to the contact Red is S-Pol and Blue is P-Pol, which means that this one actually has R=~90% for P, pretty much what we want. We'll need to buy two of these to make the swap in the setup.
Back to your original point: There's only a BS1-1064-10-2025-45UNP on the website, so unless we got these as custom items, the R for P-Pol is probably NOT actually 10%, just somewhere between 0% and 20%
We did swap a lens as discussed in elog 13968, but they both had f=100mm specified, the difference being one was AR-coated for 1064 and bi-convex, while the other one was plano-convex and had a different coating. The reason for the large beam spot was something else: The fiber wasn't sitting in the coupler properly. When reconnecting the fiber after taking it out make sure to align the key on the fiber end with the notch in the coupler before tightening. After discovering this the following was done:
Before leaving I restored the XARM alignment. SRM remains misaligned, LSC off. Alignment shouldn't change drastically over night, so I suggest when picking this work up tomorrow to directly look for the beats after phaselocking AUX and PSL
At some point we want to change the AUX injection on the AS table to interfere less with the normal interferometer path, and avoid 10/90 beamsplitters which produce a fair amount of ghosting. The plan is to replace the 99/1 BS whose reflection goes to AS110 and AS55, while the transmission goes to the AS camera, with a 90/10 BS as shown in the attachment. This results in ~10% less light on the PDs compared to the pre-AUX era. Between this BS and the AS camera there will be a second 90/10 BS that sends the AUX light into the IFO, so we end up with marginally less AUX power into the IFO and the same PSL power on the AS cam. We're short optics, so this has to wait until two new beamsplitters arrive from CVI.
EDIT: After discussing with Koji and checking the existing M2ISS PDs I put the two C30642G back and took two C30665GH (active diameter: 3mm) diodes. Only one of this type remains in storage.
I removed two C30642G photodiodes from the stash for the new M2ISS hardware and updated the wiki page accordingly.
I expanded the previous panels to 6U height for the new DAQ chassis we're buying for the upgrade. I figure it's best if we stick to the modular design, so I'm showing a panel for 8 BNC connectors as an example. The front panel has 12 slots, the back has 10 plus power connectors, switches, and the ethernet plug.
I moved the power switch to the rear because it's a waste of space to put it in the front, and it's not like we're power cycling this thing all the time. Note that the unit only requires +24V (for general operation, +20V also does the trick, as is the situation for ETMX) and +15V (excitation field for the binary I/O modules). While these could fit into a single CONEC power connector, it's probably for the better if we don't make a version that supplies a large positive voltage where negative is expected, so I put in two CONEC plugs for +/- 15 and +/- 24.
I want to order 5-6 of these as soon as possible, so if anyone wants anything changed or sees a problem, please do tell!