LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Wait for front panel activity - problem with drop down choice controls

I am trying to use the "Wait For Front Panel Activity" function; however I'm not satisfied by how it seems to work:
I have drop down choice controls (DAQ I/O Control, for example to choose a custom scale) on my front panel; the "Wait For Front Panel Activity" function triggers when I open the drop down choice list (clicking the little down arrow square on the right) but not when I click to make my choice (i.e. when actually the value of the control changes). I don't understand why this doesn't work properly? Does anybody know anything about this? Thanks
 
Tom
0 Kudos
Message 1 of 7
(2,582 Views)
Hi thomasm,

perhaps it is possible for you to add a small example vi.

Which LV version are you using?

best regards
Dippi
0 Kudos
Message 2 of 7
(2,562 Views)
I don't really see the behavior you're describing. Perhaps if you posted a small snippet of what you're seeing.

You may also want to consider using an event structure and simply responding to the control's "Value Change" event.
0 Kudos
Message 3 of 7
(2,540 Views)

Well, I extracted the relevant parts of the problem to make a simple VI to post; you should find it in the attachment. I'm using LabView 8.2; what happens on my computer is that sometimes the unit indicator (the right most column) keeps showing the previous value even after I chose an new scale (it then updates as soon as there is aone more front panel activity); the problem actually doesn't occure every time; it occures randomly. In my original VI, where there are much more functions in the loop, it occures much more often than in this here. By connecting an indicator to the loop index I found out that the function actually triggers correctly, that is always, also when I click to make my choice; however, for some reason the indicator that indicates the unit of the chosen scale doesn't always get updated.

... I eventually solved the problem by having the loop execute twice for every front panel activity; activate this feature by connecting the boolean wire to the "do not wait!" input of the wait-function.

 

Tom

0 Kudos
Message 4 of 7
(2,533 Views)
The problem is caused by the fact that even though you get the "Wait for Front Panel Activity" to trigger when you select the new menu item, the control's actual value hasn't actually changed yet. The subVI run because the block diagram continues execution, but it is receiving the previous value of the pulldown. Then, the control on the front panel is updated, but by that time the subVI has already run.

The "Wait for Front Panel Activity" is not the way to go with this, and causing the loop to run twice is just a hack. You should use an event structure and simply respond to a "Value Change" event. See attached modification for an example.
0 Kudos
Message 5 of 7
(2,524 Views)

Thanks, for the simple and clear explenation. Also your proposed solution including the modified vi is quite helpful. I know, the thing with having the loop run is a hack. However I think I'll stick with that, since, as a mentioned, there are much more things and particularly more controls in my original vi. Even with the "run twicw" feature the "Wait for activity" solution keeps programing complexity and transparency much better in my opinion (apart from the remodelling work it saves).

In any case thanks again!

Tom

0 Kudos
Message 6 of 7
(2,512 Views)
thomasm said

Even with the "run twicw" feature the "Wait for activity" solution keeps programing complexity and transparency much better in my opinion (apart from the remodelling work it saves).
Well, I would obviously debate this, and so would a lot of other regulars on here, but you are more familiar with the rest of your code, so you should be the best judge of this. Still, you should consider the event structure for future implementations. You might learn to like it.Smiley Wink
0 Kudos
Message 7 of 7
(2,499 Views)