Make useful scripts into a dodal utility

[stan-dot]

          Tagging @stan-dot as this is general good info. So to look up the type of a PV I do the following:

• python2 /dls_sw/work/useful-scripts/find-pv.py BL20I-EA-DET-06:ERASE
• This showed me the PV was defined in /dls_sw/work/R3.14.12.7/support/BL20I-BUILDER/iocs/BL20I-EA-IOC-05/db/BL20I-EA-IOC-05_expanded.db as a bo record.
• EPICS record types are documented at https://epics.anl.gov/base/R3-15/7-docs/RecordReference.html
• If you look at https://epics.anl.gov/base/R3-15/7-docs/boRecord.html you can see that bo records take values of 0 or 1, but they can define ZNAM and ONAM which are user friendly names for the 0/1 states
• So if we do:

  $ caget BL03I-EA-XSP3-01:ERASE.ZNAM BL03I-EA-XSP3-01:ERASE.ONAM
  BL03I-EA-XSP3-01:ERASE.ZNAM    
  BL03I-EA-XSP3-01:ERASE.ONAM    

  We can see that both are blank compared to a PV of the same type I found elsewhere:

  $ caget BL03I-MO-SGON-01:CS1:DeferMoves.ZNAM BL03I-MO-SGON-01:CS1:DeferMoves.ONAM
  BL03I-MO-SGON-01:CS1:DeferMoves.ZNAM Defer Off
  BL03I-MO-SGON-01:CS1:DeferMoves.ONAM Defer On

• Given they're both blank this is why your string enum complains if they're anything else. Obviously this won't actually work in production as if you set blank on the PV how does it know which one you actually need?

So, we have some choices:

1. Talk to controls and ask them to provide named states for the PV, or change the PV to a type that is more appropriate
2. Use an int - This will work but is a bit of a shame as it's not super clear that writing 1 to the erase is what you want to do
3. Use an IntEnum e.g.

   class EraseEnum(int, Enum):
   ERASE = 1
   DONE = 0

   But are you saying that didn't work? In which case we should probably open a discussion up about if this is a bug in ophyd_async

I prefer option 1 but it will be the most work. I can live with option 2 for now in the interests of just getting things done, maybe we can then put in a ticket with controls to improve it at a later date

_Originally posted by @DominicOram in https://github.com/DiamondLightSource/dodal/pull/524#discussion_r1621993932_

[stan-dot]

@DominicOram what do you think?

[DominicOram]

I think it needs wider discussion with controls about what they see the future of PV discover-ability being. find-pv has a number of issues currently that a future script would probably want to fix:

• It's python 2
• It depends on the current file system structure (I assume it will not discover any containerised IOCs running in k8s)
• It doesn't pick up any python IOC PVs

I think trying to put it in dodal as is is wasted effort which we should instead put into a full solution. However, I suspect that full solution will require some effort and is not yet a prioirity

[stan-dot]

@marcelldls , @coretl what do you think? since we already have device detection in dodal with dodal-conenct, the channel-specific logic sounds like could live quite near it.

OTOH maybe this is a non-issue, obsolesced by argocd?

still argocd only is set to go to 3 beamlines by the dark period, so there would be a stream of value from having the support for the existing non-containerized IOCs too

[coretl]

I see no reason to touch find-pv at the moment, it will soon become obsolete when we have containerised all the IOCs. This will be solved in the future by https://channelfinder.github.io/ but I'm not sure as yet where or how it will run. @MJGaughran may have more ideas.

[stan-dot]

will soon become obsolete when we have containerised all the IOCs

if I remember right, last time I spoke with @gilesknap this was years away, that at the moment we're less than 1/3rd through

[coretl]

will soon become obsolete when we have containerised all the IOCs

if I remember right, last time I spoke with @gilesknap this was years away, that at the moment we're less than 1/3rd through

Yes, and we have find-pv for the interim...