State Mover Function Blocks

[nrwslac]

Optics State Mover FBs should be moved to and called from the optics library.

[nrwslac]

_Originally posted by @nrwslac in https://github.com/pcdshub/lcls-plc-tmo-optics/pull/32#discussion_r1116320401_

[nrwslac]

I guess it isn't possible to re-use state mover function blocks for similar devices with different state enumeration types. By design the state move function blocks declare an enum type. @ZLLentz @klauer any thoughts about this?

[ZLLentz]

iirc the declaration of the enum type (instead of say, just making it an integer) was to make pytmc pick up the enum strings for use in the IOC. If there's some other/better way of accomplishing that I'm all ears, I'm not satisfied with what we currently need to do to prop up a new state mover that just differs by an enum.

[klauer]

Right - the enum lets pytmc:

• Pick the right record type (mbbi, mbbo)
• Know the right values (integers in the enum)
• Know a more user-friendly value for each of those integers (the enum name / string identifier)

In terms of auto-generation by introspecting standard code structures, I think the enum is the best we can do. It does fail us in that sometimes we want better string identifiers for each of the values, though.

I'm not sure what would be better - and it if would be worth complicating pytmc to account for it. I'd be open to new proposals, of course.

[ZLLentz]

There may be ways to reorganize the motion library code so that you only need to provide and pragma an enum and you don't need to do anything special in the function block. But yeah I don't think there's a way to get around the enum that isn't messier when we bubble up to the IOC.