Shared variable bug

Hello all:
With the attached project, run the shared variable bug.vi and press the button labeled Press me First. Then press the button labeled Press me Second. On both string indicators there shoud be text that say Hi There! in both string indicators. However, sometimes I only get only a Hi OR There! (did I say OR ) and sometimes and empty string for both itring indicator outputs.
Note this only happens when you FIRST run the VI. To repeat the bug, you will have to stop the VI and unload it from memory.
Can somebody else confirm this behavior? If confirmed, this is obviously a bug.
Robert
Attachments:
Shared Variable Bug.zip ‏25 KB

There seems to be some sort of latency when you read the value of the shared variable. I took your example, but I moved the read of the shared var. outside of the loop. After the first boolean is pressed, it took two loop iterations ~100 mS for the shared variable value (read) to update.
"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
Attachments:
Shared Variable Bug.vi ‏44 KB

Similar Messages

Bug: Built Real-Time app won't run if it accesses a typedef'ed shared variable node

Hello,
I finished developing a Real-Time program that uses typedef'ed (clusters and enums) networked shared variables (SVs). It works fine when I run the program in Development mode. However, when I built and deployed it as a start-up app, it refuses to start. The VI monitor in the Distributed System Manager says that the VIs that use those SV nodes (and the top-level VI that references them) have "Bad" status, and the rest are "Idle".
To get my built program to run, I had to disconnect all the variables from the typedefs. Deleting the SV nodes made the program run too, but that's not an option.
Has anyone else encountered this?
Platform: LabVIEW 2012 (32-bit), NI cRIO-9076

Yes. See the following thread.
Paolo
LV 7.0, 7.1, 8.0.1, 2011

Bug? Cannot export shared variable, if it's in a virtual folder within an .lvlib

Hello,
I was trying to keep my libary of shared variables organized by categorizing the variables into different virtual folders. However, it turns out that variables in virtual folders are excluded from exports, even though they (and their folders) are visible in the Multiple Variable Editor.
Is this by design (in LabVIEW 2012)? If so, what's the rationale?
Thanks!

Hi,
When there are variables inside nested virtual folders within a Library, the multiple variable editor does not work. If you select several variables in a virtual folder and right-click and select Multiple variable editor, the editor opens but you cannot change anything.
Workaround: Convert folders to libraries or move variables under a single folder.
Regards,

Peculiar behavior of Shared Variable RT FIFO

I'm trying to "leverage" the enhanced TCP/IP and Shared Variable properties of LabView 8.5. My application involves (among other things) doing continuous sampling (16 channels, 1KHz/channel) using 6-year-old PXIs (Pentium III) and streaming data to the host. I developed a small test routine that was more than capable of handling this data rate, even when I had the host put a 20msec wait between attending to the PXI (to simulate other processing on the host). To do this, I enabled the "RT FIFO" property of the Shared Variable (which was an array of 16 I16 integers) and specified a buffer size of 50 (that's 50 arrays). Key to making this work was figuring out the "error codes" associated with the SV RT FIFO, particularly the one that says the FIFO is empty (so don't save the "non-data" that is present).
Flush with success, I started developing a more realistic routine that involves rather more traffic between Host and Remote, including the passing back and forth of "event" data. These include, among other things, "state variables" to enable both host and remote to run state machines that stay "in sync"; in addition, the PXI also acquires digital data (button pushes, etc.) which are other "events" to be sent to the Host and streamed to disk. I developed the dual state-machine model without including the "analog data" machine, just to get the design of the Host/Remote system down and deal with exchanging digital data through other Shared Variables. Along the way, I decided to make these also use an RT FIFO, as I didn't want to "miss" any data. One problem I had noticed when using Shared Variables is the difficulty of telling "is this new?", i.e. is the variable present one that has been already read (and processed) or something that needs processing. I ended up adopting something of a kludge for the events by including an incrementing "event ID" that could be tested to see if it was "new".
Today, I put the two routines together by adding the "generate 16-channels of integer data at 1 KHz and send it to the Host via the Shared Variable" code to my existing Host/Remote state machine. I used exactly the same logic I'd previously employed to monitor the RT FIFO associated with this Shared Variable (basically, the Host reads the SV, then looks at the error code -- a value of -2220 means "Shared Variable FIFO Read Buffer Empty", so the value you just read is an "old" value, so throw it away). Very sad -- my code threw EVERYTHING away! No matter how slowly the Host ran, the indicator always said that the Shared Variable FIFO Read Buffer was empty! This wasn't true -- if I ignored the flag, and saved anyway, I saw reasonable-looking data (I was generating a sinusoid, and I saw numbers going up and down). The trouble was that I read many more points than were actually generated, since I read the same values multiple times!
Looking at the code, the error line coming into the Shared Variable (before it was read) was -2220, and it remained so after it was read. How could this be? One possibility is that my other Shared Variables were mucking up the error line, but I would have thought that the SV Engine handling reading my "analog data" SV would have set the error line appropriately for my variable. On a hunch, I turned of the RT FIFO on the two Event shared variables, and wouldn't you know, this more-or-less fixed it!
But why? What is the point of having a shared variable "attached" to an error line and having it return "Shared Variable FIFO Read Buffer Empty" if it doesn't apply to its own Read Buffer? This seems to me to be a very serious bug that renders this extremely useful feature almost worthless (certainly mega-frustrating). The beauty of the new Shared Variable structure and the new code in Version 8.5 is that it does seem to allow better and faster communication in real-time using TCP/IP, so we can devote the PXI to "real-time" chores (data acquisition, perhaps stimulus generation) and let the PC handle data streaming, displays, controls, etc.
Has anyone been successful in developing a data-streaming application using shared variables between a PXI and and PC, particularly one with multiple real-time streams (such as mine, where I have an analog stream from the PXI at 16 * 1KHz, a digital stream from the PXI at irregular intervalus, but possibly up to 300 Hz, and "control" information going between PC and PXI to keep them in step)? Note that I'm attempting to "modernize" some Version 7 code that (in the absence of a good communication mechanism) is something of a nightmare, with data being kept in PXI memory, written on occasion to the PXI hard drive (!), and then eventually being written up to the PC; in addition, because the data "stayed" on the PXI, we split the signal and ran a second A/D board in the PC just so we could "see" the signal and create a display. How much better to get the PXI to send the data to the PC, which can sock it away and take samples from the data stream to display as they fly by on their way to the hard drive!
But I need to get Shared Variables (or something similar) working more "understandably" first ...
Bob Schor

Bob,
The error lines passed into and out of functions are just just clusters with a status boolean, an error code, and an error string, and are not "attached" to a particular function as you describe in your post. Most functions have an error in input and an error out output, and most functions will simply do nothing except pass through the error cluster if the error in status is True (to verify this for yourself, double click on a function such as a DAQmx Read or Write and look at the block diagram. If there is an error passed in, no read/write occurs). This helps prevent unwanted code from executing when an error does arise in your program. By wiring the error cluster from your other shared variables to your analog data variable, you're essentially telling LabVIEW that these functions are related and that your analog data variable depends requires that the other shared variables are functioning properly. The error wire is a great way to enforce the flow of your program, but you must always consider how it will affect other functions if an error does arise.
Anyways, it's great that you have things more or less working at the moment. Keep us all updated!

DSC Saving Shared Variables to Library

I'm guessing this is a bug (LV/DSC 2009 SP1), but I wanted to see if anyone else had experienced this or had a workaround.
I'd like to make changes to the logging state of some shared variables programmatically and be able to save the changes. When I use the SharedVariablestoLib.vi function on a simple test library it works. However when I use it on my actual library I get the following (testing vi I'm using is Untitled 2):
Error Code 1
Invoke Node in PRC_SVsToLib.vi->PRC_DumpSharedVariables.vi->NI_DSC.lvlibharedVariablesToLib.vi->Untitled 2
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
I think the culprit is that my library has variables organized into virtual folders. Any thoughts?
Thanks,
Kyle
CLD using LV, DSC 8.5-2009, RT 8.5
Ghoti!

I can pretty well cause the problem with virtual folders. I have attached the vi I'm using to change the logging state and save the changes as well as the two libraries I used for testing purposes.
What I did to test:
-Disabled logging on both variables in both libraries.
-Saved, undeployed, and redeployed both libraries.
-Ran my log enabling vi on each library. It ran on Test 2 (no folders) fine. On Test 3 (includes a folder) it threw the same error as above.
-At this point I tested and both libraries were logging both variables.
-Looking at the variable properties in the project, both Test 2 variables showed Enable Logging checked. Neither Test 3 variable did.
-Exited the project. Test 3 had unsaved changes so I saved it.
-Re-opened the project and examined the variables, both Test 2 variables showed Enable Logging as before. In Test3 the root variable showed Enable Logging but the variable in the folder did not.
-Undeployed and redeployed both libraries.
-Confirmed that both Test 2 variables and only the root Test 3 variable were logging.
CLD using LV, DSC 8.5-2009, RT 8.5
Ghoti!
Attachments:
Programmatic Log Change.vi ‏17 KB
Test 2 Library.lvlib ‏5 KB
Test 3 Library.lvlib ‏4 KB

Modbus Communication, Adding shared variables, Licenses

Hello, I am having trouble communicating with a third party DAQ. I am receiving data from a thermocouple input module through a modbus library address but I recently purchased a digital I/O module which is giving me trouble. As soon as I add the shared variables which correspond to the modbus addresses of the digital I/O module channels I am using I get a few different errors. If I turn off aliasing for one of the thermocouple channels I get Error 1550 "the license for the I/O server type is invalid"....If I turn it back on I get errors for every modbus location saying "invalid value for enable aliasing option" I am using the student edition and on the opening screen it says the data logging license is expired. Is that the problem? I don't think so because I am successfully communicating with the thermocouple module of the same DAQ device. Is there a simple way to write a new VI that I can try to communicate with just a switch on the digital I/O module and see if it is reading on or off (0 or 1). Thank you very much for your time

Hi brade,
To clarify where we are at. the behavior you are seeing isn't expected. It is a minor bug that we have seen in R&D but haven't been able to reproduce and fix yet.
People have gotten around it by
1) re-making their projects
2) Enabling descriptions, as the engineer in other post. The problem went away for him on this post: "Aliasing is no longer an error. (As long as NI Variables (task description) is enabled)."
We were talking about the aliasing tab you can see on the modbus variables in hte labview project by right-clicking and going to properties;
I assume he checked the box on this tab:
Can you also post your project?
Jesse Dennis
Design Engineer
Erdos Miller

Binding a shared variable to a NI-PSP data object does not work

Hi,
I want to share data between a RT-target and one or more hosts (LV 8.6.1). The network shared variables are deployed to the RT-Target. According to NI accessing shared variables from another project or host has to be done by defining a shared variable on the host and aliasing it to the NI-PSP data object on the target.
I did that and the host shared variable generated an error (0x8BBB0011) during runtime.
Next I aliased to a shared variable deployed on the host from another project. This did work.
Another thing I tried was to bind the variable from the RT-target to a display element:
This is working !!! And as you can see the path of the NI-PSP data object is exactly the same ! So what is the difference between binding a data object to a shared variable and to a display element?
Is there a bug in the SVE or am I missing something here?
The host project:
The publisher VI
Hope, someone has an answer.
Regards
Matthias Quade
Solved!
Go to Solution.
Attachments:
AliasTestWrite-RT.vi ‏8 KB
AliasTestConsumer.vi ‏8 KB

Dear Mr. Quade,
thank you for posting at the National Instruments Forum. There is a known issue with the path of the bound variable with LabVIEW 8.6.1
Please download the patch for LabVIEW 8.6.1, it should solve your problem:
http://joule.ni.com/nidu/cds/view/p/id/1255/lang/de
Best regards from Munich
MarianO

Can't set intial value for cRIO boolean shared variable

LabVIEW 8.0 gives me a configuration error when I try to force an inital value for a Boolean shared variable in my cRIO library. Is that a bug, or am I overlooking some (probably obvious!) limitation of the cRIO hardware?
Jeff
Climbing the Labview learning curve!
Sanarus Medical
Pleasanton, CA

There are 3 screenshots attached to this post. Suppose I create a Boolean shared variable under My Computer in the project directory, then set the inital value as shown in BooleanInitialValue.gif.
If I drag a copy of that Boolean shared variable to my RT target block diagram, the run arrow breaks and I get the error shown in ErrorList.gif.
If I create a Boolean shared variable under my Real Time target (Compact RIO) in the project directory, then set the initial value and hit OK, I get the error shown in FixConfiguration.gif.
Message Edited by Jeff in Pleasanton on 07-19-2006 03:42 PM
Message Edited by Jeff in Pleasanton on 07-19-2006 03:44 PM
Jeff
Climbing the Labview learning curve!
Sanarus Medical
Pleasanton, CA
Attachments:
FixConfiguration.gif ‏6 KB
BooleanInitialValue.gif ‏13 KB
ErrorList.gif ‏13 KB

Shared variable engine with pro-face touchscreen windows 2000 professional

hello,
who has some experience with the shared variable engine from LabView 8.5 and a touchpanel from Pro-Face?
We try to deploy shared variables from the touchpanel but it doesn't work. Additionally the windows service ni shared variable engine dosn't start and we can't start it manually .
The touchpanel is a PS3701A from Pro-Face with Windows professional 2000 for embedded, Pro-Face told us that we have the full service of Windows 2000 professional on a regular PC.
Many thanks in advance
derN

Hi Andrew,
Thanks for the feedback! Your feedback will help us to improve LabVIEW for our customers. This bug has been reported to R&D (#45493) and they are currently investigating this issue. For now, the best workaround appears to be using a different OS, as this seems to only occur in Windows 2000. Thanks for the feedback!

What causes the Shared Variable Engine to Crash?

All,
Some background info:
I am using the SVE and DSC so that I can log my data to Citadel using Data Sets. I converted a previous DSC 7.1 project that used the tag engine over. That app ran for over 18 months. Need to upgrade app and add features at my customer requests so we migrated to LV 8.0.1.
I have an app that crashes the Shared Variable Engine (SVE). I created a test app with a single SV and then created a control and bound it to the SV and it works every time until I launch the larger app. The main app only has 33 SV that are set when I receive TCP data from PXI RT system (not using SV on RT since the logged data is only a fraction of the total data streamed and I don't want to take apart the RT data and send the SV separately). I have bound front panels controls to the SV's. When I run, I get server connection has been closed. I verified that the SVE was running with the test app before launching the main app.
I deploy the shared variables in the application and have verified they are deployed by the Monitor Variables utility ... but it always shows "No Value" for the data fields. I have set logging to enabled for data only, set Value Deaband (%) to 0 and Value resolution to 0, Update Deadband is Disabled as is Alarming, Scaling, Initial Value and Description. Security is set to default. All of the variables are set to Double, Network-Published, Single Writer with Buffering and Bind to Source disabled.
I have verified that the SV deploy without error by clicking Deploy from the project. Autodeploy All is off but I get the same results with it On (checked).
I undeploy and kill the process when I close the application.
I have tried only using 1 or 2 of the SV in the main app but get the same results. Every once in a blue moon it will work after rebooting the PC (but not everytime). Once it dies I have tried running NI examples as well as the test app and they fail until I reboot.
The error code indicates that the SVE engine has crashed. I have changed the service settings on Windows to relaunch on 1st, 2nd and all times after but nothing restarts the SVE. After it crashes it is impossible to exit LabVIEW without it hanging or reboot the PC without pressing the hard On/Off switch.
Once it dies there is nothing that I can do to get it back alive without rebooting the PC (a real problem for a control and monitoring system).
Any ideas would be greatly appreciated
Thanks.
Randy

Randy
Sorry for the delay, I've been researching your issue and juggling a few other issues. :-) One thing we can check is the Windows Event Log which will give us some more details as to WHY the Shared Variable engine seems to be blowing up on us (Conttrol Panel -> Administrative Tools -> Event Viewer). Any details in there along the lines of Variable Engine or Tagger crashing will help us narrow down what's going on.
There's always a possibility of files not getting upgraded correctly; however there aren't many shared components between LV 7.1 and LV 8.0. The Shared Variable engine is entirely new and the installations of LabVIEW themselves don't share many files outside of the example finder and a few other small common components (things located in the appropriately named Shared folder) I keep both on my machine (in addition to 5.1, 6.1, 7.0, and 8.2) without any hiccups.
The SVE crashing I have seen in the past (and from internal bug reports) has been from buggered installs, so uninstalling and reinstalling DSC may be a good course of action. One good test to do in the middle is to see if the engine still crashes with DSC uninstalled.
Hope this helps.
--Paul Mandeltort
Automotive and Industrial Communications Product Marketing

Odd Shared Variable Dialog Box message

I came across some odd behavior in the dialog box while I was created a new shared variable.
As I was typing in the name, I kept see a warning pop up in the dialog. It would come and go as typed. I figured out that whenever I typed a space, and thus it was temporarily the last letter in the SV name, the warning popped up. Type the next letter, the warning would go away. You can see the space ending the name right before the cursor in the top picture, and the name ending with a normal character in the bottom picture.
Now it is logical to me that ending a shared variable name with a space would be a bad practice, and should be warned against. But the warning never actually states that you can't end with a space. To be more precise, it says you can't have the slash code \s in the variable name. Now I am not actually entering slash codes, but I am entering spaces. And they seem to work just fine in the variable name, just not if it is the last character.
It just seems to be a mismatch between what the warning says, and what you can and can't do.
Can you have spaces in the SV name? By my experience you can.
Also, this in in LV 8.6 on an XP SP3 machine.
Message Edited by Ravens Fan on 03-05-2009 05:02 PM
Solved!
Go to Solution.
Attachments:
SV Dialog.PNG ‏48 KB

ColeTrain wrote:
Ben, which VI did you use to create your bogus folder? Was this a specific DSC VI or just the generic Create Folder VI?
The CAR for that bug was "105656".
The desription for that CAR was "Create DB while specifying path with space on end creates illegal Windows directory".
It supposed to create then put then put hte data files in the specified folder. It does the create but has trouble putting the data in the folder.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Coercion problem when using Shared Variable

I have a curious coercion problem when using Shared Variables. I want to share the state of a State Machine, which is an enum saved as a control (typedef) called TYPE State (see attached). I create a shared variable called State and define it as a Custom Control, using the just-mentioned typedef. So far, so good. I've attached three simple VIs -- the first one, Init State, simply wires a constant to the input of the Shared Variable to initialize it -- the wired constant is, of course, defined by the typedef. However, the Get State and Set State, meant to wire an indicator (for reading the state) or control (for setting it), develop coercion dots when wired into the Shared Variable. Why? How do I get rid of the dot? [I suppose I could abandon my typedef and custom control, but the beauty of typedefs and custom controls is that it "enforces" rules, lets you use enums for clarity, keeps the code "honest", etc. -- I'd hate to give that up just to get rid of a dot!].
On a related note, the code seems to work. This is much too simplistic to do anything, but if you open Set State and Get State, set the state to anything, run it (it immediately stops, of course), then run Get State, you'll see the chosen state appear in the indicator. So it does appear to work. The "error" (coercion dot) may, I suppose, be a "bug" in Labview because it can't figure out the mapping of the (very simple!) Custom Control, but if so, I hope it gets fixed quickly!
Bob Schor
Attachments:
Coercion Problem1.zip ‏38 KB

Hello Bob,
I am also seeing this behavior, I will escalate this question to our LabVIEW developers and post again here no later than next Tuesday, November 27th as National Instruments will be closed for the remainder of this week.
If this issue does turn into a product suggestion, I would suspect the workaround would to live with the coersion dot for the time being.
Enjoy the holiday
Regards,
Erik J.
Applications Engineer
National Instruments

Shared Variable event handling--spurious events

This is more of a nuisance than anything:
Using the DSC module to register for shared variable events, the event structure always fires once for each variable registered for. For example, if I register for the shared variables "Var1" and "Var2", upon entering the event structure [in a loop], I'll immediately see two events [one for Var1 and one for Var2] even if the values for Var1 and Var2 haven't changed.
I originally figured that it's intentional--it appears to be impossible to use SV events without this "feature"--except it doesn't happen in "highlight execution" mode, which I find puzzling.
Why does this exist, and is there some magic way to disable it? Or is it a bug? Anybody who has ever used SV events undoubtedly has some way of dealing with this. Right now I just burn off the first N events, where N is the number of shared variables I'm registered for. But that's extra diagram junk and it really shouldn't be necessary.
Solved!
Go to Solution.

Kyle:
Here's a sample project with two SVs and an event handler VI. SV1 has an initial value but SV2 doesn't.The array displayed in the front panel should be empty after running--the SV's are not written to anywhere. I get two entires--one from each event--when I run the VI.
I noticed some new behavior when I put this together. In this example I use the timeout condition to terminate the loop. There is a timeout value around 110ms that defines the cutoff for this behavior--but the value is not consistent. With timeout values ~110 and below, I get no spurious events. But I DO get them for any timeout value of above that. So perhaps this issue is invisible to anybody who is generating events faster than ~10Hz. This may explain why I've been having inconsistent behavior when using the execution trace.
[edit: reposted as archive]
Attachments:
SVtestProj.zip ‏16 KB

Using a 2-D array Single Process Shared Variable w/ RT FIFO for comm between a Deterministic and non-deterministic loop on an RT Target

Our problem is that we currently use a 2D array to store CAN data on a Real-time Target. The array is 20 elements of 3 byte elements as so:
                0              1              2
0              [byte]   [byte]   [byte]
19           [byte]   [byte]   [byte]
These values are passed between a Deterministic Timed (DT) loop where they are set and a Non-Deterministic Timed (NDT) loop where they are read and passed into a Network Published Shared Variable (NPSV) for communication across the network to a Host PC. I have insrted an image for illustration, pardon the size.
Currently to pass the data between the DT and NDT loop we are using a Global Variable (GV). To improve the system we have attempted to replace these GVs with Single Process Shared Variables (SPSV) with an RT FIFO enabled.
To create the shared variable I simply right clicked the GV of interest and selected create Shared Variable Node form the drop downs. At this point LabVIEW presented me with a 2D NPSV within a new Library hosted on the RT Target. I then selected this new NPSV from the Project, changed it to a SPSV, and enabled a single element FIFO. This variable was initialized with a default value for the size described above and then used in our code for the DT to NDT communication, and conversion to a corresponding NPSV for sending to the Host.
When I went to run the code I noticed that the variable was in fact 2D, however its size was only 2 elements of three bytes each, in other words only two of the row indices were populated and the other appeared as uninitialized. in addition, this data had no resemblance to the set initilazation value. This was also how the variable was presented on the host side of the network after tranfer into a NPSV.
The peculiar part is that If I change this SPSV to a NPSV and then try to change it back, I receive an error saying the type is not supported for SPSV with an RT FIFO enabled. I have to disable the FIFO (which defeats the entire purpose) in order to successfully compile! I am unclear as to what is the bug in this case. Should I not be allowed to create the original 2D SPSV with a single element RT FIFO enabled without receiving an error? Or if this is okay how do I fix the problems associated with the variable after being allowed to create it?
I have found the following discussion in which a user states “The only limitations for custom controls is the ability to use it with RT FIFO enabled on a network-published shared variable”. Is this also true for SPSV? I have not found any documentation explicitely stating this for SPSV, though it is stated for the NPSVs.

Martin,
RT FIFOs don't support Multi-Dimensional Arrays, which would corroborate the issues you're seeing. You can break up the 2D array into 1D arrays by reshaping the array, then you'll be able to use the RT FIFO enabled variable, just set the array size to the total number of elements (20*3 = 60).
You can also pass the 2D array via pre-allocated queue, or using a Functional Global. We have a reference example for a circular buffer using Functional Globals here.

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!?!?!?
Attachments:
DataBindTest.zip ‏21 KB
DataBindTest.pdf ‏40 KB

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
Attachments:
Connect Shared Varibles.vi ‏29 KB
DataBind UI_modified.vi ‏12 KB

Shared variable bug

Similar Messages

Maybe you are looking for