DETMON: Board temperature available as PVs

[JamesKingWork]

As someone supporting the detectors at ISIS I want to be able to ensure temperatures of my crates are within safe ranges. My remote working workflow is to monitor the temperature and contact MCR if there is a problem.

Acceptance criteria:

The HVCAEN IOC has the temperature available for each board in a crate. Alarms should be placed on the temperature PV. Temperature changes of greater than 1 degrees should be logged.

Notes

1. This fulfils a part of the criteria of DETMON: Board parameters available as PVs #4187 but is more important for remote working so has been split off
2. The vendor code should be checked to see if this has been implemented before doing so ourselves
3. If this cannot be undertaken via the dll in the same way as the channel information, the OPC version of the IOC should be considered, but this should be generated as a new ticket and added to the umbrella ticket Detector HV/HT/CAEN Monitoring - DETMON #4178
4. See Detmon for background information/more details if required

[DominicOram]

This requires code changes and #5069 is to do an actual release to DETMON so presumably makes sense to do this one first?

[JamesKingWork]

#5069 is not to do a release (this was done in another ticket and I will remove it from the acceptance criteria). So all is needed is config changes, I don't think either needs to hold up each other.

[DominicOram]

Had a quick look between tickets. It appears you can use CAENHV_GetBdParamProp and CAENHV_GetBdParamInfo to get the temperatures, see page 10/11 of https://github.com/ISISComputingGroup/EPICS-HVCAENx527/blob/master/HVCAENx527App/src/CAENHVWrapper/HV%20Wrapper_REV10.pdf

[DominicOram]

So https://github.com/slac-epics-modules/CAENHVAsyn seems to potentially already have this functionality, it's also an ASYN driver rather than a old style driver so should be a bit easier to maintain. I'm not sure I know enough about these devices to decide whether switching driver is a good idea at this point, will open to wider discussion.

[DominicOram]

Decision is to try the new driver on DETMON and see if it's stable

[DominicOram]

PRs at:

• Ticket 5544: Monitor board temperatures CAENHVAsyn#1
• https://github.com/ISISComputingGroup/EPICS/pull/239
• Ticket5544: monitor board temperatures EPICS-ioc#564

Also made a number of pull requests at https://github.com/slac-epics-modules/CAENHVAsyn/pulls for original library.

This exposes the temperature as a PV an alarm can be put on it by setting LLM/HLM at runtime or using the alerts system. It also exposes the last 3 parameters listed at #4187 and all of those at #4188. To test ask me for the IP address of a test crate.

Further issues have also been created for this IOC:

• CAEN: Deploy new IOC to DETMON #5962
• CAEN: Create emulator and tests #5963
• CAEN: Create OPI #5961

[DominicOram]

Davide is setting up a board in a failure state on Monday so we can test the board status more.

[JamesKingWork]

As part of the review, make a note if this may have fixed or changed the details of:

• DETMON: Archive the PVs in the IOC #4185
• DETMON: Crate parameters available as PVs #4188
• DETMON: Alias the IOC PVs to be easily readable #4186
• DETMON: Board parameters available as PVs #4187

[JamesKingWork]

Updated docs at https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/CAEN

[JamesKingWork]

Currently impeded waiting for the CAEN to be turned back on. Initial investigation showed discrepancies between the values given by the old and new iocs.

[JamesKingWork]

Crate is back on, but the new IOC now can't seem to talk to it. The old IOC can though.

[JamesKingWork]

The new driver now seems to talk happily to the CAEN crate. The new driver's code is much cleaner and more extensible than the older driver however I have some reservations to keep an eye on:

• there are some discrepancies in the values given between the drivers, though generally, the new driver gives more values which could be promising
• the new driver did fail to connect at one point to a crate which the old driver could connect to (I did not manage to find the reason)
• the amount of logs produced when the failed connection occurred was a lot higher than the old driver

The decision is to approve and merge the new driver and have a test run on DETMON and reduce logging: #6158 and #6159