Jump to content

Labview 2014 Bug with event structure?


Recommended Posts

Please look at the attached Labview 2014 vi.


Press the arrow on the control and select a different value from the drop down list and the event is fired as expected.  Now, press the arrow, then click on  "browse" and select a different channel, the event does not fire.  Is this a bug in Labview?  Is there a workaround to get the event to fire?

event issue.vi

Link to comment

Wow that has to be a real bug.  I tested it with classic, silver, system, and modern DAQmx Terminal controls, and they all don't fire the value change event, if it is changed using the browse dialog.  I also tested this in 2013 with the same result.  As for work arounds...


You could write your own XControl that looks and behaves like the selection control.  This would be a pretty big pain and would probably involve re-creating the browse dialog...


Or you could poll the control value periodically, looking to see if the value is not what it was previously...


Honestly those are the only two ideas I have.  Others come to mind but none I'm sure you could actually do other than those.  Contact NI and have a CAR filed.

Link to comment

I just tried this as far back as Labview 8.5 and the issue existed even in that version.  It is only an issue with the "NI Terminal" control.  I have tried with DAQmx Global cannel control and DAQmx Physical Channel control and the events are fired from the "browse" menu as expected.  I contacted my local Rep and he is escalating the issue. 


I'm struggling to come up with an easy work around in the mean time. 

I guess I can poll the value for changes in the timeout case of the event structure.  This is the least "ugly" solution I can think of for now.

Link to comment

Okay how about this.  Some kind of helper VI that runs in parallel, that monitors the value of the controls, by reference.  If the value does not equal what it did before, it sets the Value Sig property node, which should generate the event like always.  You'll need some way to kill this VI running in parallel of course on shutdown.  And there is a bug that when the control value is changed like normal, the event will be generated twice.  You can look at the time to filter out a duplicate event.


Attached is a quick example of what I am describing.

Event Work Around.zip

Link to comment

Thank you for your help and ideas.  I have come up with a similar solution by polling the value and if it is changes, write the new value to the Value(signaling) property.  It's kind of ugly but it will work for now.


I just got an e-mail from NI Applications Engineer and there is a CAR #426378 for this issue.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.