Repeat exact scan using header recorded in olog

[ambarb]

@tacaswell mentioned that I could repeat an exact scan by copying/pasting the text under To Call: into BS. For our beamline (and many others), this isn't exactly correct. The header doesn't capture the position of other motors during the initial scan. For any given scan at CSX1, the following motors should be captured (in addition to the scanned motor)

Essential for recreating reciprocal space position: theta, delta, gamma, pgm_energy (assuming undulatory is linked) (eventually mu but not now)

Essential for recreating the previous scan EXACTLY - except for polarization: (may not be worth the trouble and could be too inflexible, opinions for @stuwilkins and @cmazzoli) theta, delta, gamma, pgm_energy (assuming undulatory is linked), npbx, npby, npbz, nptx, npty, nptz, sx, say, saz.

I think first option could be the most flexible and would get used more often. The user can keep track of the other things.

[cmazzoli]

Correct! That's the reason the very same motors (as indicated in your option #1) are currently appended in gs.DETS by our config files (under the profile folder of python, I believe in 99-bluesky.py or similar).

[danielballan]

So perhaps the Olog should have two sections, Commands To Put Your Beamline in the Same State and Command to Reproduce the Scan? Users can decide how much of the state they want to reproduce.

[danielballan]

...sound good?

[stuwilkins]

Andi .. great idea.

All… We should also have a look at MASAR. This was a tool developed by the machine for save/restore of state of a system commanded by EPICS. This could be very nicely used to capture the state of a beam line as Andi suggests and restore it. This is somewhat what I had intended with the “log_pos” and always wanted a “restore” functionality to go along with that. Lets talk.

S

On Aug 13, 2015, at 4:42 PM, Dan Allan notifications@github.com<mailto:notifications@github.com> wrote:

So perhaps the Olog should have two sections, Commands To Put Your Beamline in the Same State and Command to Reproduce the Scan? Users can decide how much of the state they want to reproduce.

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/wishlist/issues/31#issuecomment-130834709.

[danielballan]

@stuwilkins That sounds great. We'll naturally want something at the Python level that captures all of that plus any state that is not known to EPICS. Bluesky must never assume EPICS, but should fully support it.

[stuwilkins]

Agreed 100%. lets try to find a good policy and engineering way to do this. To be able to record, compare and restore state in bluesky would be awesome.

S On Aug 13, 2015, at 7:10 PM, Dan Allan notifications@github.com<mailto:notifications@github.com> wrote:

@stuwilkinshttps://github.com/stuwilkins That sounds great. We'll naturally want something at the Python level that captures all of that plus any state that is not known to EPICS. Bluesky must never assume EPICS, but should fully support it.

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/wishlist/issues/31#issuecomment-130874355.

[ghost]

We, FRIB, and SLAC use channel finder and MASAR for this purpose in the accelerator middle layer.

@shengb and I added mongo as an option for masar backend before he left. They are all stable and come with python apis and cs-studio guis. Please look into these so that we don't have another rampingManager disaster in our hands.

http://www.aps.anl.gov/epics/meetings/2013-10/3%20-%20Other%20Services/4%20-%20MASAR%20Service.pdf

http://www.aps.anl.gov/epics/meetings/2013-10/3%20-%20Other%20Services/2%20-%20ChannelFinder.pdf

[stuwilkins]

rampingManager???

S On Aug 13, 2015, at 10:00 PM, Arman Arkilic notifications@github.com<mailto:notifications@github.com> wrote:

We, FRIB, and SLAC use channel finder and MASAR for this purpose in the accelerator middle layer.

@shengbhttps://github.com/shengb and I added mongo as an option for masar backend before he left. They are all stable and come with python apis and cs-studio guis. Please look into these so that we don't have another rampingManager disaster in our hands.

http://www.aps.anl.gov/epics/meetings/2013-10/3%20-%20Other%20Services/4%20-%20MASAR%20Service.pdf

http://www.aps.anl.gov/epics/meetings/2013-10/3%20-%20Other%20Services/2%20-%20ChannelFinder.pdf

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/wishlist/issues/31#issuecomment-130919808.

[ghost]

@stuwilkins it is a cautionary tale. A few thousand PVs are arbitrarily read/set all over the accelerator in order to determine/restore machine status to ramp the power supplies for the booster. BINP folks wrote that and insisted they don't want to use masar so they did their own terrible thing. I drew the short straw and had to fix it once...

[tacaswell]

On the other hand, this is going to be ~dozen objects, not thousands.

I suspect that we are going to end up with objects at the python level which are pseudo/composite motors which enforce constraints on the underlying PVs or are abstracted up a few layers. In either case the interesting values to record are what the python objects think the state is, not the underlying PVs. On restore we are going to want to launder all of those moves through the python logic, not just resetting the underlying PVs.

[ghost]

These services scale nicely so that does not matter. Also, a complex object can have thousands of PVs that are required to reproduce the same event. Accelerator folks use masar in the fashion you describe. They have their own python or matlab(yes, matlab lol) logic that has similar sort of abstraction to yours. Before you dismiss the suggestion, I recommend you look into ways it is utilized(there are 7 python apis so one of them should work for you :dart: ). The accelerator is a very complex system and resurrecting it requires a tool that does much more than "resetting underlying PVs".