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
I have the impression the modern waveform record offers itself to be dynamically changed for both its length (through the NORD field) and its type (through the FTVL field) and it would be nice to see the client adapting. What I noticed, though, is the following:
If FTVL is USHORT, pydm will use 32-bit ndarray instead of 16-bit (note: this is the case when using ca:// while pva:// uses 16-bit ndarrays instead and that feels the correct behavior).
If FTVL is UCHAR, pydm will use 8-bit array but the display then doesn't seem to work correctly with ca:// (note: the display looks ok when using pva:// with 8-bit arrays).
Nor ca:// or pva:// seem to be able to adapt dynamically when FTVL changes and they maintain the data type they found when the connection was established.
Do you think it would be appropriate for pydm to be able to dynamically adapt to a changing FTVL or, for cameras, to a changing pixel format? Does areadetector change FTVL on the fly?
Thank you for looking at this,
Amedeo
The text was updated successfully, but these errors were encountered:
I have the impression the modern waveform record offers itself to be dynamically changed for both its length (through the NORD field) and its type (through the FTVL field) and it would be nice to see the client adapting. What I noticed, though, is the following:
Do you think it would be appropriate for pydm to be able to dynamically adapt to a changing FTVL or, for cameras, to a changing pixel format? Does areadetector change FTVL on the fly?
Thank you for looking at this,
Amedeo
The text was updated successfully, but these errors were encountered: