Cryostat control details

Hardware abstraction layer (HAL)

• Comes with a small set of drivers for various hardware things
  • SRS SIM921
  • CTC100
  • Ryan + Sae Woo “swarm” circuits
  • Brick PCBs
• Specifically, the following types of hardware:
  • Temperature sensors
  • Heaters
  • Electrical relays
• It also allows construction of “virtual PID heaters”. These take a single heater and a single thermometer and combine them into a PID feedback system that can have its temperature set

Initialization

• Each device (e.g. thermometer or temperature sensor) has the following specified in the TOML file:
  • name (e.g. 4k)
  • hardware type (e.g. SIM922)
  • Any additional initialization parameters required, for example:
    • For SRS devices like the SIM922 which slot (e.g. slot 7)
    • For USB devices, the address /dev/usbc313
    • For heaters, a maximum value (e.g. 0.5 amps or 24 volts)
    • For heaters, a default value when turned on (e.g. 0.3 amps or 12 volts)
    • For AC resistance bridges, the configuration settings (e.g. excitation of 30 uV)
    • For a virtual PID heater, the thermometer name and its associated heater or relay
  • parameters configured in the TOML f

Allowable commands

• get_temperatures
  • Inputs: none
  • Returns: a dictionary with entries of the form {sensor name : temperature}
• set_heater_value
  • Inputs: the name of a heater, and its value (volts/amps)
  • Returns: nothing
• set_relay_state
  • Inputs: true/false
  • Returns: nothing

HAL configuration with TOML

[[thermometers]]
name = "4k"
hardware = "SIM921"
slot = 7
address = "COM5"
 
[[thermometers]]
name = "40k"
hardware = "CTC100"
address = 
 
[[heaters]]
name = "heat-pump"
heater_type = "relay"
hardware = "swarm"
address = "/dev/diodes"
i2c = 4
 
[[heaters]]
name = "heat-switch"
hardware = "CTC100"
address = "PID"

Monitor (metrics server / source of truth)

• The Monitor is responsible for keeping track of the current state of the system.
• It queries continuously queries the HAL and updates an internal “source of truth” with various temperature values, state machine state, etc. This source of truth is really just a internal Python dictionary
• It also runs an HTTP “Metrics Server” that makes accessing these values easy — the source of truth dictionary is converted to JSON and made available via HTTP

State machine

• The state machine first reads a TOML list of names and

[variables]
1k_max = 2.0
 
[states.warming_pump.target_temperatures]
# Here we specify target temperatures for each stage
pump = 50
 
[states.warming_pump.criteria.to_cold]
4k = ["less than", 3.7]
40k = ["less than", 3.7]
 
[states.warming_pump.criteria.to_cold]
4k = ["less than", 3.7]
40k = ["less than", 3.7]

• Takes a list of names of heaters and their associated temperatures
• Enter a state, e.g. heat_switch_cooling
• The state machine operates in a cycle
  • On entering a state
    • Set target temperature for each heater
  • While in that state
    • Check whether the temperatures conditions are met to move to a different state
    • Update the heaters for any PID devices
    • Repeat the above

Expected behavior

• Monitor sends a ZMQ request to HAL for sensor/heater states as a dictionary encoded in JSON: e.g. {cmd : 'get_temperatures'}
• HAL receives request and returns all data
  • HAL can’t get a single thermometer state at all — always return everything in first-pass
• Monitor takes the data and immediately updates Source of Truth (HTTP Metrics Server) with it
• Monitor also queries state machine and updates Source of Truth
• State Machine observes that the values in the Source of Truth indicate it should switch state
• State machine switches state
• State machine sends HAL (ZMQ?) a request to turn on a heater
• HAL turns the heater on
• Monitor begins polling again

Krister’s existing repo

• https://gitlab.nist.gov/gitlab/lks/fridgedocker/