Button state feedback methods

[Dave_St]

I have a front panel on PC that duplicates functionality on a control head for an actuator. So, for instance, if the "run" state on the control head reverts to the false state, the corresponding boolean control on the PC front panel needs to reflect that change. The mechanism for this is already in place using control references and property nodes.

The issue I'm struggling with is timing. Communication with the control head is done via RS232 on a loose loop (~500ms). If I put the boolean on the PC in a "run" state, it will send the command to the control head, and occasionally, the feedback from the control head will initially read false putting the FP button in a false state until the next cycle, when it will have had time to register the true state.

This results in a down-up-down action on the front panel button which really looks like crap.

I'm curious how y'all might handle this.

Unfortunately I cannot post any code as the organization I work for will not allow it. 

[LLindenbauer]

• Can you change the firmware on the actuator?
• Can you elaborate on the "loose loop"?
• Why is the indication "down" when the head responds with "up"? Do you use the indicator as a control (or the control as an indicator)?
  • In that case: Split up the indicator from the control. Your control initiates a state change in the physical world, which takes time to propagate and finish. It is ok to reflect that on the UI.

[Vi.King]

Have you thought about using a flat sequence case structure to force the program to wait for all values before continuing?

The values will not pass to the next frame until each node has been updated.

You can also insert delays with the wait (mS) function in order to force the program to wait a set time before continuing.

I have added an example below that may help 🙂

[pincpanter]

I would follow LLindenbauer's advice and split up the indicator from the control.

Otherwise, you need a way to prevent the control to be updated for a while, say 1 s. How to do this really depends on how your code is structured. For example, if the code reads the control state in an event structure, you may disable the button in the Value Change case, then re-enable it in the Timeout case (assuming you have a Timeout case and the timeout value is long enough). The loop that reads the state from actuator should not update the control value unless it's enabled. This trick has a small chance to fail from time to time, but it should work acceptably being a cosmetic patch.

[stevem181]

Hi Dave,

The attached example (LabVIEW 2018) should give you some ideas. I "think" it does what you

want but it does not provide a way to deal with HW that does not respond. A counter could be

added to address this issue if needed.

steve

[Dave_St]

• Can you change the firmware on the actuator?

The firmware is proprietary and cannot be updated.

• Can you elaborate on the "loose loop"?

I tend to refer to a loop with a short period as a "tight loop" meaning it has a quick response. In this case, I mean to say that this loop has a slow response.

• Why is the indication "down" when the head responds with "up"? Do you use the indicator as a control (or the control as an indicator)?
  • In that case: Split up the indicator from the control. Your control initiates a state change in the physical world, which takes time to propagate and finish. It is ok to reflect that on the UI.

I suppose in that light you could say the current design uses the same front panel object as both control and indicator. It is technically a control but it seems logical that its state should reflect real-world conditions. Adding an indicator could solve this issue though. 

UI design is a tricky business sometimes!

[LLindenbauer]

---

@Dave_St wrote:

I suppose in that light you could say the current design uses the same front panel object as both control and indicator. It is technically a control but it seems logical that its state should reflect real-world conditions. Adding an indicator could solve this issue though. 

---

You could, of course, build a button that does both: The next step up would be to set up a state machine (Off, Turning On, On, Turning Off) and moving to a MVC-style backend, styling the button according to the state and making sure the hardware is not spammed by impatient users hammering the button. Compared to simply separating the indicator from the control, it adds quite a bit of complexity.

UI design is a tricky business sometimes!

Yes! In larger projects, this is typically handled by specialists, separate from hardware and business-logic concerns - which is going a bit "against the grain" of LabVIEW. You might also enjoy these discussions: https://ux.stackexchange.com/questions/109871/should-state-be-indicated-by-its-control-or-should-con... and https://ux.stackexchange.com/questions/19312/ui-for-interfacing-with-hardware