Adding LBL functionality + Resolving issues with circuit impedance assumed by Agilent

[wmatava]

The core of this push is to a add a bunch of functionality to LBL's hardware setup when data-taking. A couple of problems we negotiate with at LBL:

• IV bias points are defined in daq.ini and iv_didv.ini in current monolithically across all channels. We frequently tune our bias resistors to different values to achieve simultaneous transition across multiple sensors, which means that we would need a unique bias voltage for each of the sensors in order to ensure all sensors share a current. In reality, we're only capable of delivering a single bias voltage.
• The signal generator (and in LBL's case the TES bias source) in principle "sees" an output resistance equal to the net resistance of ALL of the bias lines in parallel. Currently, the code uses the bias resistor of each channel individually. (Note that this is nominally an issue at UCB, albeit mitigated by the fact that load resistors are significantly larger than the internal impedance of the signal generator so as to make the order of the error sub-percent)
• Online iv gives us problems amidst flux jumps, namely when the SQUID jumps to a voltage off of the DAQ's range. Autocuts doesn't know what to do with a totally constant waveform, and throws errors.
• When running daq.ini with a mini-dIdV, we will see the Agilent autorange when switching signal types (i.e. between DC offsets and square waves) desptie autorange nominally being off.

The hope for this is, if you're already using pytes

Allow the user to define IV bias currents in voltage or current

• In both setup.ini/didv.ini we add an "bias_in_ua" boolean variable. If true, the bias vector will be interpreted in units of uA; otherwise it will be interpreted in mV. (The variable is optional and defaults to uA in order to ensure that UCB's existing .ini files continue to function)
• Pytesdaq stores bias vectors as a one-dimensional array; in order to preserve this, we avoid converting immediately converting any voltage values to current (suppose we had two bias lines with different bias resistors; at a common voltage, each would have a unique current, which would require expanding this array to a second dimension.
• Bias values are passed (unit-agnostic) to set_tes_bias alongside a flag denoting this units. (This was alway true, but the unit can now be mV). Conversion calculations occur inside this function without chaning much of the low-level structure.
• We also add warnings/errors depending on the unit defined/hardware. For example, we don't allow users to define bias vectors in voltage if they're using an FEB board (for which the bias resistances are not stored in setup.ini). We do allow LBL users (i.e. those with a common bias source and signal generator) to define the bias vector in current, albeit with a warning indicating that the values are only accurate if all of the bias resistors are identical

Calculating the net impedances of the signal generator/tes bias lines

• Prior to IV/dIdV, we pre-calculate the net bias resistance of the bias lines (for both the signal generator and the tes_bias source) and store them inside the control object. This value is then called inside the function set_tes_bias and set_signal_gen_params and set as the agilent's assumed external impedance (subject to a boolean variable "use_net_resistance" in both of these functions. The only time I can imagine not wanting to use this value is if they are not using the agilent, or if they are looping channels during dIdV with FEB boards to ensure that only one channel sees the signal at a time. Both of these cases are accounted for in the code.
• There is of course the question: how do we know which channels to include in this calculation. For now, I've elected to use the channels for which data is being taken. This is good assumption at UCB, where FEB boards can "block" signals to unutilized channels, but it is an assumption at LBL, and we need to keep track to ensure that extra channels are not included.

Allow the user to disable online IV in run_IV_didv.py

• Pretty straightforward, just adding an argument when running this script to disable all of the code associated with online iv.

Fix agilent auto-range during mini-dIdV

• At the beginning of our dIdV, we switch to the maximum bias seen across data-taking, then switch on the square wave, before proceeding with dIdV at the defined bias points. At the end of the scan, we once again switch to this maximum value before switching back to a DC offset, then restore the original agilent parameters to continue data-taking. This helps keep the agilent in a high enough range to be able to hit all future IV/dIdV/continuous bias points.