Adding enum attributes to PVI results in their keys being used instead of their values

[olliesilvester]

If I create an attribute which uses an Enum that I've created, for example:

class DetectorStatus(enum.StrEnum):
    IDLE = "Idle"
    ERROR = "Error"
    WAITING = "Waiting"
    RUN_FINISHED = "Run Finished"
    TRANSMITTING = "Transmitting"
    RUNNING = "Running"
    STOPPED = "Stopped"

and then

    trigger_mode = AttrRW(
        Enum(TriggerMode),
        handler=EnumHandler(TRIGGER_MODE_ENUM_MAPPING, TriggerMode, "timing"),
        group=MY_GROUP,
    )

and then my client (ophyd-async) uses PVI to see what choices this enum can have, it lists the keys of these enums rather than its values. For example, when I try to connect to this device using the following enum in ophyd-async,

class DetectorStatus(StrictEnum):
    IDLE = "Idle"
    ERROR = "Error"
    WAITING = "Waiting"
    RUN_FINISHED = "Run Finished"
    TRANSMITTING = "Transmitting"
    RUNNING = "Running"
    STOPPED = "Stopped"

ophyd-async gives the following error

TypeError: LAB29-JUNGFRAU:DetectorStatus has choices ('Idle', 'Error', 'Waiting', 'RunFinished', 'Transmitting', 'Running', 'Stopped'), but <enum 'DetectorStatus'> requested ['IDLE', 'ERROR', 'WAITING', 'RUN_FINISHED', 'TRANSMITTING', 'RUNNING', 'STOPPED'] to be strictly equal to them.

I would have expected the choices to be the Enum values rather than the keys

Acceptance Criteria

• FastCS creates PVI for enum signals using the enum values

[GDYendell]

@coretl we will have to discuss how resolve this inconsistency between FastCS and ophyd-async. As we discussed before, I think FastCS has to use the value of the enum for the string (or other) that is sent to / received from the hardware, so the key is the user friendly mapping that appears on the UI and the in PVI structure. I don't know if there is a way around this.

In this case the value is a nice human readable string, but that will not be the case for all drivers where it could be obscure strings, ints, hex, or anything else the vendors decided would be a good idea. I would say that the FastCS enum should be this:

class DetectorStatus(enum.StrEnum):
    Idle = "Idle"
    Error = "Error"
    Waiting = "Waiting"
    RunFinished = "Run Finished"
    Transmitting = "Transmitting"
    Running = "Running"
    Stopped = "Stopped"

On the ophyd-async side is it the same: the key is the user friendly name and the value is what is sent to the IOC? If so then maybe this makes sense as they are conceptually the same thing and the ophyd async is the next layer in the mapping from the user to the hardware.

[olliesilvester]

The behaviour I would have expected is for the UI to use the enum human readable keys, but the actual PV values to be the enum values. Instead, if I understand correctly, it seems like the fast-cs enum values aren't actually used at all?

[GDYendell]

I think this is how it works currently:

• The EPICS CA record uses 0,1,2,... as the value of the record and "Idle","Run Finished",... (the enum key) as the name
• The UI displays the name
• caput takes either the integer or the name
• caput calls the EPICS CA callback with the integers and these are converted to enums to poke the attribute with (here)
• FastCS sends "Idle", "Run Finished" (the enum value) to the device

[olliesilvester]

• FastCS sends "Idle", "Run Finished" (the enum value) to the device

Hmm.. I think it can't send the values directly because of #173. But if FastCS is sending the enum value to the device, then why does ophyd-async need to use the enum keys?

[GDYendell]

Well, in any specific driver handler.put method you just get called with the attribute, so you could do whatever you want at that point - send the key, the value, or anything.

[coretl]

I think it's reasonable for FastCS and ophyd-async to have different behaviour here:

# FastCS
class DetectorStatus(Enum):
    StringForUI = "VALUE FOR DEVICE"

# ophyd-async
class DetectorStatus(StrictEnum):
    STRING_FOR_LOGIC = "StringForUI"

If we want spaces in the strings for the UI then we could do:

# FastCS
DetectorStatus = Enum({"String For UI": "VALUE FOR DEVICE"})

# ophyd-async
class DetectorStatus(StrictEnum):
    STRING_FOR_LOGIC = "String For UI"

What do you both reckon?

[olliesilvester]

I vote to allow for spaces in the UI

[GDYendell]

We could potentially convert PascalCase to Title Case for choices, as we do for labels, but maybe that is less clear what is going on

[coretl]

We could potentially convert PascalCase to Title Case for choices, as we do for labels, but maybe that is less clear what is going on

Yeah, I think being explicit makes more sense here