Overview

From Bruce Hill on March 2, 2023:

...

• the daq runs
• grafana works
• TIMETOOL still works

Matt writes about the GMD/XGMD variables above:  "Yes, these are the variables you describe (to determine the structure of the bld).  I think read only should be fine.  Also, I think pvget is expected to fail.  I think the proper access is something like pvinfo." (although cpo tried and couldn't get either pvget or pvinfo to work).  Matt later adds: "The PV is actually EM1K0:GMD:HPS:BLD_PAYLOAD which is still inaccessible.  I think that's because the accelerator doesn't yet have a PVA gateway.  Our bld process uses EPICS_PVA_ADDR_LIST=172.27.131.255 to access it directly" so the above entries in mcc-daq.pvlist are incorrect and can be removed completely.

Timetool arrays are in the cnf files.  This allows the drp process to write to the timetool variable hosted by the hutch.

(ps-4.6.3) tmo-daq:scripts> grep TTALL tmo.cnf
 { host: 'drp-srcf-cmp026', id:'tmo_atmopal_0', flags:'spu', env:epics_env, cmd:drp_cmd0+' -l 0x1 -D opal -k ttpv=TMO:TIMETOOL:TTALL'},
(ps-4.6.3) tmo-daq:scripts> 

Work on April 23, 2024

Zach and cpo removed the bld-payload variables above since they were spelled incorrectly, and don't need to be writeable from the DAQ.  Also removed the RIX:FIM:W8:03 since we believe that FIM as renamed to the CRIX fim.  Also removed tmo.pvlist:DAQ:TMO:HSD:1_DA.* since it is only for one channel.  Removed DET:*, *DRP.*, *DAQ:NEH.* (replaced the latter with DAQ:NEH:XPM) in drppvlist.

DAQ:NEH:tmo are the variables that Ric's prometheus exporter generates and are readable in tmo.pvlist.  Added DAQ:NEH:rix to rix.pvlist.  Restarted rix/tmo/drp/mcc-daq gateways.

Reliability

In May 2024 TMO was unable to successfully complete a scan: would fail around 30 steps.  Bypassing the gateway dramatically improved the situation.  Notified Zach of this issue.

Bypassing Gateways

Router work has been done to allow EPICS variables to be accessed using EPICS_CA_ADDR_LIST and EPICS_PVA_ADDR_LIST.  Some details are here: ACR Realtime Feedback#RouterChangesFeedback#RouterNetworkSupport

Change Requested by Tyler

On May 31, 2024

Hi Matt, Hi Chris, during the next PAMM, I would like to add the following rule to the DRP gateway configuration and reboot the gateway to pick up the new rule:
DAQ:NEH:XPM:0.*        ALLOW RWLAS
This would allow us to configure XPM0 from the laser subnet which would be much more convenient for our laser/timing operators. My intent is to have a script that programs our standard laser XPM0 configuration(s), and make this available to our laser operators via a button on a screen. This way if the laser operators see that the XPM configuration is gone (such as after a power outage) they can press this button and restore laser operation without the need to call me or Dring.