[Jon, Shane, Luis]

My repair of the internal ribbon connecting the ADC to the adapter board resolved the timing signal problem. After this repair, we were able to start the front-end IOP model and checked out the RTS diagnostic screens (pictured below). All indicator lights were green except for the DK flag (indicating the DAC outputs are not enabled) and the DAQ flag (indicating that the system is recording data to disk). Those were both as expected, because the DAQD data acquisition service was not set up yet and the DAC outputs are not enabled until at least one user model (which outputs signals to the DAC) is started. I created and installed a simple user model (C1MSC) and confirmed that the DK flag clears once this model starts.

I later attempted to set up the DAQD service, which is needed to save data, but am yet to successfully debug it. I have received some guidance from one of LIGO's CDS experts and will try it at my next opportunity for lab work.

Update: I was able to put the FROSTI power controller on the lab network. It is connected to the switch in the top of the rack and is assigned a static IP address of 192.168.1.12 and an NDS hostname of relay1.

The controller can be remotely accessed through an SSH command line interface as well as an HTML webpage, which can be opened from any web browser on the lab network by navigating to the above IP address (the login credentials are the same as for the workstation computers).

There is also an unofficial Python package for interfacing with the controller: dlipower. We will investigate using this package to interface the controller with soft EPICS channels hosted on the CyMAC. This will allow us to create a custom MEDM screen for controlling the FROSTI heater elements.

Edit: The login credentials were set up to be the same as for the CDS workstations.

Summary

Today I finished implementing an RTS model to read out the integrated FROSTI RTDs (temperature sensors) via the CyMAC. The model is named "MSC" and is located at cymac:/opt/rtcds/usercode/models/c1msc.mdl. We successfully tested it with the heater elements operating in vacuum at low power (12 VDC), finding them to reach an average steady-state temperature of 160 C.

From the cymac host, the MEDM control screen can be accessed with the terminal command "sitemap" (from any directory).

Measurement Technique

Each FROSTI heater element [299] contains an internal two-wire RTD placed near the front emitting surface, which enables the temperature of the blackbody emitter to be directly monitored. From the measured temperature and the emissivity of the uncoated aluminum nitride surface (known to be ~1 in the IR), the radiated source-plane power can also be estimated.

The resistance of each RTD is measured via a ratiometric technique. The RTDs are powered in series with a 1 kΩ reference resistor located inside the readout chassis [305], whose temperature is not changing. The signal is obtained by taking the ratio of the voltage difference across each individual RTD to the voltage difference across the reference resisitor. The advantage of this technique is that the ratio of  the voltage differences is insensitive to changes in the current through the resistors (since they are all in series; see [271] for wiring diagram).

Implementation Detail

The signal flow is shown in Attachment 1. The eight RTD signals enter through ADC channels 0-7, along with the reference resistor signal on channel 8. The first set of filter modules apply a calibration gain to convert the signals from raw ADU counts to units of input-referred voltage. The ratio of each RTD signal to the reference resistor signal is then taken. The second set of filter modules multiply the voltage-difference ratios by the resistance of the reference resistor, 1 kΩ ± 0.01%, to obtain the RTD resistances in physical units of ohms.

Finally, a freeform math module is used to invert the quadratic relation between each RTD's resistance and temperature. The final signals passed to the third set of filter modules are the RTD temperatures in physical units of degrees C. The temperatures of the tungsten RTDs are estimated assuming TCR coefficients of A=0.0030 C^-1 (±10%) and B=1.003E-6 C^-2, which were provided by the manufacturer.

One DAC channel is used to provide the excitation voltage for the RTD measurement, which is visible on the far right of the control screen. At its maximum output voltage of +10 V, the DAC can drive a maximum current of 10 mA.

Finished ADC-DAC loopback testing today (see attached xlsx file or access directly here). All looks well with the first 8 channels, with the gain hovering just under 2. Also edited c1msc model in simulink to add channels 7-15 (the last 8 channels), and changed the rate back to 64K. See image 1 for the updated c1msc model. The last 8 channels are also looking good and show no problems, with slightly more scattering for the gain, but all values very close to 2.

We also installed the new eight-channel Perle IOLAN SDS8 terminal server today. Image attached.

NOTE: When we were installing it, we noticed an energized wire dangling from the 24V power supply. Has since been fixed and put back into place.

The timing chassis used for the cymac has been shut off due to an unknown issue causing its supplied current to fluctuate. All real-time models will be suspended until a solution is found.

[Ma, Luis, Shane]

Working theory for the timing chassis issues had been that the 1A breaker was tripping and causing the failure of the Valon 5015 and 3010 to output the timing signal correctly. We just tried bypassing the breaker, running 6 V on the benchtop power supply (set the current limit to 1.5A), with the 5010 generating the sine wave to pass to the 3010. All worked correctly, and there were no issues. Square wave outputted by the 3010 was exactly as desired (image attached) at the correct frequency, and this confirms the issue was the breaker, not the valon 5015. Ready to go ahead with ordering a new replacement breaker.

We replaced the 1A breaker in the timing chassis today with a 4A one, and tested that all is working well. The chassis successfully outputted the correct signal (image attached). The real time models have also been restarted and the CyMAC diagnostics screen is showing all green flags. Timing chassis has been closed up and reinstalled in the server rack.

Debugging update for vac system serial communications: we were able to successfully connect the smaller turbo pump to the Varian (manufacturer) software today by plugging the controller db9 directly into spica, and verified that the pump was able to send and receive information. Still no success on communication with the larger pump via python serial code, though. Issue potentially lies in the pinout mapping of the connectors, as the pinouts we'd been using work successfully for the small pump which only requires 3 connections (RXD, TXD, GND), but the large pump may require more. Tried to test this on the big pump by keeping the pinout setup for the small pump, and incrementally adding the remaining 6 connections on a one to one scale (Pin 1 matched to Pin 1, etc) between the controller DB9 and the field DB9 connected to the IOLAN ethernet cable. After each new connection was added, I retried running the serial connection code. None of the additional connections yielded any results, and the large pump remained unable to connect through the code. Next step is further looking into documentation on the pinouts to see if the large pump requires a different connection setup than the small pump.

[Shane, Jon]

Update on the serial interfacing with the vacuum system: both turbo pumps are now able to successfully communicate through the code. The older pump, for unknown reasons, required a newer version of the communication syntax (despite the newer, small pump being able to communicate fine with the old communication format). We have also confirmed that the newer pump works with this new format as well. Next step is interfacing the pressure gauge.

[Shane, Jon]

There are three major issues with the lab's CDS system that should be addressed. They are ordered from the highest priority to the lowest.

• CyMAC has stopped serving the fast channels (65k Hz)
  The channels are still there, and the data from the slow (16 Hz) channels is served correctly, but the fast data is not served. As a result, diagggui can not retrieve any information at the moment.
  Probably the issue is the same as the version conflict between daqd and nds2-server. After installing nds2-server on CyMAC and realizing that the conflict can not be resolved, I reverted the changes so that the CyMAC could be compatible with daqd, but there is a chance that there are still version conflicts that block the fast channels.
  I suspect that we have broken the MSC model when adding the new button. This could explain both the fasr-channels fault and the unexpected crashes.
  
  UPDATE 6/5
  Fixes this by rebuilding the models.
  Note for the future: The c1iop and c1msc models should be rebuilt together, even if no change has been made to c1iop.
• The fast channels were not saved to the frames
  Reviewing the frame files showed that the daqd was only saving the 16 Hz data in the .gwf frame files. I had missed this because I only checked the existence and the integrity of the raw frame files, but never retrieved the high-frequency data itself to check it.
• NDS2-server is installed, but does not distribute the data
  I managed to install the nds2-server and its satellite programs on the Chimay, and NFS mount the frame files on it. The server successfully chaches the channel names, frame files, and the data, but fails to list the channels for distribution.

Note: CyMAC machine was strangely disconnected from the network, and required manual reboot. I couldn't find any abnormal logs that could explain what happened.

• The MEDM models issue was fixed. The issue was that building the c1msc model alone was not enough and we had to re-build the c1iop as well, although no changes has been made to the c1iop. Added a note in the wiki on this for future reference.
• For writing the fast channels to the frame files, our CDS system should have a GDS broadcaster. I followed this wiki page to set one, but it breaks the current daqd system. Asked about it earlier today on the CDS Mattermost channel and waiting for a response. 
• Maybe I should continue the distributed scheme we have been trying for the nds2-server and let another machine on the network do this. 
• Question: daqd has a feature to zero-out the bad data (NaNs), and it is currently on for our system. I don't think that it's a good idea to have this. Should I turn it off? 

• Fast channels recorded to .gwf frame files
  • Had to add a DAQ Channels block to the c1msc model for those channel to be recorded in the .gwf frame files. The block is in the CDS_PARTS, and I just had to copy it to our model. Here is the example text for the channels:
    
    

    #DAQ Channels

    ONE_DAQ_CHANNEL 2048
ANOTHER_DAQ_CHANNEL 1024
SCIENCE_FRAME_CHAN* 1024
UINT32_CHAN uint32 2048
DAQ_CHANNEL_AT_DEFAULT_RATE

    I added two channels to the list (V0 and V1). Remember that the channel name should not be the full name, but just the part's name. In this case, I added these two channel names:
    
    V0_OUT
V1_OUT
    
    with the default sample rate. 
• The fast channels are recorded with an extra _DQ in their names. So, in ndscope and diaggui these two channels should be addressed as
  • C1:MSC-V0_OUT_DQ
  • C1:MSC-V1_OUT_DQ

• Update 6/13: enabled recording of all the ADC voltage channels so that Tyler can use all the data for the noise floor calculation. attached is an example of diagggui with almost 30 hrs of data.

• TODO: Enable daqd_wiper

Group Meeting slides for Non-deterministic Heater Response.

Power point slides

PowerPoint slides new

PowerPoint slides older

[Ma, Cece, Luke, Mary, Shane]

On Friday (Jan 24), we installed the heater elements on the stand. The heater elements are arranged from 1 to 8, oriented from right to left as shown in Attachment 1. Each wire has been labeled according to its corresponding element number and type (e.g., RTD connections, heater connections).

Note: We currently do not have enough PEEK zip ties, so standard zip ties have been used temporarily. These must be replaced with PEEK zip ties before the setup is placed in the vacuum chamber.

[Ma]

Installed all the pins to the peek DB 25 connectors

[Ma] Wed 1/29/2025

No short circuit between heater element ✓

No short circuit to ground on any pin ✓

No short circuit between connectors ✓