Open ambarb opened 8 years ago
attn @klauer @stuwilkins this look the issue is in ophyd.commands.mov
and/or the IOC that is running the mono.
When you are using mov
you are not using the runengine at all (which is why ^C does not quite work as expected and abort
is always raising that the runegine is in a paused state).
You should probaly be writting this as:
def CuEscan():
# I assume this just turns on the active feedback loop?
MonoClosedLoop()
yield from bp.sleep(1)
yield from ascan(pgm_en,920,960,40, md={'plan_name':'CuEscan'})
yield from bp.abs_set(pgm_en, gs.PS.max[0]-1.4, wait=True)
yield from bp.sleep(2)
RE(CuEscan())
I like what you did with md. Are you saying that I can ^C if I write the definition in the way you propose or is this the way you would write it?
From: Thomas A Caswell [notifications@github.com] Sent: Sunday, June 05, 2016 1:42 PM To: NSLS-II/Bug-Reports Cc: Barbour, Andi; Author Subject: Re: [NSLS-II/Bug-Reports] Killing motion because gs.PS issue with mov() and the problems it caused. Bluesky and CSS report different pgm_en. (#113)
attn @klauerhttps://github.com/klauer @stuwilkinshttps://github.com/stuwilkins this look the issue is in ophyd.commands.mov and/or the IOC that is running the mono.
When you are using mov you are not using the runengine at all (which is why ^C does not quite work as expected and abort is always raising that the runegine is in a paused state).
You should probaly be writting this as:
def CuEscan():
MonoClosedLoop()
yield from bp.sleep(1)
yield from ascan(pgm_en,920,960,40, md={'scantype':'CuEscan'})
yield from bp.abs_set(pgm_en, gs.PS.max[0]-1.4, wait=True)
yield from bp.sleep(2)
RE(CuEscan())
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NSLS-II/Bug-Reports/issues/113#issuecomment-223826510, or mute the threadhttps://github.com/notifications/unsubscribe/AM_7GaUWtLZl6q3UTSu0lV9b6eN_MJD5ks5qIwptgaJpZM4IuRtD.
^C will behave in a more consistent way this way, but I strongly suspect that the IOC that is running your mono is having issues (which is the source of all of those user warnings) and things at the ophyd/bs layer are not doing a good enough job coping with the hardware not operating properly.
I'm more inclined to believe this is a pyepics poor cache handling-related issue masquerading as a timeout error. I wish we had something repeatable to test, as I don't really see anything in this report I can use...
This is a bit convoluted. I set up a definition.
Executed it, and after the scan finished the energy was in a trapped state (no prompt return) 100eV away from where it should be (unexpected energy for this case). I fear that I should have added a wait time for the gs.PS to be calculated. I was doing this manually with no issues.
This is where it was hung and oscillating around 840 eV (pgm_en) so I ^C^C^C. The bluesky printed 840ish. Did not look to see what PV (CSS screen) read as energy.
That aborted ok. Now see if PS is okay ,and it is. Then commanded to move where I want pgm_en
Bluesky went crazy and this is where I could not get the command prompt back without the timeout messages.
Eventually those timeout messages stop (
ca.get
is back). Cursor is also gone. This is not the first time that the cursor has disappear. Have to restart collection to get it back when this happens, but I did not do that here as I wanted to see what was happening with the first issue.Kept trying to move the energy in bluesky and still getting stuck. Bluesky pgm_en and CSS pgm_en do not match. Energy Scan status is "moving' even thought the motors are just in a stabilized mode. Able to get a screenshot (1st image). At that time, the time out measages happned all in a row and ended on their own. Now Bluesky and CSS match. Took a screen capture of this (second attachment). I have olog entries of these. Search "crazyenergy" in olog (commissioning).
This has happened to @cmazzoli a few times as well. I am not sure how he resolved it.