Draft: Safe default settings for S4G

While testing the SPI rack driver in the lab, we have encountered a number of behaviours that could be unsafe in a real lab setting. These are mostly related to sudden jumps in current. This MR proposes a number of changes to default settings in the S4G driver that will prevent these jumps and other unexpected behaviours from occurring. These safe modes should always be the default, as a user may not think about these issues until damage is done to the chip.

Summary of the changes made:

• ramping_enabled set to True by default. When this is set to False, the current jumps instantaneously from one value to another. This sudden flux jumps can cause damage to certain types of quantum device.
• By default, s4g_module initialises with reset_currents=False. This ensures that, whenever we restart the kernel and reinitialise the SPI rack driver, the current will remain in the same state it was before. In practice, the user will have to restart the kernel many times to deal with errors and software updates, and it is not desired to have a sudden jump in current every time this happens.
• Previously, when ramp mode was enabled, the ramp would run asynchronously in the background, allowing the user to run other python commands before the ramp was completed. There is also no message to indicate that a ramp is in progress. I argue that this is not a desired behaviour, especially as a default. Although the ramping state can be queried via is_ramping, a new user might not know about this ramping mode, and try to run more commands before the ramp is complete. Furthermore, this behaviour has the potential to cause errors in the case of automated measurements. Say we are doing a 2D can of resonator frequency and flux. We complete one row of data a given current value, then when we step to the next current value. The measurement control may start scanning through the frequencies again before the ramp is complete. This would give a false reading in the experimental measurement.

To deal with the latter of these problems, I have added a th.join() to the bottom of the ramping function. This ensures that the programme waits until the ramp is finished before letting you run any more commands. Perhaps we want to enable the ability to run the ramp in the background, but I think this should be done as an optional mode if at all (otherwise this could cause errors without the user knowing about it). I have also included print statements that show the progress of the ramp and the current, so that that the user always knows what is happening during the ramp.

I have also made a small change to how the ramp runs. Previously we started the loop at vals[0], which is the initial value of the current. But this would mean that we would wait for time dt before setting the current to the same value it was already, which is not necessary. Therefore the loop now starts at vals[1]. I have also fixed some off-by-one errors to make the definition of the ramp consistent.