Daryl Posted January 16, 2015 Report Share Posted January 16, 2015 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 Quote Link to comment
hooovahh Posted January 16, 2015 Report Share Posted January 16, 2015 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. Quote Link to comment
Daryl Posted January 16, 2015 Author Report Share Posted January 16, 2015 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. Quote Link to comment
hooovahh Posted January 16, 2015 Report Share Posted January 16, 2015 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 Quote Link to comment
Daryl Posted January 16, 2015 Author Report Share Posted January 16, 2015 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.