04-03-2013 12:51 PM
@Japper wrote:
I actually created a front panel this morning with indicators as seen below:
![]()
pretty cooool.....i do the same thing here using cockpit controls for pilots, basically simulating pushbuttons, rotary knobs,toggle switches and led indicators with manual dimming included. word of caution when controlling mutitudes...."defer panel update" can be your friend!
04-03-2013 02:15 PM
Thanks Apok-
Do you set these up as clusters in your applications? Care to post and example?
(I am hobbling along with v8.2)
Not sure what you meant by ...."defer panel update"
04-03-2013 02:50 PM - edited 04-03-2013 03:18 PM
@Japper wrote:
Thanks Apok-
Do you set these up as clusters in your applications? Care to post and example?
(I am hobbling along with v8.2)
Not sure what you meant by ...."defer panel update"
by definition:
When you set this property to TRUE, LabVIEW redraws any front panel objects with pending changes then defers all new requests for front panel updates. For example, controls and indicators do not redraw when their properties or values change. If the operating system requests a redraw, such as if the window is no longer behind another window, LabVIEW redraws the front panel with the current properties instead of the original properties. If FALSE, LabVIEW immediately redraws the changed elements of the front panel.
Setting this property to TRUE can improve the execution speed and memory usage of a VI.....
i had many indicators on my front panel, therefore it was very laggy in updating (redrawing everything)...
i would like to post my application,but since this was an application used for US goverment...defense laws permit me not to do so. I would follow Ravensfan suggestion of clustering your like controls together, plus your BD will look cleaner ![]()
04-05-2013 01:27 PM
Setting up these clusters seems liek a good way to group a bunch of indicators together but how about
parsing the data?
Is this as good of a method as inputing my serial port into a case structure and then having a
case for each button where the indicator corresponding to that button is lit when the code for
that button is sent through the serial port?
04-05-2013 02:10 PM
If you are only getting information on one button at a time, I would say you will be better off with the case structure as you described. If a single message will give you multiple button status, try to group those buttons into a cluster.
04-09-2013 09:40 AM
Group function groups of those lamps as clusters, then you can use Array to Cluster and Cluster to Array to work more effectivly on the data itself.
/Y
04-11-2013 07:20 PM
I agree with several of the other posts - personally I try using clusters whenever possible (when dealing with multiple indicators/controls)