Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG/MNT: properly handle string PVs #91

Open
tangkong opened this issue Sep 30, 2024 · 3 comments
Open

BUG/MNT: properly handle string PVs #91

tangkong opened this issue Sep 30, 2024 · 3 comments

Comments

@tangkong
Copy link
Contributor

Current Behavior

Currently fetching some string PVs returns non-string data

Expected Behavior

If we request a string we should get a string

Context / environment

Playing around with tables and ran into this.

This is something that ophyd also has to deal with, and solves by having the user explicitly request a string. (this is an EPICS problem generally. aioca claims to use the "natural channel data type" if no datatype is specified, but I don't know what this means and it clearly doesn't work

I imagine this is a slightly less common use case for superscore, as string data isn't the first thing you think of as a configuration to restore. But it's something we should support

Steps to Reproduce (for bugs)

  1. cl = ControlLayer()
  2. cl.get("IM1L0:XTES:MMS:STATE:ERRMSG_RBV")

Suggested Solution

add a string: bool field to Parameter, and also add handling to these fields in our tables.

For aioca specifically we can do:
await caget("PV:NAME", datatype=dbr.DBR_CHAR_STR)
where dbr is from epicscorelibs. There are a couple different character types that I don't quite understand fully, but we'll have to disambiguate them

@ZLLentz
Copy link
Member

ZLLentz commented Sep 30, 2024

The most common case where ophyd/aioca/etc. need help is when we're using an array of integers to mean a string. This is done in EPICS because native string types have fairly small length limits (usually 40 or 60 characters).

Note that these sorts of PVs (CHAR type with element count > 1) are very rarely writeable.

There might also be some user decision needed for enums...

@tangkong
Copy link
Contributor Author

If you grab the FORMAT_CTRL fields for an enum, aioca (at least) will provide the enum strings. I was using this to infer that a PV is an enum, is this not a reliable source of information?

@ZLLentz
Copy link
Member

ZLLentz commented Sep 30, 2024

It should be ok, I was just noting that these are the two cases where the user might want a str representation of their data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants