Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HIFI: Investigate Litron Laser #6089

Closed
kjwoodsISIS opened this issue Jan 11, 2021 · 7 comments
Closed

HIFI: Investigate Litron Laser #6089

kjwoodsISIS opened this issue Jan 11, 2021 · 7 comments
Assignees
Labels
3 no_release_notes Tickets that do not need release notes, use sparingly!

Comments

@kjwoodsISIS
Copy link
Contributor

kjwoodsISIS commented Jan 11, 2021

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.
  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 HIFI: IOC & OPI for Litron Laser Timing Control #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 HIFI: IOC & OPI for Litron Laser Timing Control #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
Copy link
Member

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:
image

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:
image

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 KathrynBaker self-assigned this May 8, 2024
@KathrynBaker KathrynBaker added 3 no_release_notes Tickets that do not need release notes, use sparingly! labels May 8, 2024
@KathrynBaker KathrynBaker added this to the SPRINT_2024_05_02 milestone May 8, 2024
@github-actions github-actions bot added the ready label May 8, 2024
@KathrynBaker KathrynBaker moved this to In Progress in PI_2024_02 May 8, 2024
@github-actions github-actions bot added in progress and removed ready labels May 8, 2024
@KathrynBaker
Copy link
Member

KathrynBaker commented May 8, 2024

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:
image
Whilst the specific commands and orders could be traced, it is unlikely to be beneficial.

@KathrynBaker
Copy link
Member

What is in C:\LabVIEW Modules\Instruments\HIFI\HIFI Laser Timing
This is all interactions with a DG645
The front panel looks like this:
image

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
Loading

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
Copy link
Contributor

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

@github-project-automation github-project-automation bot moved this from Review to Done in PI_2024_02 May 10, 2024
@esmith1729
Copy link
Contributor

LVRemote uses both IND (indicator) macro and CONTROL macro, does "Control Name" refer to both of these, or only CONTROL macro?

@LowriJenkins
Copy link
Contributor

From what I remember, CONTROL was used to generate the setpoint, i.e. points to the name of the input (control) box on the VI, and indicator is used to generate te readback, i.e. points to the name of the output (indicator) value on the vi.

@LowriJenkins
Copy link
Contributor

if a vi only has a single display for a value (i.e. what you right to, and read from are the same) then ind and control can be the same value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 no_release_notes Tickets that do not need release notes, use sparingly!
Projects
No open projects
Status: Done
Development

No branches or pull requests

4 participants