feat(set_gem_timing): allowing operators to switch between HXR-GEM SC and NC timing with a one line script

[joshc-slac]

Adding what should be a temporary hack script but may be somewhat long lived to provide a one line mechanism for operators to switch the timing paradigm on the HXR-GEM. This script:

• Sets PV: KFE:CAM:TPR:02:MODE to either SC or NC
• Invokes imgr to set the GEMs IOC version to the correct version for the corresponding timing paradigm

Invokation once sourced is of form: set_gem_timing [scheme] Schemes besides NC and SC will be rejected.

Associated PR: https://github.com/pcdshub/IocManager/pull/9

Description

The set_gem_timing bash script critically:

• Sets PV: KFE:CAM:TPR:02:MODE to either SC or NC
• Invokes imgr to set the GEMs IOC version to the correct version for the corresponding timing paradigm

Argument and State Parsing

• Input validates that only 1 argument is supplied and that argument is either SC or NC
• Will fail if KFE:CAM:TPR:02:MODE is already in whatever mode is trying to be actuated
• Will fail if imgr --info determines that the requested software is already on the device

Motivation and Context

Ticket ECS-3765 requests a script to switch timing of the HXR-GEMs for the NC and SC timing schemas.

For the SC timing schema the crate that contains the HXR-GEM cannot be upgraded (or is prohibitively expensive to upgrade) which means the non SLAC EVR cannot receive / decode LCLS2 timing pulses.

To circumvent this Silke hardwired the LCLS2 timing signal from the IM2K0 to the HXR-GEM enabling LCLS2 timing to be passed to the L, hard x-ray, side of things. This means that as long as the hack exists and we want to collect SC (LCLSII) data on the HXR-GEM we need to toggle the IOC software to be the one that ignores timing and triggers when the IM2K0 camera triggers and we need a mechanism to toggle it back when we want to send NC beam to the HXR-GEM and get the additional information (timestamps) provided by actually going through the EVR on the crate.

This toggle can be accomplished manually:

• From machine in the CA network: caput KFE:CAM:TPR:02:MODE X where X == NC or SC
  • I have heard but not confirmed this sets a bunch of PVs to predetermined values
• Switch the running software via imgr
  • ioc/fee/GasDetDAQ/R4.0.22 <- for NC
  • ioc/fee/GasDetDAQ/R4.0.22-NOTS <- SC

This script aims to deprecate both manual mechanisms GUI and CLI in switching between timing paradigms in favor of a one line command. This command can be plumbed into a button if desired.

How Has This Been Tested?

• Josh has used it to switch timing paradigms for ACR for the evening shift on 9/6 and both shifts on 9/7.

TODO:

• [x] this has all been from Josh's user account
  • [x] check permissioning works as intended on operator account
  • [x] determine if sourcing should be handled by operator or this script
• [x] Upgrade the imgr instance for the lfe hutch to contain changes made in https://github.com/pcdshub/IocManager/pull/9
• [x] I would like to remove the absolute filepaths; but I would like to do it in a way thats principic to the rest of our system, someone will likely have to show me how we do it here

Where Has This Been Documented?

• https://confluence.slac.stanford.edu/display/PCDS/IocManager+R2-5-0

[ZLLentz]

Also, an aside: thank you for being detailed and clear in the PR description here, it made it much easier to understand the intent of the code. I think the script is overall very good.

[ZLLentz]

I would not be opposed to a merge if the intent is "get the script out now, working, with a tagged version". I only found one potential edge case, which technically shouldn't ever happen.

[joshc-slac]

Following up on the remaining TODO:

Based on this slack feedback it seems operators do not normally operate with dotfiles sourced.

This makes sense, so I will make the script source the needed elements for them so it is truly a one stop shop. I have scheduled time with ACR to observe them using this tooling. Planning on closing this out after that confirmation.

[joshc-slac]

Following up on the remaining TODO:

Based on this slack feedback it seems operators do not normally operate with dotfiles sourced.

This makes sense, so I will make the script source the needed elements for them so it is truly a one stop shop. I have scheduled time with ACR to observe them using this tooling. Planning on closing this out after that confirmation.

Following up on this. Ran through utilizing this with ACR. Scripts seem sufficient for their needs.

There was a lingering complaint about ssh-tunneling. This could be resolved given sufficient GUI

[silkenelson]

Following up on the remaining TODO: Based on this slack feedback it seems operators do not normally operate with dotfiles sourced. This makes sense, so I will make the script source the needed elements for them so it is truly a one stop shop. I have scheduled time with ACR to observe them using this tooling. Planning on closing this out after that confirmation.

Following up on this. Ran through utilizing this with ACR. Scripts seem sufficient for their needs.

There was a lingering complaint about ssh-tunneling. This could be resolved given sufficient GUI

I would skip that. If ACR wants it more convenient, they can make take are of it - I believe Matt Gibbs made them something easier for the PMPS GUI.