new trait supports-collect-measured #21
Conversation
for more information, see https://pre-commit.ci
|
Not sure how this can work. One would need to clear out the spooler/buffer or overwrite old entries. But how would one know when to do that, esp. if multiple clients are open and are polling differently? |
|
Great question @kameyer226. Clearing old measurements from memory is entirely at the discretion of the daemon. Each daemon will have some number of measurements cached and when the client sends In a multiclient scenario there's no difference, really. The daemon shouldn't clear the cache just because a client read from it. In this way this is different from the Bluesky Flyer interface. In the Python implementation I'm imagining the cache implemented using a Of course, this is just the beginning of this suggestion! I'm open to change the design. |
|
Note to self, I guess you might need to collect mappings as well. Frustrating because the traits collide a little bit. I guess collect mapping could be another trait entirely. |
|
Sounds great Blaise! A few questions:
|
|
|
||
| This trait adds the method `collect_measured`. This method returns an avro array of arrays, where each inner array contains exactly two items: a unix timestamp float and the associated measurement as an avro map. Bluesky users can think of this as a list of readings. | ||
|
|
||
| `collect_measured` accepts one optional argument, `measurement_id`, an integer with default of `null`. If a client provides this argument, the daemon will return only measurements since that id, inclusive. Because each measurement mapping already contains `measurement_id` as specified by the is-sensor trait, there is no ambiguity if clients need to cross-reference to ids. Daemons must account for overflow of `measurement_id`. |
There was a problem hiding this comment.
What is the standard behavior of collect_measured with no argument? All measurements are returned? The last measurement is returned?
There was a problem hiding this comment.
My idea is that all the messages in the cache would be returned. I suppose we could have a second optional argument of max_measurements with default of zero meaning "all".
|
|
||
| # Motivation | ||
|
|
||
| Some experiments incorporate sensors that are very fast or very slow compared to other pieces of hardware being controlled. In such cases it might be natural to let the sensor run asyncronously with other hardware, simply recording each time there is a new sensor reading. Unfortunately, the design of the "get_measured" message defined by is-sensor does not make asyncronus acquistion easy. Clients must ensure that they are polling quickly in order to ensure they don't miss measurements. In extreme cases, sensors are so fast that client polling is simply not practical. |
There was a problem hiding this comment.
Just to make sure I am understanding the application, this is most useful for when sensors are very fast? Does this trait also offer advantages when sensors are very slow?
There was a problem hiding this comment.
I agree it's most useful for very fast things.
For very slow things it's also great, because you just don't have to poll.
It's useful for any measurement that's fundamentally asynchronous with your central datastream.
|
|
||
| This trait adds the method `collect_measured`. This method returns an avro array of arrays, where each inner array contains exactly two items: a unix timestamp float and the associated measurement as an avro map. Bluesky users can think of this as a list of readings. | ||
|
|
||
| `collect_measured` accepts one optional argument, `measurement_id`, an integer with default of `null`. If a client provides this argument, the daemon will return only measurements since that id, inclusive. Because each measurement mapping already contains `measurement_id` as specified by the is-sensor trait, there is no ambiguity if clients need to cross-reference to ids. Daemons must account for overflow of `measurement_id`. |
There was a problem hiding this comment.
Consider allowing negative integers as an argument; e.g. collect_measured(-2) will grab the last two measurements?
There was a problem hiding this comment.
That would work, as an alternative to my suggestion of a max_measurements argument above...
I think I like it.
|
Thanks for your comments @ukurumbail
Unfortunately I have to give the frustrating answer of "maybe". Some daemons will have such a parameter, but many might not. I'd rather leave it up to each daemon, because there are often hardware limitations that make the parameterization of collection rate special.
My imagination with auto_rxn is that this would be a separate stream. Just as you imagine it. |
Co-authored-by: Daniel Kohler <[email protected]>
Co-authored-by: Kyle Sunden <[email protected]>
I'm sure I've made a bunch of small errors, but I think this gets the idea down.
I'd like some comments from the community, and then I'm going to go ahead and implement this in yaqd-core-python.
I believe the Python implementation should be as simple as a mix-in class. Should be pretty easy to add to any existing sensor daemon.