LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

bound control doesn't always update shared variable (LV 8.2 + DSC)


It seems that it is possible for a bound shared variable to NOT always get updated with the latest UI control value that it is bound to. 

If you run the vi in the attached project, and (fairly quickly) toggle the 'Keyswitch Control' between the 'Off' and 'Start' positions, you should be able to reproduce the effect shown in the attached pdf.  Sometimes the bound shared variable (Keyswitch_Control) gets stuck in the 'On' position when the control reads 'Off' or 'Start.'  It does not catch up after a little while either; it seems truly "stuck."

Unless I am missing something here, this looks like a bug. 

I haven't played around with any other control types yet to test further.  I also don't know if this is limited to 'control -> SV' binding or if it also affects 'SV -> indicator' bindings (I hope not!).

Any ideas!?!?!?


Download All
0 Kudos
Message 1 of 5
(10,096 Views)

Hello WHAVEman,

 

I was able to replicate what you were observing. It seems that there is a bug in the front panel binding code. I would be filing a Corrective Action Report to let R&D know about this. Thanks for pointing it out.

 

Just on the side note, if you are looking to build an application based on the application architecture as in your posted code, then I would recommend that you refer to the attached VI for a much more efficient way of doing this.

 

Regards,

Chetan K

Application Engineering

National Instruments

 

Download All
0 Kudos
Message 2 of 5
(10,079 Views)
Chetan,

Thanks for the verification & for submitting the bug...

Regarding the example you sent, I can see why the event-based architecture would be more efficient. 

The example I had sent you was actually a (very) stripped down version of my 'Read Hardware' loop.  I have a somewhat large DSC-based project using cFP h/w and am using a polling loop to read all h/w values approx. twice per second.  I compare the new values with the last read values, and if new, wire the new values into their respective shared variables (w/ some alarms enabled that get monitored in 'alarm' event structure) so that I can access the new data from other areas of code (for datalogging purposes, etc.).  However, there are some data that need to be simulated, so when in simulation mode I am using a front panel control bound to another shared variable that is polled in the same h/w loop.  Since I am actually trying to simulate the h/w process, I think this should be ok (although not the most efficient).

I was curious why you chose to use the datasocket vi's though.  I'm not too familiar with them.  I would think, if anything, that they would be less efficient than wiring directly to a shared variable indicator.  

Am I off-base here?



0 Kudos
Message 3 of 5
(10,062 Views)

HI Chetan,

Once fileed can you update this thread with the CAR# ?

Thank you,

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 5
(10,059 Views)

Sure Ben, The CAR# is 46489DKQ.

 

About the Datasocket,VIs, well, for this example there was a need to programmatically write to any shared variable and for that reason these Datasocket VIs were used

 

Regards,

Chetan K

AE-NIC

0 Kudos
Message 5 of 5
(10,027 Views)