New mode for Boolean Button

[georgweiss]

Suggesting the following new operational mode for the Boolean Button widget.

The current push mode could be extended to support a heartbeat case. If user defined frequency >0 then use heartbeat, i.e. send 1 (or 0 in inverse mode) repeatedly, otherwise send only once. Behavior when user releases button unchanged. A new widget property for the frequency is needed, default 0, max 10 (?). Toggle mode would ignore the frequency property.

Motivation:
Boolean buttons are used to move a motor, when user releases button, 0 is sent to PV to abort movement. But if the widget looses connection to PV, the motor will continue movement. Developers solve this potential "run amok" situation by adding a heartbeat PV used to check that Phoebus is still connected to IOC. This creates a dependency to an OPI script.

[kasemir]

The UI should not perform any automation.
User pushes a button, and the UI sends a value, soon. Operators can tell if/when it happened because some related PV will update. Write something to a motor, and the motor position PV should change in the near future. Or some limit switch indicator will light up. But expecting the UI to keep sending a value every second is a form of automation within the UI, which we want to avoid. Yes, a UI can become disconnected, get restarted, be opened multiple times or not at all. That needs to be anticipated.

The motor record by itself is prepared for this.
It offers a setpoint: Write desired position, and it tries to get there via acceleration curve, retries, backlash compensation, checking soft and hard limits etc. Once you write the desired position, there is no need to stay connected, the motor record can safely perform the move on its own.
In addition, there are "jog" fields: Write to them, and the motor goes forward or backwards by a predefined distance. Again once you start the jog, there is no need to stay connected, the motor record can safely perform the move on its own.

Sounds like you added something to the IOC where writing "RUN" to the IOC keeps the motor running, so you must stay connected to be able to stop the "RUN". Now you need a heartbeat in case the UI goes away, because you broke the basic motor record behavior. The UI cannot guarantee writing a PV at a fixed period. You cannot make the UI part of your machine protection. Whoever does that should implement their own standalone python UI, and sign a paper accepting full responsibility for any damages.

[ttkorhonen]

Well, the "jog" fields in the motor record work a little bit differently. According to documentation: "When one of these fields is set to 1, the motor will decelerate to a stop if already moving, and move in the indicated direction (in user coordinates) at an acceleration specified by ACCL and speed VELO, until the field goes to 0." I can tell from personal experience that this is indeed the case.
Yes, the motor moves on its own - until the JOGF/JOGR is changed again. Further in the documentation: "These fields are dangerous when used over channel access, because the motor does not stop moving until a second message is received. If a very busy network should cause that second message to be lost, the motor will travel to its limit switch or hard stop.".
This is where the discussion started. Fair enough, a properly designed motion system will eventually stop and not crash, but there is still the somewhat uncomfortable feature...which could hit if one is trying to commission a new system with not all safety features in place.
A separate discussion is then if and how much effort one should put in to create a solution on the OPI level.

[georgweiss]

Thanks for the input.
But neither the setpoint nor the jog case covers "move until aborted".

[kasemir]

In a distributed control system with a network protocol that can be interrupted and defaults to a 30 second timeout, you can't have a "move until aborted" because you risk a connection loss after "move" and then have no way to "abort".
You can't hack around that my turning the bool button into a "write every second" mini-automation tool.
Operators need to use the jog functionality and then interactively keep "jogging". Operators can adjust the jog distance to make larger or smaller hops, or estimate a good target position and enter that as the setpoint.

[georgweiss]

The idea was to let the IOC initiate the move on first write from client, then abort if client sends 0, or if no heartbeat from client arrives within a certain amount of time.

[kasemir]

I understand what you want to do. You can't. Channel Access doesn't support that. Motor record doesn't support that.
UI is a channel access or PV access client, nothing more.
Like a terminal where you run "caput MOVE 1" and then close the terminal so you are stuck without a way to "caput MOVE 0". That's why the motor record has no MOVE, only VAL and jog fields.

[ttkorhonen]

I replied to Kay's first comment; please look at the motor record documentation. The fields in question are JOGF (jog forward) and JOGR (jog reverse.) They indeed do tell the motor "move until I tell you otherwise".
Should this be somehow resolved in the UI, or is this good design in the first place are different topics. But the motor record does work like the documentation says. And people do make use of that functionality.

[kasemir]

Sorry, I mixed up "Jog" and "Tweak".
From the motor doc for tweak TWF, TWR: When one of these fields is set to 1, the record will immediately reset it to 0, and the motor will move

From the motor doc for JOGF, JOGR: These fields are dangerous when used over channel access, because the motor does not stop moving until a second message is received. If a very busy network should cause that second message to be lost, the motor will travel to its limit switch or hard stop.

[georgweiss]

The idea is not to write to a motor record from the Boolean Button, but instead to a - for lack of a better word - "driver" PV that would control the motor record.

[kasemir]

I get that. You could actually use the tweak TWF, TWR which reset to 0 so you keep writing them.
Still, we can't turn the UI into something that keeps writing. This would turn the UI into a mini automation tool that "does" something on its own. Other EPICS display tools like edd/dm, edm, medm, dm2k, BOY have all not done this for good reasons.

[georgweiss]

But then I'd argue that the use case for the Boolean Button is somewhat obscure. A 1 is written when user presses button, 0 when released. Regardless of what kind of record the widget controls, the risk of missing out on the second write is always there. So how can user trust that the widget does what it is supposed to do?

[kasemir]

You can't, which is why it's a good idea to use a "bo" record and set HIGH=2, so the record will self-reset to zero after 2 seconds.
It's pretty much the same issue: We can't depend on the UI to "do" anything on its own.