cryostat-gui / cryostat-gui Goto Github PK

Include a software layer for the ramp of the Oxford ITC503:

The ramp rate set for ITC503 is not always what the instrument does, since there is a maximum time for the ramp. If a very small ramp rate is set for a single large temperature step, this will fail.

• look at the maximum step time
• look at the absolute maximum ramp time
• In case one step is not enough to keep the ramp rate, break it into two steps

Currently a function in a device control thread looks something like this:

    def setRamp_Rate_K(self):
        try:
            self.LakeShore350.ControlSetpointRampParameterCommand(1,1,self.Ramp_Rate_value)
        except AssertionError as e_ass:
            self.sig_assertion.emit(e_ass.args[0])
        except VisaIOError as e_visa:
            if type(e_visa) is type(self.timeouterror) and e_visa.args == self.timeouterror.args:
                self.sig_visatimeout.emit()
            else:
                self.sig_visaerror.emit(e_visa.args[0])

Actually, nearly all the functions look like this. What the function does is in one line, all the rest is exception handling, which is the same in all functions. Ideally, it would look more like this:

    @ExceptionHandling
    @pyqtSlot()
    def setRamp_Rate_K(self):
            self.LakeShore350.ControlSetpointRampParameterCommand(1,1,self.Ramp_Rate_value)

Currently I am not sure about how to pass the signals to the decorator, as all of this happens at compilation-time of the class.

• uninterrupted live logging in case of starting a new thread

• aligning the database plot code to the currently functional live-plot (and make it functional)

• combining database with live-data

• backend for all the currently disabled GUI elements:

• relative vs absolute time (in case of time-axes)

• time in hours/minutes/seconds

• drawing only a certain range (especially when using the database)

• In-application plotting of live-measured data

• showing multiple plots at once

• saving and loading presets

implement button on mainWindow to clear the temporary folder in which the XX.pid files are stored, which prevent the individual ControlClients to start multiple times.
This is necessary in case of non-orderly shutdown of the ControlClients, during which the pid files are not cleared properly

ITC503 is not capable to change PID values during a sweep on its own.

• implement software-based automatism
• integrate automatism in the general settings
• connect the settings with the ITC thread

change from string formatting to sqlite3's builtin sql-injection prohibiting functionality:
change all
mycursor.execute('ADD COLUMN {} TO TABLE {}'.format(column, table))
to
mycursor.execute('ADD COLUMN ? TO TABLE ?', column, table)

• implement function to take one resistivity+temperature measurement
• thread which runs the above mentioned function independently of the GUI
• design window to control one-shot measurements
• build the backend connection between one-shot window and thread
• measurement storing thread for:
• data storage in .dat files

Implement one mainControl app, which can start/stop, show/hide different device apps

adapt mainWindow.py accordingly:

• change the GUI in itself to have a list of devices nicely visible, with corresponding start/stop etc buttongs
• implement checking for running services, starting/stopping services
• activate GUI updates (changing measured values in the GUI) for individual windows of running services

when putting 100% to the gas flow parameter, the needle valve stays at 0%, since the device does not understand 100%.
One-liner to make 100% gui input 99% device input

implement an abstract logger (and logging configuration) class from which the different ones can inherit basic functions and attributes

take an extended look at which windows should be closed and which should be hid, in what circumstance - and implement the same.

make a setting in the global settings:
checkbox: 'silence errors'
check for that in the show_error_textbrowser method

• for individual device windows, possibly make a small dot (like a LED blinking light), which blinks once during data updates, so it is clear when those updates happen, and spot stale data
• alternatively, record in the MainControl GUI (once it exists) whether the data is up-to-date, and display that with a colored indicator

memory leaks:

• plotting windows, when being closed should shut down their backend
• list of tiny-workers should be checked and finished/dead threads being removed

GUI freeze:

• when using the controls_software_disabled context manager, instead of just disabling the wanted widgets, the whole GUI freezes. find the bad program design and exchange it for something better

• LakeShore 350
• ITC 503
• IPS 120-10
• ILM 211
• SR 830
• SR 860
• Keithley Nanovoltmeters
• Keithley Power Supplies

implement running the sequences for the Cryostat in the zmq architecture, i.e. using zmq comms to retrieve data

• data retrieval for all relevant data in principle possible (if injected to liveStorage)
• retrieving from liveStorage
• direct access to measuring application parts (request and reply via zmq router and dealer)
• dealing with non-answering drivers
• template for measuring and saving scripts (external)

set:

• temperature

currently data is provided for prometheus by the one logging class, which collects all data, and exposes it all to prometheus.
we would like to have the individual services which interact with the instruments, to do this themselves - like this, if there is no data available, it is much easier to detect

GUI element signals should in principle not be connected to lambda functions: they can not be disconnected. Thus, whenever one stops a device thread and starts it again, the gui elements are connected a second time, and every action is recorded and managed twice (or multiple times, when the device thread was stopped and started more than once)

Therefore, we need functions for every single GUI element action!

implement a long term storage for prometheus on the server, so logs can be investigated for longer periods

• good calculation for rate of change of a specific value - needs precise datetime format, refer to #22

• uncertainties of measurements

• maybe more useful data to calculate from raw measured values?

the data sent back by the ITC is in exact accordance with what is being displayed at the physical front panel. Therefore, a number above 100°C can only have one decimal - however, the sensor is still better.
Using the current setpoint and the temperature difference between setpoint and temperature, more precision could be retrieved from the instrument

the logging package should be used as advised in the docs:

• no handlers attached to loggers, except possibly the NullHandler
• loggers with expressive names relating to module and class
• handlers and formatters are used in case the modules for specific instruments are started as __main__, so that logging output is generated

Implementing an abstract sequence performer, which leaves the set_temperature functions with an NotImplementedError, where anyone might plug in their systems particularities - to be used in conjuction with the sequence parser.

There are many things to do here separately!

A thread which recieves a sequence, and measures in a given pattern, without setting any control parameters of the devices themselves

• integrate the measuring function(s)

• automatic range adjustments
• fix putting in PID values!
• Heater Off Button - but no choosing the heater range!
• zone PID values GUI elements

Implement a 'settings' window, where all the 'basic' settings for instruments or control-cycles will be drawn together into a central place.

• Implementation of all proposed functions in the Sequence-editor
• Integrate the last LakeShore Pull-request from @adtera
• Get all the (needed) low-level functions of the Keithleys (Current Sources & Nanovoltmeters) working
• decide on a proper way to handle the Keithleys threadwise

• introduce variable time for live calculations
• introduce variable time to show at live plotting
  These two should be independent!
• live plotting data list should be conveniently large, and possibly fed into a database from which it can be retrieved with high performance
• menu to choose which calculations to perform --> put to settings window

while using nssm to run ControlClients as windows services, it is currently not possible to use the file rotation feature of I/O nssm stdout redirection.
When using this feature in nssm, the services cannot be reliably stopped, but remain in a state of "stop pending", while the respective nssm process continues to run.

So that we do not incur enormous log-files, we should find another way to rotate them, hopefully with only a small amount of hardcoding of file locations

Implement the following functions and behaviour

• function((s) to bring the device to highest/lowest speed

• 2182A Front Autozero
  can be turned off for speed (measures two times with different polarities)
  if one measures with two polarities oneself, the effects minimised by Front Autozero should also
  be minimised by design

• 2182A Autozero

• 2182A Autorange (turn off for speed, do ourselves)

• 2182A set Rate

• test for ohmicity of probe, 4 measurements in the specific setting

implement the logging and dataStorage app

• dataStorage for live reading
• logging to prometheus from individual application parts
• logging to sqlite

Currently, the one core operating everything is just coming to its limit.

the multiprocessing package should be used for calculations for displayed data, inside the respective QThread, so the actual workload is handed to a different core.

Additionally, it would be very good to do the database update in a separate core (using multiprocessing again), as this gives short bursts of comparably large cpu loads.

• parsing multilevel scan functions (e.g. scan through field inside a scan through temperature)
• export to json and pickle
• parse most important PPMS commands
• chamber operations PPMS commands

for temperature control:

• find the particularities of the current system, related to temperature
• introduce a way how to handle such particularities in a general way (possibly taking all PID values to an application preferences window)
• implement and integrate all possible functions (set field/temperature/....)

For stabilized temperature measurements:

• decide on how to check the condition whether a measurement should be taken

• switch to good datetime formats in all instances - datetime.datetime
• Low-level functions for Keithley Multimeters
• low-level functions for a Lock-In Amplifier
• plotting the rate of change of one value (or a desired rate of change) above the current live data plot (as a straight line as an indicator for the current slope)

classes inheriting from AbstractLoopThread run the function running() repeatedly, waiting a set interval between runs. FOr measuring devices this can mean to request a high number of different values from an instrument, which might take a rather long amount of time.
Therefore, the function running is only invoked if a parameter self.loop = True is set. As soon as this parameter is changed to False, the function is not invoked anymore, until it is set to True again.
Also, after setting it to False, one should wait for a small amount of time, to ensure that all recent communication is over, to have a "clear field of operations".

This setting and unsetting for all/a specific device, should best be handled in a context manager. This context manager should accept two arguments, one mandatory and one optional:

• whether all or only a set of specific threads should thus be "put to sleep" (mandatory)
• in case only a specific set should be affected, that set (optional)

currently this is solved in a bare function, which needs to be called for setting and unsetting.

• (measurement) data storage in sql (sqlite) database
• (measurement) data storage in another memory efficient file format (hdf5 ?)