06-18-2008 01:11 PM
06-18-2008 01:33 PM
Hummer1 wrote:
How do you find out what the vi is waiting on to proceed, or which element "has the ball" so to speak.
Well, that's a bad analogy, because LabVIEW is multithreaded and there could be many balls in play at the same time. 😄
06-18-2008 01:43 PM
I can't attach the vi. It consists of a while loop which contains a wait for front panel activity and a stop control to the while stop if true. It also contains two event structures. One event structure handles the control mouse down which I described before. The other event structure contains the response to another front panel control when it changes value.
06-18-2008 01:46 PM
06-18-2008 01:51 PM - edited 06-18-2008 01:52 PM
Hummer1 wrote:I can't attach the vi. It consists of a while loop which contains a wait for front panel activity and a stop control to the while stop if true. It also contains two event structures. One event structure handles the control mouse down which I described before. The other event structure contains the response to another front panel control when it changes value.
06-18-2008 04:41 PM
Got it....so...
If I put all the front panel controls in the loop with the wait for front panel activity, and all the event structures in another loop...(using multiple event cases to sort out which event to deal with, that should do it?
Thanks ...
I am making a lot of progress for a beginner at this, but am still confused about some of the "basics".
Back to humming.
06-18-2008 05:19 PM
06-19-2008 07:52 AM
Thanks...that helps a lot.
I'm confused about triggering events using front panel controls and triggering them using the property node value(signaling). The property node value(signaling) doesn't seem to trigger a value change event like the action taken by activating the control on the front panel...should it? Perhaps I had some other problem going on that masked this action, but I wound up having to make sure that the front panel controls were in a while loop that was either polled with a clock or by a wait for front panel activity. Even then, when the property node value(signaling) was changed, you had to execute a Generate Front Panel Activity for the event to be processed.
Did I miss something?
Thanks for taking time to straighten me out...as you can see, I need all the help I can get.
Humming softly.
06-19-2008 07:58 AM
06-25-2008 12:56 PM
Ok, I finally have duplicated the kind of problem I am having in a simple vi. (attached.)
The objective is to trigger an event when the control is pressed. (you can't use latched control action with events, so the control stays True until you reset it as part of the event structure)...BUT...If you reset it using Value(Signaling) it creates another event which causes the false case to run...If you reset it using Value (change to read)...the buttons state is now False....and the next time you press the button...the Value change event DOES NOT occur...(well, if it occurs, it doesn't trigger the value change event.)
This is probably something simple...and fundamental...and I'm sorry to bug everybody about it...but ....
Well you know what I mean.
Thanks.