Mono gets stuck when attempting to move to current energy

[prjemian]

From APS 4-ID-C Polar (APS-4ID-POLAR/ipython-polar#52 (comment)),

[the EPICS monochromator code] gets stuck in moving if you try to move to the same energy.

See this animated graphic to reproduce:

Pressing the Move button unsticks it. Is there a way to fix in the monochromator support code here? The current behavior jams up Bluesky control. (Bluesky could add a check if the move is trivial and then avoid asking EPICS to set the energy to the same value.)

[gfabbris]

Should we ask somebody in particular about this?

[mdwyman]

Both the MOVE button and the BraggEAO PVs have a forward link that sets the Mono's busy record to "Moving". However, the SNL program is where the busy records is "un-set" (i.e. to "Done"). The Move button activation does trigger it's associated SNL program variable so eventually the busy record completes. Since the Energy isn't changed, it doesn't trigger the SNL monitor, so the the busy record is never completed.

If the MDEL field of the BraggEAO PV is set to -1, the SNL monitor will trip. MDEL is the monitor deadband and by default it's set to 0, so monitors are only processed if value is changed. When set to -1, monitors are processed every time the record is processed not just when the value is changed.

[mdwyman]

Not sure what the other repercussions of setting MDEL to -1 are, but since it seems to only affect Bluesky/ophyd operations, maybe part of the bluesky session startup/instrument initialization be to set MDEL = -1?

[prjemian]

I can check in my simulator/softIoc.

[prjemian]

I was able to reproduce the mono getting stuck with a softIoc without using Bluesky.

• Set to Auto
• set energy to 5.0
• wait
• for move to complete (IOC:KohzuMoving is clear)
• set energy to 5.0 (again)
• IOC:KohzuMoving is stuck
• Press Move button
• IOC:KohzuMoving is clear

[prjemian]

Should resolve this in the sequence program.

[mdwyman]

I was able to reproduce the mono getting stuck with a softIoc without using Bluesky.

• Set to Auto
• set energy to 5.0
• wait
• for move to complete (IOC:KohzuMoving is clear)
• set energy to 5.0 (again)
• IOC:KohzuMoving is stuck
• Press Move button
• IOC:KohzuMoving is clear

Yes, but how is setting IOC:BraggEAO.MDEL = -1 not a viable solution?

I was also able to get similar behavior for the Lambda and Theta positioners: set lambda (or theta) value, then set it to the same value, system gets stuck in Moving mode; Move clears it. Again setting MDEL = -1 for the positioners seems to fix.

With MDEL = 0, the monitor is never set when the energy (or lambda/theta) is set (again) to it's current value, so it wouldn't matter the method of interaction (bluesky, caqtdm, camonitor, etc). With MDEL = -1, the monitor is updated (can be seen with camonitor)

Looking at the sequence program, it's dependent on the energy (or lambda/theta) PV setting a monitor. Changes to both the sequence program and database would be needed to flag the PV being set with an old value when in "Auto" mode.