Closed ambarb closed 6 years ago
That's a wild one! I want to understand if the plan skipped over these points (it's hard to imagine how that could happen) or if LiveTable/LivePlot merely failed to display them. What does db['84b2bf'].table()
return?
The data is in the database.
As verified in https://github.com/NSLS-II/bluesky/issues/829
In [39]: db['84b2bf'].table()
Out[39]:
time epu2_gap_readback epu2_gap_setpoint \
seq_num
1 2017-09-09 12:29:16.069764 30.559230 30.063875
2 2017-09-09 12:29:17.431385 30.554365 30.116507
3 2017-09-09 12:29:18.625158 30.554272 30.169138
4 2017-09-09 12:29:19.825968 30.554230 30.221770
5 2017-09-09 12:29:21.060551 30.554187 30.274402
6 2017-09-09 12:29:22.437309 30.553115 30.327033
7 2017-09-09 12:29:23.638357 30.552965 30.379665
8 2017-09-09 12:29:24.840091 30.552875 30.432296
9 2017-09-09 12:29:26.048319 30.552782 30.484928
10 2017-09-09 12:29:27.441708 30.552360 30.537559
11 2017-09-09 12:29:28.644210 30.552306 30.590191
12 2017-09-09 12:29:29.831919 30.552285 30.642823
13 2017-09-09 12:29:31.037143 30.552272 30.695454
14 2017-09-09 12:29:32.448842 30.552307 30.748086
15 2017-09-09 12:29:33.646418 30.552448 30.800717
16 2017-09-09 12:29:34.841456 30.552627 30.853349
17 2017-09-09 12:29:36.053238 30.552755 30.905980
18 2017-09-09 12:29:37.451394 30.554461 30.958612
19 2017-09-09 12:29:38.648582 30.554475 31.011244
20 2017-09-09 12:29:39.841663 30.554485 31.063875
epu2_gap_stop_signal sclr_ch1 sclr_ch2 sclr_ch3 sclr_ch4 \
seq_num
1 0 50000005.0 1982.0 46.0 31.0
2 0 50000005.0 2017.0 45.0 31.0
3 0 50000005.0 2175.0 45.0 31.0
4 0 50000005.0 2109.0 46.0 31.0
5 0 50000005.0 1997.0 45.0 30.0
6 0 50000005.0 2041.0 46.0 30.0
7 0 50000005.0 2041.0 46.0 31.0
8 0 50000005.0 2032.0 46.0 31.0
9 0 50000005.0 2126.0 45.0 31.0
10 0 50000005.0 2050.0 45.0 31.0
11 0 50000005.0 1935.0 44.0 31.0
12 0 50000005.0 2010.0 46.0 31.0
13 0 50000005.0 2009.0 46.0 31.0
14 0 50000005.0 2246.0 46.0 32.0
15 0 50000005.0 2145.0 46.0 30.0
16 0 50000005.0 2137.0 47.0 31.0
17 0 50000005.0 2004.0 46.0 31.0
18 0 50000005.0 2030.0 46.0 31.0
19 0 50000005.0 1919.0 46.0 31.0
20 0 50000005.0 1815.0 46.0 31.0
sclr_ch5 sclr_ch6 sclr_time
seq_num
1 1362.0 0.0 1.0
2 1362.0 0.0 1.0
3 1360.0 0.0 1.0
4 1359.0 0.0 1.0
5 1358.0 0.0 1.0
6 1358.0 0.0 1.0
7 1360.0 0.0 1.0
8 1364.0 0.0 1.0
9 1366.0 0.0 1.0
10 1367.0 0.0 1.0
11 1367.0 0.0 1.0
12 1366.0 0.0 1.0
13 1370.0 0.0 1.0
14 1371.0 0.0 1.0
15 1371.0 0.0 1.0
16 1372.0 0.0 1.0
17 1372.0 0.0 1.0
18 1373.0 0.0 1.0
19 1373.0 0.0 1.0
20 1362.0 0.0 1.0
I attribute the missing rows in LiveTable to the progress bar try to clean up after itself (i.e., clear itself off the screen) and accidentally take a row of the table with it. But the underlying issue is the epu_gap failing to move and also failing to report that problem correctly.
@cmazzoli @wen-hu @stuwilkins @irawaluyo @adhuntbnl be aware that this happened to the epu.
@danielballan you are suggesting we either change our profile or look into the ioc, right. As such, we can close this and and open a report on https://github.com/NSLS-II-CSX/xf23id1_profiles/issues/5
Yes.
This one is some what odd and not at all reproducible as I successfully completed a gap scan before and after the bad scan [82887). The same command was entered each time. The second scan [82887] didnt even drive epu gap to the requested position.