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.

Sign up for GitHub

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

Jump to bottom

PVA backend does not correctly handle long-string waveforms. #678

Open
jwlodek opened this issue Nov 26, 2024 · 3 comments · May be fixed by #682
Open

PVA backend does not correctly handle long-string waveforms. #678

jwlodek opened this issue Nov 26, 2024 · 3 comments · May be fixed by #682
Labels
bug Something isn't working

Comments

@jwlodek
Copy link
Member

jwlodek commented Nov 26, 2024

When attempting to connect to waveform records with the PVA backend, we get a type error:

NotConnected: 
manta_async: NotConnected:
    drv: NotConnected:
        nd_attributes_file: TypeError: XF:31ID1-ES{GigE-Cam:1}cam1:NDAttributesFile with inferred datatype Array1D[np.int8] from typeid='epics:nt/NTScalarArray:1.0' specifier='ab' cannot be coerced to str
    fileio: NotConnected:
        xml_file_name: TypeError: XF:31ID1-ES{GigE-Cam:1}HDF1:XMLFileName_RBV with inferred datatype Array1D[np.int8] from typeid='epics:nt/NTScalarArray:1.0' specifier='ab' cannot be coerced to str
        file_path: TypeError: XF:31ID1-ES{GigE-Cam:1}HDF1:FilePath_RBV with inferred datatype Array1D[np.int8] from typeid='epics:nt/NTScalarArray:1.0' specifier='ab' cannot be coerced to str
        file_name: TypeError: XF:31ID1-ES{GigE-Cam:1}HDF1:FileName_RBV with inferred datatype Array1D[np.int8] from typeid='epics:nt/NTScalarArray:1.0' specifier='ab' cannot be coerced to str
        file_template: TypeError: XF:31ID1-ES{GigE-Cam:1}HDF1:FileTemplate_RBV with inferred datatype Array1D[np.int8] from typeid='epics:nt/NTScalarArray:1.0' specifier='ab' cannot be coerced to str
        full_file_name: TypeError: XF:31ID1-ES{GigE-Cam:1}HDF1:FullFileName_RBV with inferred datatype Array1D[np.int8] from typeid='epics:nt/NTScalarArray:1.0' specifier='ab' cannot be coerced to str
        nd_attributes_file: TypeError: XF:31ID1-ES{GigE-Cam:1}HDF1:NDAttributesFile with inferred datatype Array1D[np.int8] from typeid='epics:nt/NTScalarArray:1.0' specifier='ab' cannot be coerced to str

This is because the type provided by PVA is an array of ints, rather than a string.

Steps To Reproduce

Steps to reproduce the behavior:

  1. Install ophyd async with p4p only.
  2. Attempt to connect to a waveform signal with FTVL= CHAR.

Acceptance Criteria

  • Can connect to waveform records as strings if FTVL=CHAR when using the PVA backend
@jwlodek jwlodek added the bug Something isn't working label Nov 26, 2024
@jwlodek
Copy link
Member Author

jwlodek commented Nov 26, 2024

Moving from slack to here for visibility.

After some investigation, it does not seem that a pvinfo on the record itself (or the VAL field) provides enough information to determine the type - instead we may need to explicitly pvget the .FTVL field. From here value.choices[value.index] will give us what we need. However, to avoid hanging/timeouts when this isn't needed, we need a way to filter signals we need to check this for.

@jwlodek
Copy link
Member Author

jwlodek commented Nov 26, 2024

I wonder if the correct approach to fixing this is actually to use Q:form, and make corresponding PRs to all of the upstream modules that we want to use this with.

@coretl
Copy link
Collaborator

coretl commented Nov 27, 2024 •
edited
Loading

I think the correct long term thing to do is convert areaDetector to either use lsi/lso records, or add Q:form to the existing waveform records.

After some investigation, it does not seem that a pvinfo on the record itself (or the VAL field) provides enough information to determine the type - instead we may need to explicitly pvget the .FTVL field. From here value.choices[value.index] will give us what we need. However, to avoid hanging/timeouts when this isn't needed, we need a way to filter signals we need to check this for.

In the short term I think the best thing to do is putting in the same fix as CA, in make_converter if datatype==str and PVA is NDArray[np.int8] NTScalarArray then make a PvaLongStrConverter and use that to do the conversion in ophyd. We don't need to get FTVL to get this information, PVA already tells us the type of the value field which is sufficient

We should add a test for this too in test/epics/signal/test_signals.py

@jwlodek jwlodek linked a pull request Nov 27, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
2 participants
@jwlodek @coretl