-
Notifications
You must be signed in to change notification settings - Fork 40
Sample Changer changes and Sample Changer maintenance
Warning
This page is now deprecated.
The up-to-date page can be found at:
https://mxcubeweb.readthedocs.io/en/latest/dev/sample-changer-changes-and-maintenance.html
A new commit just proposed (August 2017) introduces a number of changes to the existing support for SampleChanger in mxcube3 and introduces support for "maintenance" commands. This note explains the motivation and some details about this implementation:
The following changes are introduced and explained below:
- STATE of SC now represents state of SampleChanger hardware (before it was showing the result of the previous action in the interface)
- loadedSample (with address and ID/Barcode) now separated from contents and included in app state->SampleChanger
- Unload and Abort commands are proposed in SampleChanger component when a sample is loaded (Unload) and when the SC is in moving state (Abort)
- routes for loaded_sample, state, contents added (support for SampleChanger corresponds with GenericSampleChanger features, state defs and API)
As mxcube user are often confronted with a number of "maintenance" operation with the sample changer (open lids, soak-dry-home or other trajectories, etc...) a new set of features and graphical component has been added in mxcube3.
To be able to respond to different types of sample changers with completely different set of maintenance commands the associated hardware object must provide all necessary information about:
- which commands exist
- which commands are available for the user at a particular moment
- an array with different state bits (general state, powered-state, lids-state... or other)
- a free-format message to inform users about any incidence
SC_Maintenance hardware object must provide: (see CatsMaint.py in HardwarObjects/sample_changer for example): ::
get_cmd_info() method returns a list with a series of "command groups". Each group is composed of a label and as list of commands a command is represented as a list with at least 3 values: cmd = [ cmdname, cmdlabel, cmddesc ]
send_command(cmdname, args) method this method will actually execute the command
get_global_state() method returns three values:
state_dict():
dictionary with keys and boolean value indicating state of subsystem (on/off)
cmd_state_dict():
for every cmdname given in the data returned by get_cmd_info() this dictionary, indexed by cmdname, provides a boolean value to specify whether the commands is currently available for use or not.
message:
string containing meaningful information about operation, incidences or other
SIGNAL: globalStateChanged, (state_dict, cmd_state_dict, message). emit the same information as in get_global_state() at any time it changes
mxcube3 conforms to the the interface described above to propose a panel (in SampleChanger tab) that will adapt to that information. No assumption about a particular type of sample changer or command is done in that panel.
a SampleChangerMaintenance object has been added to the app state to include the information described above for the use of the app.
the following routes are available to check the information about at any moment. /mxcube/api/v0.1/sample_changer/get_global_state /mxcube/api/v0.1/sample_changer/get_maintenance_cmds /mxcube/api/v0.1/sample_changer/send_command/
(for now cmdparts only include a command name, not arguments are supported. If necessary this could be added in a later commit)
The SampleChanger container is now composed of three components. SampleChangerState: just showing the updated state of the SC hardware SampleChanger: contains refresh, scan buttons plus the new unload and abort buttons (depending on state) it also shows the sample tree from which to load individual samples manually SampleChangerMaintenance: gives acccess to other SC commands (as described in previous paragraph)