docs: Update device list
This commit is contained in:
ci_update_bot
@@ -14,8 +14,15 @@
|
||||
| aa1GlobalVariables | Global variables<br><br> This class provides an interface to directly read/write global variables<br> on the Automation1 controller. These variables are accesible from script<br> files and are thus a convenient way to interface with the outside word.<br><br> Read operations take as input the memory address and the size<br> Write operations work with the memory address and value<br><br> Usage:<br> var = aa1Tasks(AA1_IOC_NAME+":VAR:", name="var")<br> var.wait_for_connection()<br> ret = var.readInt(42)<br> var.writeFloat(1000, np.random.random(1024))<br> ret_arr = var.readFloat(1000, 1024)<br><br> | [tomcat_bec.devices.aerotech.AerotechAutomation1](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/aerotech/AerotechAutomation1.py) |
|
||||
| aa1Tasks | Task management API<br><br> The place to manage tasks and AeroScript user files on the controller.<br> You can read/write/compile/execute AeroScript files and also retrieve<br> saved data files from the controller. It will also work around an ophyd<br> bug that swallows failures.<br><br> Execution does not require to store the script in a file, it will compile<br> it and run it directly on a certain thread. But there's no way to<br> retrieve the source code.<br><br> Write a text into a file on the aerotech controller and execute it with kickoff.<br> '''<br> script="var $axis as axis = ROTY\nMoveAbsolute($axis, 42, 90)"<br> tsk = aa1Tasks(AA1_IOC_NAME+":TASK:", name="tsk")<br> tsk.wait_for_connection()<br> tsk.configure({'text': script, 'filename': "foobar.ascript", 'taskIndex': 4})<br> tsk.kickoff().wait()<br> '''<br><br> Just execute an ascript file already on the aerotech controller.<br> '''<br> tsk = aa1Tasks(AA1_IOC_NAME+":TASK:", name="tsk")<br> tsk.wait_for_connection()<br> tsk.configure({'filename': "foobar.ascript", 'taskIndex': 4})<br> tsk.kickoff().wait()<br> '''<br><br> | [tomcat_bec.devices.aerotech.AerotechAutomation1](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/aerotech/AerotechAutomation1.py) |
|
||||
| aa1TaskState | Task state monitoring API<br><br> This is the task state monitoring interface for Automation1 tasks. It<br> does not launch execution, but can wait for the execution to complete.<br> | [tomcat_bec.devices.aerotech.AerotechAutomation1](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/aerotech/AerotechAutomation1.py) |
|
||||
| EpicsMotorEC | Detailed ECMC EPICS motor class<br><br> Special motor class to provide additional functionality for ECMC based motors. <br> It exposes additional diagnostic fields and includes basic error management.<br> | [tomcat_bec.devices.psimotor](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/psimotor.py) |
|
||||
| EpicsMotorMR | Extended EPICS Motor class<br><br> Special motor class that exposes additional motor record functionality.<br> It extends EpicsMotor base class to provide some simple status checks <br> before movement.<br> | [tomcat_bec.devices.psimotor](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/psimotor.py) |
|
||||
| EpicsMotorX | Special motor class that provides flyer interface and progress bar. | [tomcat_bec.devices.aerotech.AerotechAutomation1](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/aerotech/AerotechAutomation1.py) |
|
||||
| GigaFrostCamera | Ophyd device class to control Gigafrost cameras at Tomcat<br><br> The actual hardware is implemented by an IOC based on an old fork of Helge's<br> cameras. This means that the camera behaves differently than the SF cameras<br> in particular it provides even less feedback about it's internal progress.<br> Helge will update the GigaFrost IOC after working beamline.<br> The ophyd class is based on the 'gfclient' package and has a lot of Tomcat<br> specific additions. It does behave differently though, as ophyd swallows the<br> errors from failed PV writes.<br><br> Parameters<br> ----------<br> use_soft_enable : bool<br> Flag to use the camera's soft enable (default: False)<br> backend_url : str<br> Backend url address necessary to set up the camera's udp header.<br> (default: http://xbl-daq-23:8080)<br><br> Bugs:<br> ----------<br> FRAMERATE : Ignored in soft trigger mode, period becomes 2xExposure time<br> | [tomcat_bec.devices.gigafrost.gigafrostcamera](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/gigafrost/gigafrostcamera.py) |
|
||||
| GigaFrostClient | Ophyd device class to control Gigafrost cameras at Tomcat<br><br> The actual hardware is implemented by an IOC based on an old fork of Helge's<br> cameras. This means that the camera behaves differently than the SF cameras<br> in particular it provides even less feedback about it's internal progress.<br> Helge will update the GigaFrost IOC after working beamline.<br> The ophyd class is based on the 'gfclient' package and has a lot of Tomcat<br> specific additions. It does behave differently though, as ophyd swallows the<br> errors from failed PV writes.<br><br> Parameters<br> ----------<br> use_soft_enable : bool<br> Flag to use the camera's soft enable (default: False)<br> backend_url : str<br> Backend url address necessary to set up the camera's udp header.<br> (default: http://xbl-daq-23:8080)<br><br> Usage:<br> ----------<br> gf = GigaFrostClient(<br> "X02DA-CAM-GF2:", name="gf2", backend_url="http://xbl-daq-28:8080", auto_soft_enable=True,<br> daq_ws_url="ws://xbl-daq-29:8080", daq_rest_url="http://xbl-daq-29:5000"<br> )<br><br> Bugs:<br> ----------<br> FRAMERATE : Ignored in soft trigger mode, period becomes 2xexposure time<br> | [tomcat_bec.devices.gigafrost.gigafrostclient](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/gigafrost/gigafrostclient.py) |
|
||||
| GrashopperTOMCAT | <br> Grashopper detector for TOMCAT<br><br> Parent class: PSIDetectorBase<br><br> class attributes:<br> custom_prepare_cls (GrashopperTOMCATSetup) : Custom detector setup class for TOMCAT,<br> inherits from CustomDetectorMixin<br> cam (SLSDetectorCam) : Detector camera<br> image (SLSImagePlugin) : Image plugin for detector<br> | [tomcat_bec.devices.grashopper_tomcat](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/grashopper_tomcat.py) |
|
||||
| SLSDetectorCam | <br> SLS Detector Camera - Grashoppter<br><br> Base class to map EPICS PVs to ophyd signals.<br> | [tomcat_bec.devices.grashopper_tomcat](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/grashopper_tomcat.py) |
|
||||
| SLSImagePlugin | SLS Image Plugin<br><br> Image plugin for SLS detector imitating the behaviour of ImagePlugin from<br> ophyd's areadetector plugins.<br> | [tomcat_bec.devices.grashopper_tomcat](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/grashopper_tomcat.py) |
|
||||
| StdDaqClient | StdDaq API<br><br> This class combines the new websocket and REST interfaces of the stdDAQ that <br> were meant to replace the documented python client. The websocket interface<br> starts and stops the acquisition and provides status, while the REST<br> interface can read and write the configuration. The DAQ needs to restart<br> all services to reconfigure with a new config.<br><br> The websocket provides status updates about a running acquisition but the <br> interface breaks connection at the end of the run.<br><br> The standard DAQ configuration is a single JSON file locally autodeployed<br> to the DAQ servers (as root!!!). It can only be written through a REST API <br> that is semi-supported. The DAQ might be distributed across several servers, <br> we'll only interface with the primary REST interface will synchronize with <br> all secondary REST servers. In the past this was a source of problems.<br><br> Example:<br> '''<br> daq = StdDaqClient(name="daq", ws_url="ws://xbl-daq-29:8080", rest_url="http://xbl-daq-29:5000")<br> '''<br> | [tomcat_bec.devices.gigafrost.stddaq_client](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/gigafrost/stddaq_client.py) |
|
||||
| StdDaqPreviewDetector | Detector wrapper class around the StdDaq preview image stream.<br><br> This was meant to provide live image stream directly from the StdDAQ.<br> Note that the preview stream must be already throtled in order to cope<br> with the incoming data and the python class might throttle it further.<br><br> You can add a preview widget to the dock by:<br> cam_widget = gui.add_dock('cam_dock1').add_widget('BECFigure').image('daq_stream1')<br> | [tomcat_bec.devices.gigafrost.stddaq_preview](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/gigafrost/stddaq_preview.py) |
|
||||
| StdDaqRestClient | Wrapper class around the new StdDaq REST interface.<br><br> This was meant to extend the websocket inteface that replaced the documented<br> python client. It is used as a part of the StdDaqClient aggregator class. <br> Good to know that the stdDAQ restarts all services after reconfiguration.<br><br> The standard DAQ configuration is a single JSON file locally autodeployed<br> to the DAQ servers (as root!!!). It can only be written through the REST API <br> via standard HTTP requests. The DAQ might be distributed across several servers, <br> we'll only interface with the primary REST interface will synchronize with <br> all secondary REST servers. In the past this was a source of problems.<br><br> Example:<br> '''<br> daqcfg = StdDaqRestClient(name="daqcfg", rest_url="http://xbl-daq-29:5000")<br> '''<br> | [tomcat_bec.devices.gigafrost.stddaq_rest](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/gigafrost/stddaq_rest.py) |
|
||||
| TomcatAerotechRotation | Special motor class that provides flyer interface and progress bar. | [tomcat_bec.devices.tomcat_rotation_motors](https://gitlab.psi.ch/bec/tomcat_bec/-/blob/main/tomcat_bec/devices/tomcat_rotation_motors.py) |
|
||||
|
||||
Reference in New Issue
Block a user