search

pcdshub / pcdsdevices

Collection of Ophyd device subclasses for IOCs unique to LCLS PCDS.
https://pcdshub.github.io/pcdsdevices/
Other
5 stars 59 forks source link

EpicsSignal Description #293

Closed teddyrendahl closed 3 years ago

teddyrendahl commented 6 years ago

Many of our EPICS records have helpful information in their .DESC field. It would be nice if this information bubbles up when you ask EpicsSignal.describe just like the limits and units do. Unfortunately, this information isn't available without making another PV connection. This is true all the way down to the pyepics level.

I think that part of the issue is that while all records have a .DESC field, a generic PV will not.

PYEPICS Exploration

```python In [2]: pv = epics.PV('MFX:TFS:MMS:21') In [3]: pv._args Out[3]: {'access': 'read-only', 'char_value': '123.0', 'chid': 43954256, 'count': 1, 'enum_strs': None, 'ftype': 20, 'host': 'pscag2-dev.slac.stanford.edu:38653', 'lower_alarm_limit': None, 'lower_ctrl_limit': None, 'lower_disp_limit': None, 'lower_warning_limit': None, 'nanoseconds': 341194000, 'nelm': 1, 'posixseconds': 1536001064.0, 'precision': None, 'pvname': 'MFX:TFS:MMS:21', 'read_access': True, 'severity': 0, 'status': 0, 'timestamp': 1536001064.341194, 'type': 'time_double', 'typefull': 'time_double', 'units': None, 'upper_alarm_limit': None, 'upper_ctrl_limit': None, 'upper_disp_limit': None, 'upper_warning_limit': None, 'value': 123.0, 'write_access': False} ```

Placing this here for discussion after an email conversation with @koglin
ZLLentz commented 6 years ago

In some sense it's strange that the dbr_ctrl structures in EPICS don't have any sort of string description. I think that's the root of the question here. The .DESC cannot be assumed of an arbitrary EpicsSignal, and ophyd tries really hard to not assume things: everything is explicit. I have to wonder if we should have an LCLSDevice mix-in with fields like .DESC, .DISP, etc.

klauer commented 3 years ago

I agree that this would be nice, but it isn't feasible (well, easy) to have optional .DESC fields on EpicsSignals.

A Device to do the same could be an option as @ZLLentz suggested above, but then it would no longer be a valid signal and have a confusing API.

Based on my knowledge of the underlying bits of ophyd, I'm going to close this one as the balance of "complexity vs gain" is heavily weighed in the direction of "complexity".

If you disagree or see this in the future and really want this, feel free to re-open the issue and explain why.