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

read_configuration executes a second reading of the signal? #1179

Open
A-D-Fuchs opened this issue Mar 12, 2024 · 1 comment
Open

read_configuration executes a second reading of the signal? #1179

A-D-Fuchs opened this issue Mar 12, 2024 · 1 comment

Comments

@A-D-Fuchs
Copy link

We are currently writing custom signals that inherit from ophyds Signal and SignalRO.

We noticed that the first time we read the signal, the read operation is performed twice. This seems to be due to the function read_configuration here. This reads the signal a second time after it was read intentionally the first time, executing any code that is run when the signal is read again.
This is not a problem if it is an EPICS Signal, but as our "read" is a long execution (reading from a spectrometer) this is not ideal.
Is there a reason for this second read execution that we are missing?
Our current workaround is that we overwrite the read_configuration function for our inherited signals.

Any clarification on this would be great. Thank you.

@tacaswell
Copy link
Contributor

short answer: That is fine so long as you never want to use that signal with kind 'config'.

slightly longer answer: when we run down the read_configuration tree we do not differentiate on the type of device that we are recursing on. If Signal (which is the leaf of the Device tree) did not have the same read and read_configuration methods then you would never actually be able to get any configuration values out! I suspect this double read is coming from something like RE(bp.count([my_sig]))?

Slightly hacky suggestion:

class Dev(Device):
    cpt = Cpt(MySigClass, ..., kind='normal')

my_sig = Dev(...)

which (without testing) I think will avoid the double reading.

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