40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 23 of 341 Not logged in
ID Date Author Type Category Subject
8580   Wed May 15 17:17:05 2013 JamieSummaryCDSAccounting of ADC/DAC channel availability

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

• 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: ?
• 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  8583 Wed May 15 19:32:04 2013 ranaSummaryCDSAccounting of ADC/DAC channel availability 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). 8585 Wed May 15 22:47:11 2013 JamieSummaryCDSAccounting of ADC/DAC channel availability  Quote: What are we using 16 DAC channels for in the LSC? For the new input and output tip-tilts. Two input, two output, each requires four channels.  Quote: 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. 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?  Quote: 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). 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. 12614 Mon Nov 14 19:15:57 2016 JohannesUpdateGeneralAchievable armloss measurement accuracy Looking back at elog 12528, the uncertainty in the armloss number from the individual quantities in the equation for $\mathcal{L}$ can be written as: $\delta\mathcal{L}^2=\left(\frac{T_1(1-\frac{P_L}{P_M}-2T_1)}{4\gamma}\right)^2\left(\frac{\delta T_1}{T_1}\right)^2+T_2^2\left(\frac{\delta T_2}{T_2}\right)^2+\left(\frac{T_1(1-\frac{P_L}{P_M}-T_1)}{4\gamma}\right)^2\left(\frac{\delta\gamma}{\gamma}\right )^2+\left(\frac{T_1}{4\gamma}\right )^2\left[\left(\frac{\delta P_L}{P_L}\right )^2+\left(\frac{P_L}{P_M} \right )^2\left(\frac{\delta P_M}{P_M}\right )^2\right ]$ Making some generous assumption about the individual uncertainties and filling in typical values we get in our measurements, results in the following uncertainty budget: $\delta\mathcal{L}^2\approx\left(12\,\mathrm{ppm}\right)^2\left(\frac{\delta T_1/T_1}{5\%}\right)^2+(0.7\,\mathrm{ppm})^2\left(\frac{\delta T_2/T_2}{5\%}\right)^2+\left(2\,\mathrm{ppm}\right)^2\left(\frac{\delta\gamma/\gamma}{1\%}\right )^2+\left(140\,\mathrm{ppm}\right )^2\left(\frac{\delta P/P}{2.5\%}\right )^2$ 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. 12618 Tue Nov 15 20:35:19 2016 JohannesUpdateGeneralAchievable armloss measurement accuracy 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. 12624 Thu Nov 17 21:54:11 2016 JohannesUpdateGeneralAchievable armloss measurement accuracy 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.  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. 12442 Thu Aug 25 19:03:56 2016 PrafulUpdateElectronicsAcoustic Tab and Amp Suspension 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. 12460 Thu Sep 1 15:28:01 2016 ranaUpdateElectronicsAcoustic Tab and Amp Suspension 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)  Quote: 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. 12463 Thu Sep 1 17:25:02 2016 PrafulUpdateElectronicsAcoustic Tab and Amp Suspension 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. Quote: 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)  Quote: 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. 7707 Tue Nov 13 21:05:22 2012 AyakaUpdateWienerFilteringAcoustic noise cancellation with MC 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. Attachment 4: psd_coh.png 7814 Wed Dec 12 11:49:05 2012 AyakaUpdateLSCAcoustic noise in POX and AS error signal [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. 12677 Wed Dec 14 19:16:57 2016 LydiaUpdateCDSAcromag Binary I/O testing 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 12634 Tue Nov 22 13:55:32 2016 JohannesOmnistructure40m upgradingAcromag Chassis 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. Attachment 1: acroplan.pdf 12625 Fri Nov 18 00:25:08 2016 JohannesOmnistructure40m upgradingAcromag Chassis Development 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.

12477   Wed Sep 7 18:00:47 2016 LydiaUpdateGeneralAcromag Progress

[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.

12514   Thu Sep 22 20:18:27 2016 LydiaUpdateGeneralAcromag Progress

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.

12554   Wed Oct 12 18:09:25 2016 LydiaUpdateGeneralAcromag Progress

[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.
12306   Fri Jul 15 17:44:37 2016 AakashSummaryGeneralAcromag Setup | SURF2016

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.

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.

12360   Mon Aug 1 18:50:29 2016 AakashUpdateGeneralAcromag Setup | SURF2016

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.

Attachment 1: 1.png
Attachment 2: 2.png
Attachment 3: 3.png
Attachment 4: 5.png
Attachment 5: 6.png
Attachment 6: 7.png
Attachment 7: 8.png
12366   Wed Aug 3 15:35:19 2016 AakashUpdateGeneralAcromag Setup | SURF2016

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.

12368   Wed Aug 3 16:34:59 2016 LydiaUpdateGeneralAcromag Setup | SURF2016

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.

 Quote: 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.

13463   Mon Dec 4 22:06:07 2017 johannesOmnistructureComputersAcromag XEND progress

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

Quote:

[Aaron, Johannes]

We configured the AtomServer for the Martian network today. Hostname is c1auxex2, IP is 192.168.113.49. Remote access over SSH is enabled.

There will be 6 acromag units served by c1auxex2.

 Hostname Type IP Address c1auxex-xt1221a 1221 192.168.113.130 c1auxex-xt1221b 1221 192.168.113.131 c1auxex-xt1221c 1221 192.168.113.132 c1auxex-xt1541a 1541 192.168.113.133 c1auxex-xt1541b 1541 192.168.113.134 c1auxex-xt1111a 1111 192.168.113.135

Some hardware to assemble the Acromag box and adapter PCBs are still missing, and the wiring and channel definitions have to be finalized. The port driver initialization instructions and channel definitions are currently locally stored in /home/controls/modbusIOC/ but will eventually be migrated to a shared location, but we need to decide how exactly we want to set up this infrastructure.

• Should the new machines have the same hostnames as the ones they're replacing? For the transition we simply named it c1auxex2.
• Because the communication of the server machine with the DAQ modules is happening over TCP/IP and not some VME backplane bus we could consolidate machines, particularly in the vertex area.
• It would be good to use the fact that these SuperMicro servers have 2+ ethernet ports to separate CDS EPICS traffic from the modbus traffic. That would also keep the 30+ IPs for the Acromag thingies off the Martian host tables.
13468   Thu Dec 7 22:24:04 2017 johannesOmnistructureComputersAcromag XEND progress

 Quote: 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.

14364   Tue Dec 18 11:42:40 2018 ChubUpdateGeneralAcromag box wired

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.

13553   Wed Jan 17 14:32:51 2018 gautamUpdateDAQAcromag checks
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.
 Quote: Some suggestions of checks to run, based on the rightmost colum in the wiring diagram here - I guess some of these have been done already, just noting them here so that results can be posted. Oplev quadrant slow readouts should match their fast DAQ counterparts. Confirm that EX Transmon QPD whitening/gain switching are working as expected, and that quadrant spectra have the correct shape. Watchdog tripping under different conditions. Coil driver slow readbacks make sense - we should also confirm which of the slow readbacks we are monitoring (there are multiple on the SOS coil driver board) and update the MEDM screen accordingly. Confirm that shadow sensor PD whitening is working by looking at spectra. Confirm de-whitening switching capability - both to engage and disengage - maybe the procedure here can be repeated. Monitor DC alignment of ETMX - we've seen the optic wander around (as judged by the Oplev QPD spot position) while sitting in the control room, would be useful to rule out that this is because of the DC bias voltage stability (it probably isn't). Confirm that burt snapshot recording is working as expected - this is not just for c1auxex, but for all channels, since, as Johannes pointed out, the 2018 directory was totally missing and hence no snapshots were being made. Confirm that systemd restarts IOC processes when the machine currently called c1auxex2 gets restarted for whatever reason.

Attachment 1: OSEMPDmon_Acro.png
13554   Wed Jan 17 22:44:14 2018 johannesUpdateDAQAcromag checks

This happened because there are multiple ways to scale the raw value of an EPICS channel to the desired output range. In the CryoLab I was using one way, but the EPICS records I copied from c1auxex were doing it differently. Basically this:

 DTYP - Data type - LINR "NO CONVERSION" vs "LINEAR" RVAL Raw value EGUF Engineering units full scale EGUL Engineering units low ASLO Manual scaling factor AOFF Manual offset VAL Value

If the "LINR" field is set to "LINEAR", the fields EGUF and EGUL are used to convert the raw value to the channel value VAL. To use them, one needs to enter the voltages that return the maximum and minimum values expected for the given data type. It used to be +10V and -10V, respectively, and was copied that way but that doesn't work with the data type required for the Acromag units. For -some- reason, while the the ADC range is -10V to +10V, this corresponds to values -20000 to +20000, while for the DAC channels it's -30000 to +30000. I had observed this before when setting up the DAQ in the CryoLab, but there we were using "NO CONVERSION", which skips the EGUF and EGUL fields, and used the ASLO and AOFF for manual scaling to get it right. When I mixed the records from there with the old ones from c1auxex this got lost in translation. Gautam and I confirmed by eye that this indeed explains the different levels well. This means that the VMon channelsfor the coils are also showing the wrong voltages, which will be corrected, but the readback still definitely works and confirms that the enable switches do their job.

 Quote: 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.

13565   Sun Jan 21 13:11:25 2018 johannesUpdateDAQAcromag checks

After some research: -the- reason for the reduced +/- 20,000 swing in raw values is a default setting for having support for legacy devices enabled when using the acromag proprietary i2o peer-to-peer protocol. So this is doubly unnecessary because a) we don't have any legacy devices at all and b) we're using pure modbus/TCP and no i2o. To change the setting I have to connect via the USB configuration utility. In addition, I want to understand the averaging feature of the acromag units better, which is also configured via USB, and lets one set a fixed amount of samples to be averaged before updating the read-register value. The documentation says that the 8 channels are multiplexed into a single ADC, and that new input data is available after 10 ms for each channel, suggesting a sampling rate of 100 Hz per channel and that the multiplexing happens faster, but is not super-clear about this, so I want to test it in the cryo lab first before unleashing it onto c1auxex2.

Furthermore, the standard timing options for updating epics records are 10s, 5s, 2s, 1s, 0.5s, 0,2s, and 0.1s. On the previous c1auxex, the monitoring channels were set to 0.1s, but that clashes with the 16 Hz global EPICS rate, resulting in partial double-sampling. One can manually provide the option 0.0625s for 16Hz update rate. I will test this and how it deals with the averaging in the cryolab too.

14718   Tue Jul 2 12:30:53 2019 gautamUpdateElectronicsAcromag crate switched to Sorensens

[chub, gautam]

We crossed off another couple of bullets today.

It took me ~1 hour to realize that c1susaux requries the running of sudo /sbin/ifup eth0 to be run in order to see the martian network - why???

Activity:

1. Stopped the c1susaux machine:
• Moved alignment sliders of ITMX and ITMY to 0 as a precaution.
• Shutdown the c1susaux machine so that it doesn't become unhappy with the missing Acromags when we power the unit down.
2. Dialled down supply voltages on the +/- 15 V and +/- 20 V DC Sorensens. Current draw became 0 A on the front panel indicators.
3. Chub tapped some new terminal blocks for +15 V DC and +20 V DC
• This required some additional daisy chaining, which is why we dialled down the Sorensens.
• New cables were made using the "standard" LIGO color scheme, which isn't really applicable in this case because we are using +15 V DC (orange sheath wire) and + 20 V DC (yellow sheath wire) whereas the closest LIGO standard voltages are +18 V DC and +24 V DC.
• A test cable, presumably meant to be used in the electronics area (orange for +15 V DC) was destroyed for this work as we opted for speed rather than making a new cable.
4. Disconnected bench power supplies that were powering the Acromags, and connected the new cables.
• I opted to use 5 A fuses in the terminal blocks for these supplies as the current draw is pretty significant.
5. Dialled the Sorensens back up to the nominal voltages:
• Attachment #1 shows the front panels of the Sorensens before and after this work.
• The current limit on the +20 V DC Sorensen had to be raised, because the Acromag box draws ~2.3 A on its own, whereas the previous current draw was 2.8 A.
6. Brought the c1susaux machine back online. Took me a while to get to the bottom of why I wasn't able to see c1susaux on the martian, but eventually, I figured out the whole sbin/ifup thingy.

I don't understand the exact chain of causation, but during this work, the fast c1sus model crashed. I had to go through a few iterations of the scripted vertex machine rebooting, but things seem to be back in a normal state now, see Attachment #2. Should probably run the IFO test suite to make sure everything is a-okay, but for now, I am able to lock the IMC so I'm moving on.

The main task remaining here is to take new pictures of everything and upload to the wiki. Also, need to update the Sorensen labels to reflect their current values, some of them are outdated.

 Quote: Take photos of the new setup, cabling. Remove the old c1susaux crate from the rack to free up space, possibly put the PSL monitoring acromag chassis there. Test that the OSEM PD whitening switching is working for all 8 vertex optics.(verified as of 5/3/19 5pm) New 15V and 24V power cables with standard LIGO connectors need to be run from the Sorensenn supplies in 1X5. The chassis is currently powered by bench supplies sitting on a cart behind the rack. All 24 new DB-37 signal cables need to be labeled. New 96-pin DIN connectors need to be put on two ribbon cables (1Y5_80 B, 1Y5_81) in the 1X4 rack. We had to break these connectors to remove them from the back of the eurcrates. General cleanup of any cables, etc. left around the rack. We cleaned up most things this evening. Rename the host computer c1susaux2 --> c1susaux, and update the DNS lookup tables on chiara.
Attachment 1: 1X5Sorensens.pdf
Attachment 2: CDS_20190702.png
12273   Fri Jul 8 13:01:23 2016 AakashUpdateGeneralAcromag is talking ! | SURF 2016

Acromag is talking now, after few changes to the original EPICS configuration and cross compile configuration. Modbus config files also were changed and compiled again to run it on linux-arm architecture. I have made use of pyModbus for the final work and I am planning to use the same for grabbing channels. Though I am unable to grab channel data right now, I am able to communicate to it over ethernet and send and receive data.

13832   Fri May 11 11:47:33 2018 johannesSummaryPEMAcromag issues

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.

13844   Tue May 15 15:13:23 2018 KiraSummaryPEMAcromag issues

I tried calibrating the other channels today, but they still fluctuate. Sometimes they do stabilize at +/- 10V, but then suddenly drop to 5 or 6 V before climbing back up to 10. Turning the legacy off made it go only up to 6.67V. This happens for all the channels, even after doing a factory reset and recalibrating. Not sure what's happening here.

14892   Tue Sep 17 23:43:34 2019 KojiSummaryCDSAcromag logic checker

For the investigation of the latch logic issue for the CARM CM board, I have made the LED logic checkers with DB breakout boards. They require the pull up voltage supply of +15V because the acromag digital out is a open corrector (well... open "source") output.

The logic from Pin1 to Pin16 of DB37 can be monitored. The DB15 connector is only for monitoring the latch enable logic.

What Gautam and I found with the logic outputs was that the latch logic works fine but occasionally we found that the top 2 bits and the bottom 4bit were processed independently.

Attachment 1: digital_checker.pdf
Attachment 2: IMG_8914.JPG
13473   Thu Dec 14 00:32:56 2017 johannesUpdateASSAcromag new crate; c1auxex2 configured as gateway server for acromag

This splicing in of fast binary channels we discussed at yesterday's and today's meetings is getting messy with the current chassis. Cleaning up the cable mess was a key point, so I got a 4U height DEEP chassis from Rich and drew up a front panel for a modular approach that we can use at the other 40m locations as well. The front panel will have slots for smaller slot panels to which we can mount the breakout boards as before, so all the wiring that I've done can be transfered to this design. If some new connector standard is required it will be easy to draw a new slot panel from a template, for now I'll make some with two DSub37 and IDC50. Since this chassis is so huge it will have ample space for cross-connects.

I also moved the communication of c1auxex2 with the Acromag units off the martian network, connecting them with a direct cable connection out of the second ethernet port. To test if this works I configured the second ethernet port of c1auxex2 to have the IP address 192.168.114.1 and one of the acromag units to have 192.168.114.11, and initialized an IOC with some test channels. Much to my surprise this actually worked straight out of the box, and the test channels can be accessed from the control room computers without having a direct ethernet link to the acromag modules. huzzah!

Steve: it would be nice to have all plugs- connectors lockable

Attachment 1: fp_mod_4U.pdf
Attachment 2: IMG_20171213_171541850_HDR.jpg
13434   Fri Nov 17 16:31:11 2017 aaronOmnistructureComputersAcromag wired up

# Acromag Wireup Update

I finished wiring up the Acromags to replace the VME boxes on the x arm. I still need to cut down the bar and get them all tidy in the box, but I wanted to post the wiring maps I made.
I wanted to note specifically that a few of the connections were assigned to VME boxes but are no longer assigned in this Acromag setup. We should be sure that we actually do not need to use the following channels:

### Channels no longer in use

• From the VME analog output (VMIVME 4116) to the QPD Whitening board (no DCC number on the front), 3 channels are no longer in use
• From the anti-image filter (D000186) to the ADC (VMIVME 3113A) 5 channels are no longer in use (these are the only channels from the anti-image filter, so this filter is no longer in use at all?)
• From the universal dewhitening filter (D000183) to a binary I/O adapter (channels 1-16), 4 channels are no longer in use. These are the only channels from the dewhitening filter
• From a second universal dewhitening filter (D000183) to another the binary I/O adapter (channels 1-16), one channel is no longer in use (this was the only channel from this dewhitening filter).
• From the opti-lever (D010033) to the VME ADC (VMIVME 3113A), 7 channels are no longer in use (this was all of the channels from the opti lever)
• From the SUS PD Whitening/Interface board (D000210) to a binary I/O adapter (channels 1-16), 5 channels are no longer in use.
• Note that none of the binary I/O adapter channels are in use.

Attachment 1: AcromagWiringMaps.pdf
13435   Fri Nov 17 17:10:53 2017 ranaOmnistructureComputersAcromag wired up

Exactly: you'll have to list explicitly what functions those channels had so that we know what we're losing before we make the switch.

15760   Tue Jan 12 08:21:47 2021 anchalHowToCDSAcromag wiring investigation

I used an Acromag XT1221 in CTN to play around with different wiring and see what works.  Following are my findings:

### Referenced Single Ended Source (Attachment 1):

• If the source signal is referenced single ended, i.e. the signal is only on the positive output and the negative side is tied to GND on the source side AND this GND is also shared by the power supply powering the Acromag, then no additional wiring is required.
• The GND common to the power supply and the source is not required to be Earth GND but if done so, it should be at one point only.
• RTN terminal on Acromag can be left floating or tied to IN- terminal.

Floating Single Ended Source (Attachment 2):

• If the source signal is floating single-ended i.e. the signal is only on the positive output and the negative output is a floating GND on the source, the the IN- should be connected to RTN.
• This is the case for handheld calibrators or battery powered devices.
• Note that there is no need to connect GND of power supply to the floating GND on the source.

Differential Source (Attachment 3):

• If the source is differential output i.e. the signal is on both the positive output and the negative output, then connect one of the RTN terminals on Acromag to Earth GND. It has to be Earth GND for this to work.
• Note that you can no longer tie the IN- of different signals to RTN as they are all carrying different negative output from the source.
• Earth GND at RTN gives acromag a stable voltage reference to measure against the signals coming in IN+ and IN-. And the most stable voltage reference is of course Earth GND.

### Conclusion:

• We might have a mix of these three types of signals coming to a single Acromag box. In that case, we have to make sure we are not connecting the different IN- to each other (maybe through RTN) as the differential negative inputs carry signal, not a constant voltage value.
• In this case, I think it would be fine to always use differential signal wiring diagram with the RTN  connected to Earth GND.
• There's no difference in software configuration for the two types of inputs, differential or single-ended.
• For cases in which we install the acromag box inside a rack mount chasis with an associated board (example: CTN/2248), it is ok and maybe the best to use the Attachment 1 wiring diagram.

Related elog posts:

Edit Tue Jan 26 12:44:19 2021 :

Note that the third wiring diagram mentioned actually does not work. It is an error in judgement. See 40m/15762 for seeing what happens during this.

Attachment 1: SingleEndedNonFloatingWiring.pdf
Attachment 2: SingleEndedFloatingWiring.pdf
Attachment 3: DifferentialSignalWiring.pdf
15761   Tue Jan 12 11:42:38 2021 gautamHowToCDSAcromag wiring investigation

Thanks for the systematic effort.

1. Can you please post some time domain plots (ndscope perferably or StripTool) to clearly show the different failure modes?
2. The majority of our AI channels are "Referenced Single Ended Source" in your terminology. At least on the c1psl Acromag crate, there are no channels that are truly differential drive (case #3 in your terminology). I think the point is that we saw noisy inputs when the IN- wasn't connected to RTN. e.g. the thorlabs photodiode has a BNC output with the shield connected to GND and the central conductor carrying a signal, and that channel was noisy when the RTN was unconnected. Is that consistent with your findings?
3. What is the prescription when we have multiple power supplies (mixture of Sorensens in multiple racks, Thorlabs photodiodes and other devices powered by an AC/DC converter) involved?
4. I'm still not entirely convinced of what the solution is, or that this is the whole picture. On 8 Jan, I disconnected (and then re-connected) the FSS RMTEMP sensor from the Acromag box, to check if the sensor output was noisy or if it was the Acromag. The problem surfaced on Dec 15, when I installed some new electronics in the rack (though none of them were connected to the Acromag directly, the only common point was the Sorensen DCPS. And between 8 Jan and today, the noise RMS has decreased back to the nominal level, without me doing anything to the grounding. How to reconcile this?
15762   Wed Jan 13 16:09:29 2021 AnchalHowToCDSAcromag wiring investigation

I'm working on a better wiring diagram that takes into account multiple power supplies, how their GND is passed forward to the circuits or sensors using those power supplies and what possible wiring configurations on Acromag would give low noise. I think I have two configurations in mind which I will test and update here with data and better diagrams.

I took some striptool images earlier yesterday. So I'm dumping them here for further comments or inferences.

Attachment 1: SimpleTestsStriptoolImages.pdf
15778   Tue Jan 26 12:59:51 2021 AnchalHowToCDSAcromag wiring investigation

Taking inspiration from SR785 on how it reads differential signal, I figured that acromag too always need a way to return current through RTN ports always. That must be the reason why everything goes haywire when RTN is not connected to IN-. Now for single ended signals, we can always short RTN to IN- and keep same GND but then we need to be careful in avoiding ground loops. I'm gonna post a wiring diagram in next post to show how if two signal sources connect to each other separately, a GND loop can be formed if we tie each IN- port to RTN on an acromag.
Coming to the issue of reading a differential signal, what SR785 does is that it connects 50 Ohm resistance between Earth GND and differential signal shields (which are supposed to signal GND). In a floating GND setting, SR785 connects a 1 MOhm resistor between input shield and Earth GND. This can be used to read a differential signal through a single BNC cable since the shiled can take arbitrary voltages thanks ti the 1 MOhm resistor.

We can do the same in acromag. Instead of shorting RTN to IN- ports, we can connect them through a large resistor which would let IN- float but will give a path for current to return through RTN ports. Attached here are few scenarios where I connected IN- to RTN throguh wire, 820 Ohms, 10kOhms and 1MOhms in two sub cases where RTN was left open or was shorted to Earth GND. In all cases, the signal was produced by a 9V battery outputing roughly 8.16V. It seems that 10kOhm resistor between RTN and IN- with RTN connected to Earth GND is the best scenario noise wise. I'll post more results and a wiring diagram soon.

Attachment 1: TestingDifferentialSignalWithFloatingRTNwrtIN-.pdf
15779   Tue Jan 26 15:37:25 2021 AnchalHowToCDSAcromag wiring investigation

Here I present few wiring diagrams when using Acromag to avoid noisy behavior and ground loops.

### Case 1: Only single-ended sources

• Attachment 1 gives a functioning wiring diagram when all sources are single ended.
• One should always short the RTN to IN- pin if the particular GND carried by that signal has not been shorted before to RTN for some other signal.
• So care is required to mark different GNDs of different powersupply separately and follow where they inadvertently get shorted, for example when a photodiode output is connected to FSS Box.
• Acromag should serve as the node of all GNDs concerned and all these grounds must not be connected to Earth GND at power supply ends or in any of the signal sources.
• I think this is a bit complicated thing to do.

### Case 2: Some single and some differential sources

• Connect all single ended sources same as above keeping care of not building any ground loops.
• The differential source can be connected to IN+ and IN- pins, but there should be a high resistance path between IN- and RTN. See Attachment 2.
• Why this is the case, I'm not sure since I could not get access to internal wiring of Acromag (no response from them). But I have empirically found this.
• This helps IN- to float with respect to RTN according to the negative signal value. I've found that 10kOhm resistance works good. See 40m/15778.
• If RTN is shorted to nearby Earth GND (assuming none of the other power supply GNDs have been shorted to Earth GND) shows a reduction in noise for differential input. So this is recommended.
• This wiring diagram carries all complexity of previous case along with the fact that RTN and anything connected to it is at Earth GND now.

### Case 3: Signal agnostic wiring

• Attachment 3 gives a wiring diagram which mimics the high resistance shorting of RTN to IN- in all ports regardless of the kind of signal it is used for reading.
• In this case, instead of being the node of the star configuration for GND, acromag gets detached from any ground loops.
• All differences in various GNDs would be kept by the power supplies driving small amounts of current through the 10 kOhm resistors.
• This is a much simpler wiring diagram as it avoids shorting various signal sources or their GNDs with each other, avoiding some of the ground loops.

Edit Wed Jan 27 13:38:19 2021 :

This solution is not acceptable as well. Even if it is successfull in reading the value, connecting resistor between IN- and RTN will not break the ground loops and the issue of ground loops will persist. Further, IN- connection to RTN breaks the symmetry between IN-  and IN+, and hence reduces the common mode rejection which is the intended purpose of differential signal anyways. I'll work more on this to find a way to read differential signals without connecitng IN- and RTN. My first guess is that it would need the GND on the source end to be connected to EarthGND and RTN on acromag end to be connected to EarthGND as well.

Attachment 1: GeneralLabWiring.pdf
Attachment 2: GeneralLabWiring2.pdf
Attachment 3: GeneralLabWiring3.pdf
15785   Fri Jan 29 17:57:17 2021 AnchalHowToCDSAcromag wiring investigation

I found a white paper  from Acromag which discusses how to read differential signal using Acromag units. The document categorically says that differential signals are always supposed to be transmitted in three wires. I provides the two options of either using the RTN to connect to the signal ground (as done in Attachment 3) or locally place 10k-100k resistors between return and IN+ and IN- both (Attachment 2).

I have provided possible scenarios for these.

### Using two wires to carry differential signal (Attachment 1):

• I assume this is our preferential way to connect.
• We can also assume all single-ended inputs as differential and do a signal condition agnostic wiring.
• Attachment 3 show what were the results for different values of resistors when a 2Hz 0.5V amplitude signal from SR785 which as converted to differential signal using D1900068 was measured by acromag.
• The connection to RTN is symmetrical for both inputs.

### Using three wires to carry differential signal (Attachment 2):

• This is recommended method by the document in which it asks to carry the GND from signal source and connect it to RTN.
• If we use this, we'll have to be very cautious on what GND has been shorted through the acromag RTN terminals.
• This would probably create a lot of opportunities for ground loops to form.

Using an acromag card without making any connection with RTN is basically not allowed as per this document.

Attachment 1: GeneralLabWiringDiffWith2Wires.pdf
Attachment 2: GeneralLabWiringDiffWith3Wires.pdf
6210   Wed Jan 18 12:38:44 2012 steveUpdatePEMAcrylic plexiglass transmittance

Transparent- clear plexyglass from tree different sources were measured in 1064 and 532 nm light.

Samples: a, clear Acrylic-GP 0F00  from Ridout Plastics in thickness 0.7" ,  made by  Evonic Ind

b, clear cast acrylic from Mc Master Carr in thickness 0.94" , likely  made by Reynolds-Cast

c, clear cell cast  plexyglass from Delvie's Plastics - Utah in thickness  0.93" , maker not known

PMC reflected beam was used at 92 mW and 6 mm diameter at incident angle 0-25 degrees.

All tree samples agreed on Transmittance of ~90%, Reflectivity ~3-4% and calculated Adsorption ~6-7%

Transparent Colored Acrylic orange-amber #2422   from www.eplastics.com in 0.12" thickness gave  T 96%,  R 1% and  Ab-calc ~3% in the beam of 92 mW 1064  nm at 6 mm diameter.

Transparent , colored   Light Red #26 thin film filter   policarbonate-polyester   0.002" thick   from Roscolux measured T 81% of 115 mW 1064 nm

Now I changed power meter FieldMate to Ophir and the light source to laser pointer 2.2 mW  ~532 nm  with 1-2 mm beam diameter.

Orange - amber #2422  sample, 0.12" thick,  T 1% ,  R 4%  and  Ab-calculated ~95%, estimated visibility  ~50% It does cut out the green at this low power level.

Light red #26  sample  T 0.5%  at 2.5 mW of 532 nm . The transparent green is not visible.  The softening point of this sandwiched polycarbonate-polyecter filter is 160C. Estimated VLT of this film ~40%

SUMMERY:

Clear and colored acrylics'  @ 1064 nm  transmittance 90% or higher  regardless of thickness. Softenig point 115 degrees C

Colored acrylic and colored policarbonate film are adsorbing the low power green and they  transmit the 1064nm beam.

Options to consider: a, acrylic laser safety shield liner of  0.125" thick inside of 1" thick clear acrylic  box, OD +5 @1064 and OD +4 @ 532nm,  amber color VLT 27%,  150\$/sqft

b, thin metal liner for 1" wall acrylic box, VLT 0%

Attachment 2: roscogel_red#26_film.pdf
5524   Thu Sep 22 22:53:06 2011 SureshUpdateComputer Scripts / ProgramsActivated DAQ channels in C1IOO model and restared fb

To look at the WFS servo signals I was using test points in the servo filter banks.  This is not recommended for regular operation since acquiring the testpoint data at 16k loads the fb. Instead, I ran the daqconfig script from the scripts directory and activated the IN1_DQ, IN2_DQ and OUT_DQ channels in all the six servo filter banks (at 2048 Hz sampling rate) and then restarted the fb.   However the c1ioo Sun machine stopped responding after this.  Koji and I went in to see what was going on and the machine was not reponding to a keyboard plugged directly into the machine.  The screen display showed no reponse to our key press.  So we did a hardware reboot with the tiny switch in front of the machine.  It came up okay and all the c1ioo models were back in action.

I then checked with the dataviewer to make sure that I can see the trends on the newly activated DQ channels.  They were all fine.

15946   Fri Mar 19 15:31:56 2021 AidanUpdateComputersActivated MATLAB license on donatella

15945   Fri Mar 19 15:26:19 2021 AidanUpdateComputersActivated MATLAB license on megatron

3690   Mon Oct 11 17:31:44 2010 yutaUpdateCDSActivation of DAQ channels for 8 optics

(Joe, Yuta)

Background:
We need DAQ channels activated to measure Q-values of the ringdowns for each DOF, each optics with the Dataviewer.

What we did:
1. Activated the following DAQ using daqconfig (in /cvs/cds/rtcds/caltech/c1/scripts).
C1:SUS-XX_AASEN_IN1
C1:SUS-XX_SUSBBB_IN1
C1:RMS-YYY_AASEN_IN1
C1:RMS-YYY_SUSBBB_IN1
C1:MCS-ZZZ_AASEN_IN1
C1:MCS-ZZZ_SUSBBB_IN1
(XX=BS,ITMX,ITMY  YYY=PRM,SRM  ZZZ=MC1,MC2,MC3  AA=UL,UR,LR,LL,SD  BBB=POS,PIT,YAW)

2. Set datarate to 2048 for each DAQ.

3. Restarted fb(frame builder).

Result:
We succeeded in making DAQ channels appear in the Dataviewer signal list, but we can't start the measurement because c1mcs is still flaky.

Note:
We found that c1mcs crashes everytime when turning off all the damping servo (using "Damp" buttons on the medm screen).
It doesn't crash when all the filters are off.

3691   Mon Oct 11 20:52:00 2010 ranaUpdateCDSActivation of DAQ channels for 8 optics

Bah!  We tried to get some data but totally failed. It seems like there is some rudimentary functionality in the FE process of the MC, but no useful DAQ at all.

Neither Dataview or DTT had anything. We looked and the NDS process and the DAQD process were not running on FB.

I restarted them both (./daqd -c daqdrc) & (./nds pipe > nds.log) but couldn't get anything.

There's a bunch of errors in the daqd.log like this:

CA.Client.Exception...............................................
Warning: "Identical process variable names on multiple servers"
Context: "Channel: "C1:SUS-MC1_SUSPOS_INMON", Connecting to: c1susdaq:57416, Ignored: c1sus.martian:57416"
Source File: ../cac.cpp line 1208
Current Time: Mon Oct 11 2010 18:25:15.475629328
..................................................................
CA.Client.Exception...............................................
Warning: "Identical process variable names on multiple servers"
Context: "Channel: "C1:SUS-MC1_SUSPIT_INMON", Connecting to: c1susdaq:57416, Ignored: c1sus.martian:57416"
Source File: ../cac.cpp line 1208
Current Time: Mon Oct 11 2010 18:25:15.475900124

5696   Wed Oct 19 12:25:58 2011 SureshUpdate40m UpgradingActive Tiptilts from LLO moved to clean shelf along X arm

I have moved the active tip tilts that we brought over from LLO to the Clean Bureau along the X arm (closest to the ETMX). There are two tip tilts and a pack of spare parts.

5697   Wed Oct 19 13:45:11 2011 SureshUpdate40m UpgradingActive Tiptilts from LLO moved to clean shelf along X arm

I have moved the active tip tilts that we brought over from LLO to the Clean Bureau along the X arm (closest to the ETMX). There are two tip tilts and a pack of spare parts.  I am sure that the tip tilts are clean, packed in the clean room at LLO.  I am not sure whether the spares are clean.  I have kept them together for now.

We need to open one of the Tip tilt packages to be sure what we have got.

3917   Sun Nov 14 16:40:46 2010 JenneUpdateTreasureActivities related to OSEM measurement

[Valera, Jenne]

We pondered the idea of clamping the PRM optic to measure the OSEM noise.  So we opened up the BS tank to give this a try.  We rediscovered that Jenne is too short to reach the other side of the PRM tower, so we couldn't fully clamp the optic (when is Jaime coming again? He's kind of tall...)  If we only did the back 2 EQ stops, the optic would still be able to rock, and thus defeat the purpose of clamping anyway.  So we didn't go for it.

While we were in there we saw that the SRM OSEMs were just hanging out on the table, and decided to go with them.  See Valera's elog for details on our measurement.  We closed up the tank without making any changes to anything.

In other news, we still need to figure out how to change up the connectors to get those OSEMs over to the ITM table.  This needs to happen pretty soonish.

ELOG V3.1.3-