HIFI: Investigate Litron Laser

[kjwoodsISIS]

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

1. Discover if there is any technical documentation for the laser (maybe the manufacturer can supply it).
2. A wiki page in the IBEX Developer's Manual describing how the Litron Laser operates and how it is used.
   • Add a link to this documentation from the HIFI Instrument wiki.
3. The wiki page should cover (at a minimum) the following 3 areas
   • Laser Client
   • Laser Power
   • Laser Timing
4. Create additional tickets (if required) to implement support for the Litron Laser.
   • Laser Timing is likely to be the feature of the laser that most needs control from IBEX (the others may only need to be controlled via the laser's own control PC). Ticket #6090 (for HIFI: IOC & OPI for Litron Laser Timing Control) already exists.

Notes

1. Click Litron Lasers to visit the manufacturer's web-site.
2. The existing VIs are located
   • here: C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser and
   • here: C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser Power and
   • here: C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser Timing.
3. The Laser Client VI (in 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).
4. The Laser Power module appears to refer to a picomotor device (see 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

[KathrynBaker]

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:

Values to read regularly (LVGET)

Control Name	Data Type	PV Name(s)	Notes
Wavelength	Double	LASER:WL
OPOCrystalPosition	Double	LASER:OPO:CRYS:POS
Distance	I32	LASER:OPO:CRYS:DIST

Values to write when asked (LVPUT)

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.

[KathrynBaker]

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.

[KathrynBaker]

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
• both of these are multiplied by 1e6, to give dA_0 (usec) and dC_0 (usec) respectively
• both are added together to give the Summed Delay (usec) When a delay is set:
• mode, offset, and delay are all taken from the front panel controls
• The delay and offset are summed to give a summed value
• If the mode is 0 then we can consider this a failure state
• If the mode is 1:
  • dlay? C is read, this is multiplied by 1e6, and the summed value is added to it
  • if that total is >39900 or the summed value is <0 this is a failure state, otherwise it is a success.
• If the mode is 2:
  • dlay? C is read, this is multiplied by 1e6, and the summed value is added to it
  • if that total is <= 0 or the summed value is >39900 this is a failure state, otherwise it is a success.
• If this is a failure state the backgrounds of the variables are turned red
• If things are successful then the following are done in this order
  • DISP 11,2 is sent
  • dlay A,T0,us,{val} is sent where {val} is set to the summed value
  • *CLS is sent When a mode is set:
• If the mode is Auto (value of 0):
  • If the delay is greater than the absolute of the offset, use Mode 1
  • Otherwise use Mode 2
• If the mode is Mode 1:
  • *RCL 1 is sent - this recalls the settings in location 1
• If the mode is Mode 2:
  • *RCL 2 is sent - this recalls the settings in location 2

A 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.

[LowriJenkins]

The Acceptance criteria suggests the creation of a wiki, has one been created or has it been decided that it wasn't nesecary?