Documenting a conversation in passing with @tacaswell. I don't think work on this is imminent, but didn't want to forget about it:
Current Behavior
Plans are supposed to use Msg('configure', ...), as opposed to Msg('set', ...), to touch anything that involves configuration_attrs. Changes to those signals render the EventDescriptor's configuration metadata out of date, and the RunEngine needs to know that it should issue a fresh one for any future Events. To that end, RunEngine._configure updates its cache of EventDescriptors to remove any EventDescriptors that includes the relevant Device. There could be multiple streams involved. Then, next time the Device is create/read/saved, save sees that there is not EventDescriptor in the cache and makes one, as it would always do.
Proposed improvement
There are two big holes in this story:
It's easy for a plan author to forget to use 'configure' instead of 'set' . Most don't event know about this distinction.
Worse, it's easy to think of scenarios where the Device's configuration_attrs update due to external factors outside the plan's control.
Particularly due to (2) we need a way for the Device to tell the RunEngine, "My configuration has changed. You will need to issue a fresh EventDescriptor when/if I am read again." I imagine we would add some yet-specified new piece of ophyd API to support this communication and, ultimately, retire the 'configure' Message entirely. Plans can do all their setting with plain old 'set', which is easier for plan authors, and Devices can let the RunEngine know when configuration has changed, whether that changed was caused through the action of the plan or some external agent.
Documenting a conversation in passing with @tacaswell. I don't think work on this is imminent, but didn't want to forget about it:
Current Behavior
Plans are supposed to use
Msg('configure', ...), as opposed toMsg('set', ...), to touch anything that involvesconfiguration_attrs. Changes to those signals render the EventDescriptor's configuration metadata out of date, and the RunEngine needs to know that it should issue a fresh one for any future Events. To that end,RunEngine._configureupdates its cache of EventDescriptors to remove any EventDescriptors that includes the relevant Device. There could be multiple streams involved. Then, next time the Device is create/read/saved, save sees that there is not EventDescriptor in the cache and makes one, as it would always do.Proposed improvement
There are two big holes in this story:
Particularly due to (2) we need a way for the Device to tell the RunEngine, "My configuration has changed. You will need to issue a fresh EventDescriptor when/if I am read again." I imagine we would add some yet-specified new piece of ophyd API to support this communication and, ultimately, retire the 'configure' Message entirely. Plans can do all their setting with plain old 'set', which is easier for plan authors, and Devices can let the RunEngine know when configuration has changed, whether that changed was caused through the action of the plan or some external agent.