Closed kjwoodsISIS closed 3 months ago
What is in C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser
The Main front panel here interacts with vendor DLLs, this should be left as is during migration
The client uses the same mechanism as was developed in #8264 to talk to that remote VI
It is suggested that this can be achieved by generating some appropriate substitution files (extending the data types in the templates if needed), and creating an OPI
The VI refered to is C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser\HIFI Laser - FrontPanel.vi
The Front Panel of the VI is:
The following would match the PVs more readily, but if the scientists want to maintain the "impression" of just setting a value, then this will need to be done at the IOC level not the GUI level:
Control Name | Data Type | PV Name(s) | Notes |
---|---|---|---|
Wavelength | Double | LASER:WL | |
OPOCrystalPosition | Double | LASER:OPO:CRYS:POS | |
Distance | I32 | LASER:OPO:CRYS:DIST |
Control Name | Data Type | PV Name(s) | Notes |
---|---|---|---|
OPONudgeDistance | I32 | LASER:OPO:CRYS:NUDGE:DIST | The absolute value should be sent at this point, if the scientists do not want to consider this as an absoulte value then the IOC will need to use this to trigger on to records which will send this absolute value, and the appropriate nudge direction as per the next two commands and present a single control to the user of the distance |
btnNudgeOPOUp | Integer | LASER:OPO:CRYS:NUDGE:UP | This would be a trigger to send a specific value of 1, it should not be a value that changes and maintains a state |
btnNudgeOPODown | Integer | LASER:OPO:CRYS:NUDGE:DN | This would be a trigger to send a specific value of 1, it should not be a value that changes and maintains a state |
Note that the PV Names suggested have not been checked against the standards, and are likely to be too long.
What is in C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser Power
This is interacting with a motor controller, that already has support in the motor record.
Making sure that this type interacts with the motor controller in question, and that there is an appropriate OPI is probably what is needed for this part of the laser system.
The manual is in the usual place, use a sub path of \New Focus\Intelligent_Picometer
and the files is called 15242.pdf
.
The motor record in question is https://github.com/epics-motor/motorNewFocus
Existing interaction looks like this:
Whilst the specific commands and orders could be traced, it is unlikely to be beneficial.
What is in C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser Timing
This is all interactions with a DG645
The front panel looks like this:
Behind the scenes this looks complicated, but it isn't too bad, it's all queued events. The basic structure of the interactions is as follows:
stateDiagram-v2
s1 : Set Display
s2 : Set Delay
s3 : Set Mode
s4 : Clear Error
s5 : Read Offsets
s6 : Status
s7 : Check and Set Delay
u1 : UI Timeout (every 250ms)
u2 : Set Delay requested
u3 : Set Mode requested
state if_state <<choice>>
u1 --> s5 : Regular Update
u2 --> s7 : Mode, Delay and Offset values from the controls
u3 --> if_state
if_state --> s3 : Mode 0, delay > absolute offset = Mode 1
if_state --> s3 : Mode 0, delay <= absolute offset = Mode 2
if_state --> s3 : Mode 1
if_state --> s3 : Mode 2
s7 --> s1 : Success
s1 --> s2 : Success, val = offset + delay
s2 --> s4 : Success
s7 --> s6 : Failure = Red, Success = Grey
In a few more words and with commands: Every 250ms the offsets are read:
dlay? A
is sent followed by dlay? C
dA_0 (usec)
and dC_0 (usec)
respectivelySummed Delay (usec)
When a delay is set:summed value
dlay? C
is read, this is multiplied by 1e6, and the summed value
is added to itsummed value
is <0 this is a failure state, otherwise it is a success. dlay? C
is read, this is multiplied by 1e6, and the summed value
is added to itsummed value
is >39900 this is a failure state, otherwise it is a success. DISP 11,2
is sentdlay A,T0,us,{val}
is sent where {val}
is set to the summed value
*CLS
is sent
When a mode is set:Auto
(value of 0):
Mode 1
Mode 2
Mode 1
:
*RCL 1
is sent - this recalls the settings in location 1Mode 2
:
*RCL 2
is sent - this recalls the settings in location 2A look at the commands for the DG645 didn't show anything as simple as this being used, and nothing at all for these commands or variations of them. Working on this will probably need some checking of the DG645 and then implementation of the above behaviours in some form.
The Acceptance criteria suggests the creation of a wiki, has one been created or has it been decided that it wasn't nesecary?
As a developer, I need to understand how the Litron Laser device (used on HIFI) operates and how it is used by scientists, so that I can create an appropriate control system for it.
Acceptance Criteria
Notes
C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser
andC:\LabVIEW Modules\Instruments\HIFI\HIFI Laser Power
andC:\LabVIEW Modules\Instruments\HIFI\HIFI Laser Timing
.C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser
) is very complex and is suggestive of a manufacturer's VI. It may be that the Litron Laser is controlled by its own PC (running the manufacturer's VI). It seems quite possible that SECI's communication with the Litron Laser may be handled via the HIFI Laser Timing VI (meaning that #6090 is the only ticket that needs to be implemented).C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser Power\Documentation\15242.pdf
for details)To review
This is hard to review, without redoing the work done, please instead look at the comments below, note that tickets have been updated/created to move this work forward in a slightly more reasonable fashion when it comes time to migrate HIFI. So please check that the tickets exist and refer back to the comments below. Tickets updated:
6090
Tickets Created:
8331
8332