-
Notifications
You must be signed in to change notification settings - Fork 18
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
LiveTable failed to format row #331
Comments
Pretty sure this has something to do with keeping the same type throughtout the scan. It seems LiveTable detects the data types when it receives a descriptor document, then expects those types to remain the same throughout the run. Integers can be formatted as floats, but not the other way around. Simply put, if For example the following succeeds since we saw a float first: In [51]: list1 = [-1., -0.1, 0, 0.1, 1]
...: RE(bp.list_scan([det], motor, list1))
Transient Scan ID: 11 Time: 2022-04-21 15:35:13
Persistent Unique Scan ID: 'd0916d6a-f755-46e1-9506-20dadfd0822a'
New stream: 'primary'
+-----------+------------+------------+------------+
| seq_num | time | motor | det |
+-----------+------------+------------+------------+
| 1 | 15:35:13.6 | -1 | 0.607 |
| 2 | 15:35:13.6 | -0.1 | 0.995 |
| 3 | 15:35:13.7 | 0 | 1 |
| 4 | 15:35:13.7 | 0.1 | 0.995 |
| 5 | 15:35:13.7 | 1 | 0.607 |
+-----------+------------+------------+------------+
generator list_scan ['d0916d6a'] (scan num: 11) But the this fails because the float values cannot be formatted as integers (mind the definition of In [2]: list1 = [-1, -0.1, 0, 0.1, 1]
...: RE(bp.list_scan([det], motor, list1))
Transient Scan ID: 1 Time: 2022-04-21 15:37:07
Persistent Unique Scan ID: '96158fdf-e5fc-439c-9d19-e893f5896e0e'
+-----------+------------+------------+------------+
| seq_num | time | motor | det |
+-----------+------------+------------+------------+
| 1 | 15:37:07.0 | -1 | 0.607 |
failed to format row
| 3 | 15:37:07.9 | 0 | 1 |
failed to format row
| 5 | 15:37:07.9 | 1 | 0.607 |
+-----------+------------+------------+------------+
generator list_scan ['96158fdf'] (scan num: 1) The adaptive scan plan can solved in a similar way if you start at |
That's a really interesting find. We could sort of patch around this in an interface layer, probably. I wonder if this would motivate a change on the |
A bit of a rant: On the ophyd side, if |
It looks like what ophyd does is So then a place this might happen more often is with I wonder if having a James's problem happened with |
This was ambiguously-worded on my part:
I meant more that it's the Signal's job to be consistent about its underlying data type, not that there's a bug in the describe/read mechanism.
In normal operating circumstances, for a Channel Access, this can really only happen if the IOC goes down and comes back up with a different type. Reasonably rare, but not impossible. The archiver appliance has issues with this as a client, requiring manual intervention in my past experience.
Those signals should probably be
Hmm, this is definitely a code path I didn't foresee... I could be wrong, but here's my take.
It does seem like |
I didn't mean to suggest that you thought there was a bug in describe/read, I was just trying to work through the code path to figure out in which circumstances we could be ending up with inconsistent typing. |
Expected Behavior
Live table shouldn't fail to format a row.
Current Behavior
LiveTable occasionally has issues formatting rows. We saw this first in a slack thread James Cryan in
bp.list_scan
.Later seen by me in
bp.adaptive_scan
This does not stop the scan from running, just breaks the terminal outputs. Originates from this exception catch.
Possible Solution
??? Possibly something to do with floats and ints?
Steps to Reproduce (for bugs)
RE(bp.list_scan([daq], photon_energy, list1))
(resolved by defining the list as floats, not int)
Context
Your Environment
pcds-5.3.1
The text was updated successfully, but these errors were encountered: