Skip to content
This repository has been archived by the owner on Nov 3, 2021. It is now read-only.

abort of external macro #1606

Open
kklmn opened this issue Jun 6, 2021 · 3 comments
Open

abort of external macro #1606

kklmn opened this issue Jun 6, 2021 · 3 comments

Comments

@kklmn
Copy link

kklmn commented Jun 6, 2021

Hi,

If I create a door object as door = taurus.Device(my/door/path) and then run a macro as door.runMacro(my_macro_str), the macro executor in Taurus GUI doesn't change its buttons: the stop button remains gray and the Run button remains green. So there is no way to abort the macro. The State LED goes to blue though.

I think the macro executor should react also to externally started macros, not only to those started from within its widget.

Thank you, as always!

@reszelaz
Copy link
Collaborator

reszelaz commented Jun 8, 2021

Hi @kklmn,

We were discussing it in #1109 starting from this #1109 (comment) (there are also some interesting comments in continuation, sorry, but these are mixed with the PR review comments).

I do not have a strong opinion on how these widgets should behave. Before we decide to change/maintain the current behavior I will try to post here the consequences of both options.

I will come back to this issue (and others you've posted recently) after Thursday's Sardana follow-up meeting - I'm a bit busy these days.

Cheers

@kklmn
Copy link
Author

kklmn commented Jun 9, 2021

Hi @reszelaz,

Thank you for pointing to the old discussion in #1109!

I think much of that discussion has a very abstract ground; people probably assume that there will be several competing operators that start various spock sessions. In my reality, this is never the case: the beamline operator is always one person at a time. So if I want to abort a scan, I do want to abort it. And it is indeed confusing when I start it in one widget (terminal) and cannot abort from another one connected to the same door. @stanislaw55 says exactly the opposite with no explanation about his confusion of what with what.

I can reduce my opinion on macro controlling to this sentence:
If a widget (terminal) reacts on the macro, e.g. prints the door output, the same widget, or a near widget, should be able to abort it. For example, the Sardana/Taurus macro executor is near the DoorOutput widget.
And inversely, abortion should be ignored if the output is silent to the macro.

More explanation:
I have beamline optimization widgets on one screen (8 screens in total). On another screen is my plotting tool and the standard Taurus Sardana integration widgets including DoorOutput. When I start an optimization macro, I look at the plots and DoorOutput. Because my focus is already there, aborting is easier from that screen. Certainly, I can put abortion buttons in my widgets, this is just against users' and my intuition.

@kklmn
Copy link
Author

kklmn commented Sep 10, 2021

if there are two opposite opinions on the issue, should there be a corresponding user option?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants