many controls on GUI

[Blokk]

I would like to ask how you would deal with the following scenario:

I have a GUI where besides some other elements, I have a TAB page, where I will have about 40 custom looking Boolean controls (representing hand valves in a P&ID of an experiment rig). Beside these many controls, I will have 2 more controls representing FlowController setpoint values, and about 9 indicators (flowmeters actual values, temperatures, and pressures).

The 40 hand valve controls are only for helping and guiding the operator when using the system, and I need to log the valve states (open or closed) in the TDMS file, where I log the other measured values too with timestamps.

My problem is that, if I want to have a nice and tidy block diagram, I cannot clutter all 40 controls neither in the top loop (GUI Event handler), neither in the bottom loop (DAQ and logger -> slow DAQ so file logging is not in separate loop). I cannot really create a cluster of these 40 controls, since I cannot overlap the other controls and indicators over this cluster (my Front panel TAB page will show the whole P&ID to guide the user).

I started to search, and I read some similar posts, where people suggested to use subpanel. I never used subpanels before, would you think this could help here? Also, where I should read out these 40 hand valve controls? I do not necessarily need an Event to be triggered, since I only want to record their actual state at 1Hz into the TDMS file beside the other data measurements. So they could be read out at the DAQ/logging bottom loop too...

Any recommendation?

Thanks!

[Yamaeda]

It sounds like there's several valves and they each need several controls? If so, each valve is a natural cluster of controls. That way you can reduce things to e.g. 10 clusters instead of 40 individual controls.

Optimally this could then be used as an array of clusters, in which case you handle 1 array of clusters instead of individual controls ...

On the front GUI an array might not be optimal, but then you can use the Array to cluster and have 1 big cluster with several valve clusters inside. If using classic clusters you can make the borders transparent to avoid the several levels of indentation.

/Y

[Blokk]

No, misunderstood me.

I have 40 hand valves (HV), and on my Front Panel exactly 40 Boolean controls represent them. Hand valves = they must be operated by hand, no electronic control. The reason industrial software (Siemens, etc.) also use them on a GUI that they can guide the operator which valves he/she opened by hand and which ones are still closed. It is like a graphical overview of the P&ID. So the operator goes to the physical system, opens a valve by hand, goes back to the terminal and clicks on the graphical representation to mirror EVERY steps.

So I have such a Boolean controls like 40 of them, which only role is to reflect the real world situation AND the software logs their state into the TDMS file.

If during an experiment something goes wrong, we can investigate whether the operator did something stupid or not. Of curse, we cannot avoid possible user mistakes either when the operator changes a valve state on the GUI and not in the real system, or vica versa.

On my front panel I will have these 40 HV Boolean controls, and between them, around them some other controls which DO real action for example on a FlowController device, and some indicators which are showing pressure and temperature measurements...

EDIT1:

"On the front GUI an array might not be optimal, but then you can use the Array to cluster and have 1 big cluster with several valve clusters inside. If using classic clusters you can make the borders transparent to avoid the several levels of indentation."

This could work, however I have also indicators, like 9. You cannot put an indicator cluster into a control cluster...

[Yamaeda]

---

@Blokk wrote:

 "You cannot put an indicator cluster into a control cluster..."

---

Sure you can, just make is Disabled and it's an indicator. 😉

So the valves is an Array of Boolean controls. :)Ofcourse it'd be a better system is there was some sensor that'd read the valve instead of relying on the operator remembering to switch the right one.

/Y

[Blokk]

"Ofcourse it'd be a better system is there was some sensor that'd read the valve instead of relying on the operator remembering to switch the right one."

Well, when I first started to deal with systems where you have high radioactivity, I also wondered a lot why engineers design systems with such hand valves. The key is life-time and reliability. Imagine an experimental rig in a glove-box system where you have 300 valves (and beside pumps, detectors, etc...). If all of these valves would be electronically operable, it would be a disaster. In such a system maybe we have 10% electronic valves, the rest are hand valves. A high quality hand valve is just superior to ANY electronic alternative in many aspects. Of course for such systems you need multiple operators and very strict rules (it is a bit like in an airplane, the pilots counter-check their actions).

[Yamaeda]

I wasn't referring to electrical operation, just sensors to read the value to avoid mistakes. Still you'd need some double check to ensure the reading is correct.

/Y

[Blokk]

Hm, maybe I will just do a kind of workaround: I create a strict typdef cluster and I arrange all the 40 Boolean controls in it as they are on the P&ID. I just realized that, decorations can be placed over clusters, so I can imitate all the connecting pipes with lines and some other decoration shapes can be used to draw pump, flow controller, pressure/temperature sensor symbols. I just label with some decoration texts (like RF001, RT001, etc.) all the symbols (which are not the hand valves), and I can place the real indicators and controls by side of this large custom looking cluster.

edit: but the best solution could be a feature to create a cluster in LabVIEW where the cluster elements must not be together graphically...

edit: hm, I like this idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Clusters-as-a-concept-should-only-exist-on-the-block-d...

Clusters can be a useful tool for the programmer. Its role is on the block diagram. On the front panel the cluster's only useful feature is better served by grouping and decorations.

-Clusters force you to have all the controls within it bundled together within a box on the front panel. A box that even interferes with keyboard navigation. If you want one of the controls to be located elsewhere, you have to choose between the usefulness on the block diagram, and the best design of your user interface. The link is just unnatural.

[Yamaeda]

That sounds like an interesting solution, would be great to see the result.

/Y

[Ben]

This may give you some ideas. My "Docking" albumn found here shows examples of that technique in action.

Ben

[Blokk]

Thanks! I will have a look.