Koji, Steve, and Kevin looked into calibrating the Wilcoxon accelerometers. Once calibrated, the accelerometers will be used to monitor the motion of the PSL table.

We want to use the shaker to shake each accelerometer and monitor the motion with an OSEM. We will make a plate to attach an accelerometer to the shaker. A flag will also be mounted on this plate.The OSEM will be mounted on the table next to the shaker and positioned so that the flag can block the LED light as the plate moves up and down. We will then measure the motion of the accelerometer as it is shaken from the OSEM signal. The OSEM signal will be calibrated by keeping the plate and the flag still and moving the OSEM down along the flag a known distance with a micrometer.

[C1:PEM-ACC_MC1_X]
chnnum=15014
gain = 10

etc.

[Jenne and Koji] 

In order to characterize the seismic vibration of the PSL table, we put the accelerometers on and below the PSL table.

On the PSL: MC2 Accelerometers (X, Y, Z) - being connected to CH1-3 of the preamps
East side of the PSL table. X, Y, and Z is directed to North, East, and Up.

On the ground: MC1 Accelerometers (X, Y, Z) - being connected to CH4-6 of the preamps
Beneath the West side of the PSL table. X, Y, and Z is co-aligned to the MC2 ACC.

I found that the C1:PEM-ACC_MC1_Z has large noise in the low freq (~1Hz) region. I tracked down the noise source
and found the noise is still present in the down stream even when the CH17 (C1:PEM-ACC_MC1_Z) of the ADC IF BNC
(@1Y7) was terminated.

I consulted with Jenne and decided to connect this channel to CH14, which is vacant and has name
C1:PEM-AUDIO_MIC2 (16k).
(for the details of the channel configurations, see /cvs/cds/caltech/chans/daq/C1ADCU_PEM.ini)

I first tried magnetometer channels to steal, but they didn't seem reacting (and the connected to the wrong channels).
I am feeling that we should once entirely check the I/F box.

Note that there looks the difference of the gain by x10 between C1:PEM-ACC_MC* channels and C1:PEM-AUDIO_MIC2.

[From Jenne:  The gain difference is because the C1:PEM-ACC_MC* channels have gain=10 in the .ini file, while C1:PEM-AUDIO_MIC2 uses the default gain=1. ]

Result of the accelerometer measurement

Introduction

We wanted to characterize the PSL table before the work before its lifting up.
We put a set of three-axis Wilcoxon accelerometers on the ground and another set on the PSL table through the weekend.

Result

- The data at 9th Aug 00:00(UTC) is used. This was Sunday 5PM in the local time.
- The freq resolution was 0.01Hz. The # of avg was 50.

- The accelerometer signals were calibrated by the value 1.2e-7 V/(m/s^2). We use this absolute value of the spectrum for the comparison purpose.

- The accelerometers were aligned to North(X), East(Y), and Up(Z). There was the coherence observed from 2~20Hz.
  The transfer functions are valid only this frequency region although we still can set the lower bound of them.

- The transfer functions in the horizontal directions show huge peaks at around 20Hz. The Q of the peaks are ~30 to ~100.
  The vertical transfer function shows somewhat lower peak at around 50Hz with Q of ~10.

Some thoughts

- The low resonant freq and the high Q of the horizontal mode comes from the heaviness of the table.

- We are going to raise the table. This will usually mean that we get the lower resonant freq. This is not nice.

- So, the decision to use 6 tripods rather than 4 was right.
- The steel tripods are expected to give both more rigidity and more damping than the chep-looking hollow Newport legs.
- Concrete grouting of the tripods will also lower the effective height and will benefit for us.

The MC1 accelerometer cube (3 accelerometers arranged in x,y,z) is under the PSL table, as I found it at the beginning of the summer.

The MC2 accelerometer cube is on the table where I worked on the STACIS, right when you walk into the lab from the main entrance. Their cables are dangling near the end of the mode cleaner, so the accelerometers are ready to be placed there if wanted.

All accelerometers are also plugged into their ADC channels.

MC1 accelerometer has been plugged in. The modecleaner locking has been intermittent today, but I looked at a 15 minute lock in DTT, looking at the STS1 seismometer and both accelerometer triplets. Plot and DTT xml attached.

For the sake of not cluttering up everything with legends, the coherence plots are organized by direction (x, y, z), and include the coherence of each of the three sensors (sts, acc1, acc2) with the IMC control signal and the IMC transmitted RIN. 

Some remarks:

• The 1 Hz pendulum motion is about equal amounts of X and Y, which makes sense, as MC1 and 3 are at an angle
• The ~3 Hz stack motion seems to be entirely in the X direction. Why?
• The bounce/roll bands are strongly coherent with Z motion at MC2. 
• The STS does not appear to have any low frequency advantage over the accelerometers, in terms of coherence, contrary to what I would expect even without a thermal enclosure. 
• The control signal and RIN RMSs are clearly dominated by noise in the 1-3Hz band, where we have reasonable coherence. Good prospects for noise subtraction...

The accelerometers have been installed at MC1 and MC2. MC2 data is live, I haven't yet run the cables from the MC1 set to the preamp yet, though. 

Today, I installed the Wilcoxon accelerometers in the table near the end of the mode cleaner. I only set three of them up instead of all six. They were set up just as Rana suggeted we should have them properly set up, i.e. cables being tighten up, and a box on top to prevent any airflow introducing any disturbances. We are planning on running the huddle test on these guys once the upgrade? to the interferometer is done.

The cables were tightly clamped to the table as shown below, I used a thick piece of shock absorbing rubber to do this.

 A small piece of thin rubber was used to hold each of the accelerometers tightly to the table in order not to damage them.

We had to borrow Megan's and Kate's piece of black foam in order to seal one of the sides properly, as the cable had to come out through somewhere. We didn't want to mess with drilling any holes into the box! 

There was a small crack even after using the foam. I sealed it up with duck tape.

The box isn't perfect, so there were multiple cracks along the bottom and top of it that could potentially allow for air to flow to the inside. Eric suggested that we should be super careful this time and do it right, so every crack was sealed up with ducktape.

Finally, we needed something heavy to be placed on top of the box to hold everything well. We used Rana's baby to accomplish this goal.

Just kidding! Rana's baby is too delicate for our purposes. A layman box of heavy cables was used instead. 

Both accelerometers have been moved in an attempt to optimize their positions. The MC1 accelerometer was moved from one green bar to the other (I don't know what to call them) at the base of the MC1 and MC3 chambers. That area is pretty tight, as there is an optical table right there, and I did my best to be careful, but if you suspect something has been knocked loose, you might check in that area. The MC2 accelerometer was moved from the horizontal bar down to the metal table on which the MC2 chamber rests.

[Sanjit, Jenne]

The set of 6 accelerometers which were semi-randomly placed underneath the MC2 tank are now back into 2 separate sets of 3 - one set at MC2 and one set at MC1.  The channel names once again reflect reality, i.e. MC1_Y is actually under the MC1 tank, and aligned with the y direction.  Also, the Guralp under MC1 was moved a little bit to the left, because Sanjit wanted to put the accelerometers where the seismometer had been. 

Some of these channels are not like the others.

[Steve, Bob, Jamie, Kiwamu, Valera, Jenne]

The access connector is now in place, in preparation for pump-down.  Tomorrow (hopefully) we will do all the other doors.

[Jenne, Koji]

I was trying to lock the Yarm, and saw that I was not getting signals to go between the LSC and SCY models.  I had digital zeros for TRY, and when I overrode the trigger and tried to force signal to ETMY, I had digital zeros at the SUS-ETMY_LSC input. The corresponding filter bank in the rfm model was receiving signals, so the Dolphin connection between LSC and SUS was okay, it was just the RFM connection going to the end station that wasn't succeeding. 

Koji restarted the c1scy model, and then went inside the IFO room, and found that the SUS IO chassis power was off.  We must have accidentally turned it off while we were in there earlier.  Koji turned on the power, and also restarted the rfm model, and we now have real signals going back and forth. 

Yarm is locked, ASS worked nicely, etc, etc, so things seem normal again (with the Yarm....ETMX stuff is still out of order).

We need ADC and DAC channels for a couple of things:

• POP QPD: 3x ADC
• ALS PZTs: 3x 2x 2x DAC (three pairs of PZTs, at ends and vertex, each with two channels for pitch and yaw)
• Fibox: 1x DAC

What's being used:

• c1iscex/c1iscey:
  
  • DAC_0:   7/16 = 9 free
  • ADC_0: 17/32 = 15 free
• c1sus:
  
  • DAC: ?
  • ADC: ?
• c1ioo
  
  • DAC_0:   0/16 = 16 free ?? This one is weird. DAC in IO chassis, half it's channels connected to cross connect (going ???), but no model links to it
  • ADC_0: 23/32 = 9 free
  • ADC_1:  8/32 = 24 free
• c1lsc
  
  • DAC_0: 16/26 = 0 free
  • ADC_0: 32/32 = 0 free

What this means:

• We definitely have enough DACs for the ALS PZTs.  The free channels are also in the right places: at the end stations and in the c1ioo FE, which is close to the PSL and hosts the c1als controller.
• We appear to have enough ADCs for the QPD in c1ioo.
• We don't have any available DAC outputs in c1lsc for the Fibox.  If we can move the Fibox to the IOO racks (1X1, 1X2) then we could send LSC channels to c1ioo and use c1ioo's extra DAC channels.

Of course we'll have to investigate the AA/AI situation as well.  I'll try to asses that in a follow up post.

PS: this helps to identify used ADC channels in models:

grep adc_ sus/c1/models/c1scx.mdl | grep Name | awk '{print $2}' | sort | uniq

1. What are we using 16 DAC channels for in the LSC?
2. What are the functions of those IOO DAC channels which go to cross-connects? If they're not properly sending, then we may have malfunctioning MC or MCWFS.
3. Can we just use the SLOW DAC (4116) for the ALS PZTs? We used this for a long time for the input steering and it was OK (but not perfect).

For the new input and output tip-tilts.  Two input, two output, each requires four channels.

I have no idea.  I don't know what the hardware is, or is supposed to be, connected to.  DAC for WFS??  Was there at some point supposed to be fast output channels in the PSL?

 Probably. I'm not as familiar with that system.  I don't know what the availability of hardware channels is there.  I'll investigate tomorrow.

Looking back at elog 12528, the uncertainty in the armloss number from the individual quantities in the equation for can be written as:

Making some generous assumption about the individual uncertainties and filling in typical values we get in our measurements, results in the following uncertainty budget:

In my recent round of measurements I had a 2.5% uncertainty in the ASDC reading, which completely dominates the armloss assessment.

The most recent numbers are 57 ppm for the YARM and 21 ppm for the XARM, but both with an uncertainty of near 150 ppm, so while these numbers fit well with Gautam's estimate of the average armloss via PRG, it's not really a confirmation.

I set the whitening gain in ASDC to 24 dB and ran LSC offsets, and now I'm getting a relative uncertainty in measured reflected power of .22%, which would be sufficient for ~25ppm accuracy according to the above formula. I'm going to start a series of measurements tonight when I leave, should be done in ~2 hours (10 pm) the latest.

If anybody wants to do some night work: I misaligned ITMY by a lot to get its reflection off ASDC. Approximate values are saved as a restore point. Also the whitening gain on ASDC will have to be rolled back (was at 0dB) and LSC offsets adjusted.

I had a mistake in my script that reported the wrong error after averaging several datapoints, and because I hadn't looked at the individual numbers I didn't catch it so far. Thanks to Gautam it is no more.

The updated numbers are (with fresh, more trustworthy data):

XARM: 21 +/ 35 ppm
YARM: 69 +/- 45 ppm

This looks much better. I'm planning to take more data with the AS110 PD rather than AS55 when I get the chance, increase the averaging time, and also sigma filter the datapoints. That should get us to a good spot and cut down the uncertainty even further.

I don't like AS110 or AS55. Neither of them are designed for DC and so the DC readout chain is hokey. How about use an actual transimpedance PD with a 100-1000 Ohm resistor and a 3 mm diode? This would eliminate the alignment sensitivity and the drifts due to electronics and room lights.

My box has been suspended in the PSL using surgical tubing, and it has been connected to C1:PEM-MIC_1 (C17) with a BNC. I made a braided power cable as well but it turned out to be slightly too short... Once this is fixed, everything should be ready and we can see if it's working correctly. I also set up a new tab on the summary pages for this channel:

https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1154941217-1154942117/pem/acoustic/

This data is back from when I had my solderless breadboard running near MC2. I'll add this tab to the real pages once the box is working (which could be a while since I'm gone for a month). Let me know if you see any issues with either the tab or the box/cables.

1. add photo of installation
2. no more secret personal pages! put channels into the actual pages that we look at
3. make it ASD instead of PSD, same as the other channels
4. add specgram (whitened and not)

I'll add a picture of the installation when I get back to campus and finish hooking up the power cable. I haven't added this channel to the actual pages yet because there's not any data right now- the box is still unpowered because my braided power cable wasn't long enough. I just changed the format of the spectrum to ASD and added spectrograms. Here's how the tab looks now: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1155014117-1155015017/pem/acoustic/

Let me know if there's anything else to change.

 In order to perform acoustic noise cancellation with MCL signal, I am trying to find sweet spots for microphones.

I set microphones at various places around MC chambers, and see how coherent microphones and MC signals are.
I had checked the half part of MC.

• data set #1
  place where I set the microphones (left), MCL signal (blue) and its error (green) (right top), and coherence between microphones (original: fine lines, error: thick lines) (right bottom).
  
• data set #2
   
•  data set #3
  
• data set #4
  

The acoustic noise around the MC2 chamber is most critical so far. I could subtract the signal and the sensitivity got 2 times better.
I will see the acoustic coupling from the other side of MC.

[Koji, Ayaka]

Last night, I injected acoustic noise at POX table and AS table with oplev controls on (LPF is on).

1. acoustic noise at the POX table

I set the microphones and speakers at the POX table and see the acoustic coupling.

I could see slight change around 40 Hz. This can be caused by the oplev feedback loop because the speaker was on the same table as the ITMX oplev.

2. acoustic noise at the AS table

I controlled XARM with AS error signal and set the microphones and speaker on the AS table.

The resonance a 200 Hz seemed to be enhanced. But still we are not sure that it is caused by acoustic noise. Because this resonance is enhanced when the OL gain is high, and the gain adjustment was so critical that this resonance was easily enhanced even when the acoustic noise is not injected. And sometimes it has gone away.

I looked into converting the QPD whitening switches for the X end to Acromag.

• To test this out and be able to freely toggle filters without messing anything up, I added a temporary dummy cdsFiltCtrl module (ACROMAG_BIO_TEST) to the c1scx model.
• The filters can be toggled from the automatically generated medm screen medm/c1scx/C1SCX_ACROMAG_BIO_TEST.adl
• The control output of the dummy filter bank is sent to a channel named C1:SCX-ACROMAG_SWCTRL.
• I was able to read in the appropriate bits from there and send them to the appropriate acromag channel using a calcout channel.
  • I couldn't get individual bo channels to work. This Acromag module is configured to write to 4 channels at a time, so I set that up with an analog output channel. The calcout channel shifts each relevant bit from C1:SCX-ACROMAG_SWCTRL to the right place for writing to the Acromag. 
• I connected the Acromag XT1111 Binary I/O unit to a temporary power supply and verified that toggling the filters on and off changed the output appropriately. This is a sinking output model so the output pin is connected to the return if the switch is on. 

The plan from here:

• Determine how to configure these outputs to be compatible with the QPD whitening board.
• Modify the SUS PD whitening board to always use the analog filter and remove digital option in models.
• Test DACs 
• Verify that the QPD whitening gain switches aren't doing anything
• Assemble new Acromag box for X end and connect to QPD whitening, SUS PD whitening and SOS driver boards

Current Acromag chassis status:

I found out that Acromag offers DIN rail mounting kits for the open boards, so we can actually fit both XT series and ES/EN series in the same boxes, depending on the signal needs. The primary design driver will be the ES footprint, but if we find we don't need that many channels in some of the units, it's interchangable. For the wiring to the front panel - for which we will have a standard front panel express design, but may order modified ones for the custom needs of the 40m, I will contract the same company that Rich used for the wiring in his DIO box (Panel mount connectors terminating in loose wires/pre-routed plugs for Acromag units). We will either run a single DIN rail along the length of the chassis, or have two in parallel across.

Lydia and I took close looks at the breakout arrangements on the rack sides, and determined that because of the many cross-connects between non-DAQ ports it is not possible to redo and debug this in a reasonable amount of time without essentially shutting down the interferometer. So instead, we will connect the chassis directly to the slots that were previously leading to the slow machines. They come in two different flavors: The ADC modules have 64 pins, while the DIO and DAC ones have 50. There are a couple things we can do:

• For ADC: Put favorite 64+ pin connector on front panel. I would advocate for the 68 pin VHDIC (SCSI-5). This standard ist widely used, has a sturdy connector, and usually off-the-shelf cables have twisted pair leads.
• For DAC+DIO: Either use favorite 50 pin connector (there are 50-pin DSUB connectors, and also 50-pin IDC connectors with backshell), or also send the signals through VHDIC connectors, tolerating a few unused lanes. I would prefer the second option, after all it all goes to some 64 pin VME-crate backplane connector in the end, so if we ever get rid of the rack-side breakouts the wiring will much more uniform.
• For good measure, we will add a few (16 maybe) BNC connectors to the front panel.
• A standardized front panel could have a variety of different connectors by default: DSUBs, BNCs, etc., to be used when needed with some initial default wiring.
• Note that THEORETICALLY we could even connect all backplane EUROCARD ports to the Acromag chassis and do the cross-connect wiring entirely inside, although that would make the inside extremely messy.

Based on Rich's design I will get started on a parts list and wiring diagrams to send out to the cable company.

I had Rich show me his approach to a chassis for the Acromag modules. The document tree for his design can be found on the DCC. Note that he's using the high densitymodel ES series, which is available as a bare board variant with pluggable screw terminals:

He can fit up to 4 of these in a 2U chassis and has outsourced the wiring from front panel Dsubs to the board connectors to an external company. At the 40m (and in West Bridge) we currently only have the rail mounted XT series

At first glance the specs are very similar. Both A/D and D/A flavors have 16-bit precision in both cases. The high density ES series with Rich's layout can achieve 128 A/D per 2U, 64 D/A per 2U, or 384 DIO per 2U. Into a 4U chassis of the type we have currently we can fit ~32 XT modules (assuming two rows), which results in very similar numbers, except for the DAC, of which we could fit more.

XT1221-000 (8 diff. channel 16-bit ADC)                          $495.00      $61.88/ch
XT1541-000 (8 channel 16-bit DAC and 4 discrete I/O )    $525.00      $65.63/ch
XT1120-000 (16 channel DIO)                                         $320.00     $20.00/ch

ES2162-0010 (32 diff. channel 16-bit ADC)                     $2050.00    $64.06/ch
ES2172-0010 (16 channel 16-bit DAC)                           $1400.00    $87.50/ch
ES2113-0010 (96 channel DIO)                                      $1100.00    $11.46/ch

It's cheaper to stick with the current XT models, but they need the bulkier 4U chassis. The good news is that actually all these models have 16 bit precision, which wasn't clear to me before. Lydia and I will work out what connectors we want on the boxes, and how many modules/channels we need where. Rich also got me in touch with Keith Thorne, who handles the analog I/O Acromag at LLO, and I will ask him for advice. From his documents on the DCC it seems that he is using yet another series: EN. The 968EN-4008 for example is a rail-mounted ADC with pluggable connections, but looses quite clearly in price per channel.

For a generic multipurpose DAQ interface box the ES series is the best approach in my opinion, because it offers a more compact design. We could for example fit 1 ADC, 2 DAC, 1 DIO in a 2U chassis for 32/32/96 channels. The combined price tag for this scenario would be ~$6k.

[Teng, Lydia]

We would like to establish a system for setting up ADC channels and integrating them into the existing EPICS framework, so that we can gradually switch over channels that are currently handled by the aging slow machines. Otherwise, we will be stuck when they eventually fail. As a preliminary test for this method, we are in the process of setting up an Acromag ADC to read the "Diagnostic" output of the PSL controller. This information will also be useful to monitor the health of the PSL. 

Today, we accomplished the following:

• Configured the Acromag XT1221 for use on the martian netowrk. It is assigned the static IP 192.168.113.237, with hostname iocPSLmon. 
• Connected the Acromag to a switch on the 1X6 cabinet, and set it up on a desk near the X arm door with a 24V DC power supply. 
• Verified that the IP was reachable from a control room desktop. 
• Modified the files from Aiden's wiki page (myiocconfig.cmd and IOCTEST.db) to reflect our setup. 
• Attached input 0 to a DC voltage and retrieved the output over the network. 
  • Channel name: "C3:ACROMAG_INPUT0" 
  • Values are currently uncalibrated, the voltage is represented by a 16 bit signed integer
  • We changed the value of the DC input and verified that the channel output changed in the expected direction

The power supply has been turned off for the night. 

We moved the Acromag and its power supply to the X end, where we connected it to the diagnostic output of the NPRO controller. We renamed the channels to be descriptive of the pin outputs as described in the laser manual. We were able to recover readouts similar to those we found with a multimeter. 

We should figure out how to set up the channels on the front end machines: right now they are accessed through a tmux session running on pianosa. Once we are confident in the operation, we will make a box to contain the Acromag and wire connections and move the setup to connect to the PSL controller. 

[Lydia, Johannes]

Johannes acquired a crate to contain the Acromag setup and wiring, and installed a rail along the bottom panel so that the ADC units will be oriented vertically with the ehternet ports facing up. We briefly talkes about what the layout should be, and are thinking of using 2 rails, one for ADCs and one for DACs. We want to design a generic front panel to accept 25 pin D-Sub inputs and maybe also BNCs, which we can use for all the Acromag crates. 

I got the epics session for the acromag to run on c1iscex and was able to access the channel values using caget on donatella. However, I get the following warning: 

cas warning: Using dynamically assigned TCP port 48154,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)

It seems like there might be a way to assign a port for each unit, if this is a problem. 

Also, c1iscex doens't have tmux; what's the best way to run the modbusApp and then detach? Right now I just left an epics session running in an open terminal. 

Plans:

• Deisgn crate connections and interior layout. Set up front panel to accept desired connections. 
• Set up the crate with the Acromag XT1221 reading the diagnostic info from the X end NPRO in the X end rack.
• Figure out how many of each type we need to replace c1auxex functionality, and order them.
• Generate appropriate EPICS db files for acromag based on slow machine channels.
• Add necessary units to X end Acromag crate and read in the same inputs as c1auxex. 
• Set up everything else to look for c1auxex channels from Acromag instead. (Not sure about nuances of this step: should we name the channels something different at first? How to find everything that relies on c1auxex? Must be careful with SUS channel connections.)
•  Determine number of units needed to replace all slow machines, and order thm. Likewise assemble as many crates as necessary with the right connections. 
• Once we are confident that the replacement is complete and fully functional, disconnect c1auxex and repeat process for other slow machines. 

Aidan has described the physical connections and initial setup here :  https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:resources:computing:acromag#recovering_from_a_terminal_power_communication_outage  .

Since I used a Raspberry Pi(domenica.martian) for communicating to Acromag(acroey.martian) card, I had to recompile everything for linux-arm architecture. 

For EPICS installation, download the EPICS base from http://www.aps.anl.gov/epics/download/base/baseR3.14.12.3.tar.gz . Installing dependencies, build, install epics at /usr/local/epics. By downloading modbusApp source from https://llocds.ligo-la.caltech.edu/daq/software/source/epics-3.14.12.2_long-source.tar.gz  , build the modbusApp for linux-arm architecture in modules/modbus directory inside epics base.

Put all the files mentioned by Aidan and run a tmux session to grab channels.

Also, pyModbus can be used to read the channels. I'll put the physical connections schematic shortly.

There were many unknown and unsolved problems with using modbusApp for linux-arm architecture. So I tried to install the necessary files to setup Acromag Busworks card 1221-000 on Zita(192.168.113.217), which is a linux-x86_64 machine on the martian network. After installing a few dependencies and seting up few symbolic links for some libraries, everything is successfully configured. Initially I was unable to run myiocconfig.cmd file(as mentioned by Aiden on ATF wiki page) due to a undefined macro error for envset. Later I found that this error might be due to THIS bug in epics base. So, I removed the first four lines of that given code and directly referenced the .db file's location and it worked.

Now, I am facing another issue while running this file but on different line. Random symbols are returned on the last second line of the file each time I run it. I have attached the screenshots of those errors. I tried changing the encoding of the file several times but still it is showing the same error.

Lydia helped me to troubleshoot the Accromag connection problems which I was facing previously.  If power goes off/turned off manually, the ethernet cable has to be pulled out and put back again until only a non-blinking green light is observed. I was foolish enough that I did not use secure power connections. About the random symbol, a code block was not closed in the other supporting file which was being called in the main program. There are still some port errors and register errors, which I would work on later tonight.

Actually, if the power goes off and back on, the ethernet connection comes back online after about 5 seconds, or faster if it is disconnected and reconnected. The main issue was that the cable had partially slipped out (ie both power and network connections were loose); I suggest that the final setup should use ethernet cables that have a locking tab as this one does not. 

I wired up the power distribution, and ethernet cables in the Acromag chassis today. For the time being it's all kind of loose in there but tomorrow the last parts should arrive from McMaster to put everything in its place. I had to unplug some of the wiring that Aaron had already done but labeled everything before I did so. I finalized the IP configuration via USB for all the units, which are now powered through the chassis and active on the network.

I started transcribing the database file ETMXaux.db that is loaded by c1auxex in the format required by the Acromags and made sure that the new c1auxex2 properly functions as a server, which it does.

ToDo-list:

• Need to calibrate the +/- 10V swing of the analog channels via the USB utility, but that requires wiring the channels to the connectors and should probably be done once the unit sits in the rack
• Need to wire power from the Sorensens into the chassis. There are +/- 5V, +/- 15V and +/- 20V present. The Acromags need only +12V-32V, for which I plan to use the +20V, and an excitation voltage for the binary channels, for which I'm going to wire the +5V. Should do this through the fuse rails on the side.
• The current slow binary channels are sinking outputs, same as the XT1111 16-channel module we have. The additional 4 binary outputs of the XT1541 are sourcing, and I'm currently not sure if we can use them with the sos driver and whitening vme boards that get their binary control signals from the slow system.
• Confirm switching of binary channels (haven't used model XT1111 before, but I assume the definitions are identical to XT1121)
• Setup remaining essential EPICS channels and confirm that dimensions are the same (as in both give the same voltage for the same requested value)
• Disconnect DIN cables, attach adapter boards + DSUB cables
• Testing

Getting the chassis ready took a little longer than anticipated, mostly because I had not looked into the channel list myself before and forgot about Lydia's post which mentions that some of the switching controls have to be moved from the fast to the slow DAQ. We would need a total of 5+5+4+8=22 binary outputs. With the existing Acromag units we have 16 sinking outputs and 8 sourcing outputs. I looked through all the Eurocrate modules and confirmed that they all use the same switch topology which has sourcing inputs.

While one can use a pull-down resistor to control a sourcing input with a sourcing output,

pulling down the MAX333A input (datasheet says logic low is <0.8V) requires something like 100 Ohms for the pull down resistor, which would require ~150mA of current PER CHANNEL, which is unreasonable. Instead, I asked Steve to buy a second XT1111 and modified the chassis to accomodate more Acromag units.

I have now finished wiring the chassis (except for 8 remaining bypass controls to the whitening board which need the second XT1111), calibrated all channels in use, confirmed all pin locations via the existing breakout boards and DCC drawings for the eurocrate modules, and today Steve and I added more fuses to the DIN rail power distribution for +20V and +15V.

There was not enough contingent free space in the XEND rack to mount the chassis, so for now I placed it next to it.

c1auxex2 is currently hosting all original physical c1auxex channels (not yet calc records) under their original name with an _XT added at the end to avoid duplicate channel names. c1auxex is still in control of ETMX. All EPICS channels hosted by c1auxex2 are in dimensions of Volts. The plan for tomorrow is to take c1auxex off the grid, rename the c1auxex2 hosted channels and transfer ETMX controls to it, provided we can find enough 37pin DSub cables (8). I made 5 adapter boards for the 5 Eurocrate modules that need to talk to the slow DAQ through their backplane connector.

The Auxiliary DAQ Chassis, or Acromag box, is now wired and ready for testing.  I will be sorting the cables at the vacuum rack to make connection to the box easier.

1. I take back what I said about the OSEM PD mon at the meeting - there does seem to be to be some overall calibration factor (Attachment #1) that has scaled the OSEM PD readback channels, by a factor of (20000/2^15), which Johannes informs me is some strange feature of the ADC, which he will explain in a subsequent post.
2. The coil redback fields on the MEDM screen have a "30Hz HPF" text field below them - I believe this is misleading. Judging by the schematic, we are monitoring, on the backplane (which is what these channels are reading back from), the coil to the voltage with a gain of 0.5. We can reconfirm by checking the ETMX coil driver board, after which we should remove the misleading label on the MEDM screens.