You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently you can pass general information to the datatypes, e.g Bool(znam="1", onam="1") or Float(prec=0). We need to be able to add epics specific information too, for example EGU, DESC.
I suggest that we create a new optional kwarg on either the datatypes or attributes:configuration=. This will be an child of a new abstract class to describe further information about the datatype. Then in the epics backend we can check for this (an EpicsIntConfiguration and set our sub fields on the record accordingly).
I would say egu and description should both be first-class members of Attribute. I would like to avoid passing around a dict of EPICS fields that don't mean anything to other backends.
I suppose egu will have to live in Float and Int since it's an aIn/aOut/longIn/longOut specific field. I'll make a new branch and use my best judgement as to what should live where.
I think we shouldn't couple it to what EPICS does - backend would still be able to only pass through egu for the record types that support it. But yes, in this case egu on string and bool would never make sense, so I think you are right it needs to go on the type.
Currently you can pass general information to the datatypes, e.g
Bool(znam="1", onam="1")
orFloat(prec=0)
. We need to be able to add epics specific information too, for exampleEGU
,DESC
.I suggest that we create a new optional kwarg on either the datatypes or attributes:
configuration=
. This will be an child of a new abstract class to describe further information about the datatype. Then in the epics backend we can check for this (anEpicsIntConfiguration
and set our sub fields on the record accordingly).@GDYendell
The text was updated successfully, but these errors were encountered: