String to Shared Variable error

Hi all
I created a small example.
Why is in Shared Variable "Da 5" - "a" not upper ?
Regards.
Iskander
Attachments:
Examle.vi ‏8 KB

Hi Cole R.
Thanks for attention.
I am using LV-2010 and Win XP.
I have the same ERROR "Da5" in SVE. (See example) .
Although I created in project "DA5"
Picture is added.
Best regards
Iskander.
Attachments:
SVE.png ‏9 KB

Similar Messages

Why string type shared variable takes more time to update in the client

I am using shared variables to share the data across a master and the client PCs connected in a network. (Network published & no buffering)
I have created an integer type shared variable(I32) and a string type shared variable (data size is 60 bytes) in the Master and subscribing to the same in the client PCs. In the master PC, I am modifying the data in this order - update the data in the string type variable and then update the data in the integer vaiable.
But in the client PCs, due to the size difference in the variables, I am receiving the data of the integer first and after that about 3-4 sec later only I am receiving the string data. Can any optimization be done to reduce this latency period? Instead of the string data type any better data type will reduce this delay?
Please suggst. Advnced thanks.

Latency has a lot to do with your network. 3-4 seconds is a long time though. This could also be due to the larget data size of your string. The integer data size is definitaly not 60 bytes. If you're looking for better performance, I would highly recommend looking into Datasocket communication or TCP/IP communication. (There are shipping example for both.)
When it comes to performance of throughput and efficiency, network-published variables are lower on the totem pole.
I hope this helps,
Kevin S.
Applications Engineer
National Instruments

Dsc 8.2.1 cannot write to shared variables error 1950679035

I am getting error 1950679035 ni_tagger_write when I try to write to my shared variables. I recently upgraded from labview 8.2 to 8.2.1. I also upgraded to DSC 8.2.1. During the install, I had to upgrade my computer to SP2 (windows xp), which installed mdac 2.8 sp1 for use with dsc 8.2.1.
I have the windows firewall turned off, I checked with our IT dept and no upgrades were completed overnight (as the program worked yesterday using 8.2). I checked and MAX will get a connection with the fieldpoint unit. Everything is deployed from my machine, currently running under the dev environment.
I have looked at this thread, but I was not able to get anywhere, http://digital.ni.com/public.nsf/websearch/0D7B86F4B4D19A5E86256F9A006EECB1?OpenDocument and here.
Even though I have windows firewall turned off, I added all of the execptions to the windows firewall list.
It appears that the shared variable library is deploying correctly, as the the windows says that it has (when you run a vi). I am progmatically deploying the vi.
I looked at the variable manager and I attached a screenshot below. I am not sure if that means that it did not deploy correctly or not.?? (I was only watching a couple of the variables, I have about 20 total)
thanks
Kenny
Attachments:
variable manager.jpg ‏55 KB

It appears that my problem has been solved. Apparently our network had an internal error for a quick second and my nic did not like it. So after I restarted again (fourth of the morning) it started working now.
Kenny

Shared variable error 1967362044

Hi everybody,
I am using shared variable in one of my project to communicate between RT program and my PC program. FOr very first time I run the program in my PC. I am facing the error 1967362044. Can anyone tell the reason for this error and solution to get rid of this error. I have also searched in ni.com but I didnt find any solution regarding this. So, I request you to provide me a solution.
Thanks and Regards
Giridhar
Idesign

Hi Giridhar
From what I've seen this error can occur if the connection between computer and target was suddenly lost while the shared varible was written to. In that case rebuild the shared Variable.
Another instance were this can occur is if the project was developed on a computer with a localized version (i.e. non-english) version of Windows AND LabVIEW. Is that the case for you?
Best Regards
David
NISW
Message Edited by DavidEk on 07-31-2009 08:25 AM

Shared variable error

HI,
I get this error,
LabVIEW: (Hex 0x8BBB0005) Unable to locate variable in the Shared Variable Engine. Deployment of this variable may have failed.
This error or warning occurred while reading the following Shared Variable:
\\RT Single-Board RIO\temp1_lib\Temperature1
\\192.168.1.140\temp1_lib\Temperature1
What do I need to do?

Are you deploying the variable? Right click on the library>deploy.
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell

LABVIEW 2012 - shared variable error during programming of NI CRIO 9023 and TPC 2212

HELLO,
i am using CRIO 9023 with TPC 2212 and LV 2012. I want to develop a stand alone app which has a front panel on TPC. at first i am building a simple app with two controls variables, one is a sliding bar on TPC Vi and the other one is the while loop variable "i" on CRIO VI. i used shared variables.
first i creat shared variable on CRIO side and access this on TPC Vi. I COMPILE both Vi,s and they are working fine. But when i created the slide bar control in TPC VI, compiled and deploy the TPC Vi, it get deployed in TPC. But when i start compiling the CRIO VI an error mesage occured as follows;
I have tried every option to best of my understanding like formating crio then installing all softwares including Network variable engine etc. i also go in properties of the executable file of TPC Vi and go in properties-shared variable- then check the "deploy variable in application" option . below is image displayed.
I am in despirate need for solving this problem as i have to develop the final app for testing soon. can some one help me regrarding this.
REGARDS

I would not recommend using shared variable engine. It is supposed to make things easier, but in fact, you will spend more time troubleshooting why it is not working than you will actually coding an alternative solution.
Try the Simple TCP Messaging instead.
http://zone.ni.com/devzone/cda/epd/p/id/2739
Machine Vision, Robotics, Embedded Systems, Surveillance
www.movimed.com - Custom Imaging Solutions

Shared Variable Error -1950679023 (Connection to Server Disconnected)

There seem to be several questions but few answers regarding this error, which appears to be related to the NIVE (National Instruments Variable Engine) service dropping out.
One solution:
I noticed:
When I opened DSM (NI Distributed System Manager), I saw processes listed that I know I had manually removed previously from DSM.
NIVE service timed out when I manually tried stop it.
So, I:
Closed out of everything, re-opened DSM, and removed all processes (except for "System", of course)
Restarted the PC
Verified that DSM had no processes listed
Ran my software (which programmatically deploys libraries)
Error -1950679023 is gone!
Apparently something was clogged up with my deployed processes (didn't check whether Variable Manager also displayed the issue), which was causing the NIVE (i.e. SVE, "tagger") to hiccup.
Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

There seem to be several questions but few answers regarding this error, which appears to be related to the NIVE (National Instruments Variable Engine) service dropping out.
One solution:
I noticed:
When I opened DSM (NI Distributed System Manager), I saw processes listed that I know I had manually removed previously from DSM.
NIVE service timed out when I manually tried stop it.
So, I:
Closed out of everything, re-opened DSM, and removed all processes (except for "System", of course)
Restarted the PC
Verified that DSM had no processes listed
Ran my software (which programmatically deploys libraries)
Error -1950679023 is gone!
Apparently something was clogged up with my deployed processes (didn't check whether Variable Manager also displayed the issue), which was causing the NIVE (i.e. SVE, "tagger") to hiccup.
Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

Shared variable error 0x8ABC0011

I was getting this error on a simple test VI that I made. I am also getting this error when running the Heat Exchanger example. All of the controls and indicators have the red status light and this error. I am using 8.2.1, but I know I ran this example without any problems using 8.2. Any ideas what could be wrong?

I got it. Once I followed the instructions in the upgrade readme file about the database differences, it worked.

Error codes for shared variables in Labview 8.5?

I am trying to use Shared Variables in Labview 8.5 to enable real-time loops (similar to some of the examples in "Using the LabVIEW Shared Variable", published Aug 28, 2007). I created it to hold the result of a 16-channel A/D converter (so a 16-element I16 array). To avoid losing samples, I used buffering, with a buffer of 5. To test this, I made a pair of VIs, one a producer that stuffs a 16-element I16 array into the shared variable "every so often" (controlled by a timed loop), and a consumer loop that reads the shared variable and does something with the data.
If I think of the buffered shared variable as a Real Time FIFO (as the article suggests it is), I was curious how I would know (a) when the queue was empty, and (b) if the queue had overflowed. Both are necessary if this is to be a practical means of exchanging data -- you want the producer and consumer to run more-or-less at the same rate, but only the producer is deterministic. The consumer needs to be able to run "faster" if it falls behind (for example, because it is writing data to disk), but you don't want it to read data from the shared variable if there's nothing there. [One can always read a shared variable, after all -- as the article states, it simply "holds" the last value written to it].
Snooping around, I discovered that there are "error codes" associated with the shared variable. In particular, a code of -2220 (FFFFF754) seems to signify an empty queue (or a shared variable that has not yet been written to), while a code of -1950678981 (8BBB003B) appears to be "buffer overflow".
Is this documented anywhere? Are there other "error codes" that would be helpful to know? Is there some rationale to these seemingly-random numbers? [It would help to develop code to utilize shared variables if there was a bit less "magic" and "mystery" involved].
For what it is worth, with a buffer of size 40, I could generate 16 I16 values at 1 KHz (simulating sampling from a 16-channel A/D at 1 KHz) and pass it to a consumer node that (a) read from the shared variable until it was empty, then (b) "went to sleep" for 20 msec (simulating "doing something else non-deterministically"), and not miss any data (because I could then empty the Shared Variable RT-FIFO, which should have been half full, before it overflowed on me). Not bad throughput -- I bet I could push it even higher.
Bob Schor

Hey Bob,
The errors are documented in the LabVIEW help:
Shared Variable Error Codes
Real-Time Shared Variable Error Codes
There are several error messages for buffer underflow/overflow depending on the settings of the network or RT FIFO buffers. In particular the -2220 and -2221 are useful for the producer/consumer use case. For example (as you probably know) the consumer can flush a variable using the error code (see the attached image).
Gerardo
Attachments:
variable1.png ‏3 KB

Valid shared variable output does not work!

I am having a problem getting the string to shared variable to function correctly. Specifically the "Valid Shared Variable?" output. It always give a false output even when I know the variable is deployed. Could it be that it only functions correctly on shared variables from the localhost and not a remote system? If so is there another way to check?
Thanks
Todd

There is a community example on this at http://decibel.ni.com/content/docs/DOC-3861
The DLL is included in DSC, but if you have 2009 you may have to relink it. There is a boolean output for valid in this as well. Pop this in a subvi, and you have the functionality you are looking for.
Rob K
Measurements Mechanical Engineer (C-Series, USB X-Series)
National Instruments
CompactRIO Developers Guide
CompactRIO Out of the Box Video

Datasocket and Shared Variables

I am curious if there is any advantage to using Datasocket to read/write shared variables (as opposed to a direct read/write). I'm specifically talking networked shared variables here.
Is there any speed advantage to accessing shared variables thru the Datasocket functions? Since both a direct read/write and a Datasocket PSP read/write talk to the same variable engine I assume they are equally efficient but I'm looking for confirmation here. I've seen benchmarks for shared variable performance but none of them use DS/PSP to access the variables.
Normally I would not even think of using Datasocket to access shared var's but where I currently work we have a large app that does this and it works great. I suspect that this functionality only exists in LV8.x for backward compatibility and non-Windows OS compatibility and is not really meant to be used for new, Windows-based apps? Am I off base on this?
I am working in LV 8.5, BTW.....

Hello Jared,
Thank you for the reply with clarification.
Based on your comment, I changed the buffer parameters and also tried the programs with two different data types, previously StringArray and now String.
In the attached LV8.6 project, you have all the programs, and shared variable library to review my tests.
There are two sets of two files - each set has a Write Shared Variable and Read Shared Variable file. One set is for StringArray type Shared Variable (named StrArr in the library), and the other set is for String type Shared Variable (named Str in the library).
String Array example:
MultipleDS-Write-SharedV-StrArr.vi / MultipleDS-Read-SharedV-StrArr.vi
In my String Array shared variable, I use only 4 element array, each having 4 character strings - meaning 16 bytes per String Array data. I have two loops in the write file, writing to the same variable, an array of 4 strings, each loop continues until the loop index is >0. This means, sometimes, depending on the processor speed, the variable will be written 3 times or 4 times (the variable could have a new value before the loop condition is checked).
So this means, if I have buffer of 100 bytes (16*4=64<100), it's enough for 4 such arrays (of 4 elements, each element with 4 characters) could be buffered to have sufficient time at the client (Read) program to read them.
I am putting 2048 bytes in buffer, which is much more than sufficient in my case.
The writer loops run with 200 ms to wait for each iteration. The reader loop runs with 100 ms in DS timeout and 100 ms in wait timer. This gives results without any loss. However, if I run the reader loop with 1000 ms to wait for each iteration, the data is lost. The buffer is not maintained for 2048 bytes.
In the read program, just to make sure if all data is read or not, I am showing data in two different string indicators, showing data of each loop.
String example:
MultipleDS-Write-SharedV-Str.vi / MultipleDS-Read-SharedV-Str.vi
The String Array shared variable didn't show values in the Distributed System Manager. Hence, I created another simple variable with String datatype.
The writer program writes strings of 4 characters, one-by-one, in two loops. Meaning, total 8 strings of 4 characters each are written in the "Str" Shared variable.
The reader program, however, doesn't always display all the 8 strings. Although the wait timer is not high (slow) it still misses some data usually. Data is overwritten even before the buffer is filled (in buffer, I have defined 50 strings with 4 elements in each).
In both of the Read programs, I read using datasocket. I think thought datasocket has more ability to buffer. Earlier I had "BufferedRead" in DataSocket, which I have changed to just Read, because BufferedRead didn't give any special buffer advantage in the Shared Variable reading.
---- This is an update on the issue.
Ok, just while typing the last paragraph above, regarding datasocket, something clicked in my mind, and I changed the DataSocket functions to simple Shared variables (completely eliminating datasocket functions) in the read programs as well. And bingo, the buffer works as expected, even if I have reading loops very very slow, there is no data loss in any of the program sets.
The two changed Read programs are also included in the attached project - MultipleSV-Read-SharedV-Str.vi and MultipleSV-Read-SharedV-StrArr.vi
So this means, I can completely eliminate DataSockets (not even using PSP URLs in DataSocket Open/Read functions) from my programs.
One question here, what will be an advantage of this (or any side effects that I should be keeping in mind)?
Vaibhav
Attachments:
DataSocket.zip ‏71 KB

Shared variable dialog window

I want to ignore the dialog window or prevent it from coming up when there is an error in my shared variable. I am reading data from a PLC on a manufacturing machine. I am doing this on a separate server system and it isn’t monitored, so the fault does nothing but lock the Vi and prevent it from collecting data until someone happens to look at it.
I have a loop that is waiting for the variable to change and the most common error is when the PLC is turned off and there is no data available, however there are others that come up now and again.
I want to simply return to the loop and keep cycling until the data is there and readable again.
Is there a way to prevent the Shared Variable from halting on error? Can I turn off the dialog box so that it doesn’t stop the Vi?

It is coming from LabVIEW's autmatic error handler. There is also a VI option that can be changed globally for the VI to ignore the error. But I don't recommend changing that unless you have accounted for all other errors you could possibly get elsewhere in the VI. Any node that has an error output not wired to something else will have this dialog box pop up if the VI option is set to automatically handle the errors.
Another alternative is to wire the shared variable error to a tunnel on the loop, but don't do anything with it afterwards.

Unspecified error when writing variant shared variable

Hi everybody,
I'm getting an unspecified error (-2147467259) when trying to write a variant to a shared variable hosted on my cRIO device.
I'm using a cRIO chassis as a headless controller that dynamically finds remote ScanIO chassis at startup. Similar to the LabVIEW example, the cRIO finds the chassis and generates clusters containing the IO container refnums as well as other information about the modules. I generate two arrays (local and remote) of these clusters, turn them into a variant, and publish it as a network published shared variable so they can be used in a remote PC to add or remove remote channels as needed.
Has anyone had this sort of issue before? I'm new to real-time so I'm not sure if I have violated some canon here or not Thank you for your help
-Jordan

Jnelson,
There appear to be a few Corrective Action Requests (CARs) associated with using shared variables of the variant data type. The closest one I could find related to your issue was CAR #291679 where Wiring FieldPoint IO Point into shared variable throws error -2147467259. All CARs that I could find about using shared variables of the variant type threw the same error you are seeing and are feeding into it less standard datatypes (FieldPoint IO, LVClasses, IMAQ references).
To get a more general overview of your problem, does this error come up the first time you try to write to this shared variable or does it come up somewhat randomly? It would help if you could tell us exactly what hardware you are doing and if you can recreate this issue by simply deploying a program that writes a constant cluster with the same data types into that shared variable.
A possible workaround for you to try would be using the Flatten to String and Unflatten from String functions and pass that through a string shared variable. This has seemed to work for others in the past.
Matt J
Professional Googler and Kudo Addict
National Instruments

Problem with dsc shared shared variables and error 1950679023

I'm having trouble using shared variables on my laptop PC (with Windows XP) using Labview 8.2 and DSC. I've set up a simple project with one VI and one shared variable library. In the VI, I have a while loop that writes a number from a front panel control to the shared variable. Another loop running in parallel reads the shared variable and displays to an indicator on the front panel. The VI resides on my PC (no remote targets). This program executes just fine on my desk top PC; however I get the following error codes out of the shared variable nodes when I run the project and VI on my laptop for the write and read, respectively: ni_tagger_lv_Write 180121604 ni_tagger_lv_Read -1950679023 I've tried to manually deploy the shared variable library without success. The NI knowledge base and other entries on this forum suggested that the Windows firewall should be disabled for a quick fix, however, the firewall was already disabled on my lap top. I didn't see any entries regarding the 180121604 error code.
Any suggestions would be appreciated.

The problem has mysteriously gone away. For about the 10th time, I manually deployed the share variable library, and it started to work properly.

Error -1950678991 saving LV8.2 library of shared variables

I used to be able to programmatically save my library of shared variables using "ProcessToLib.vi" (set to Process mode) after changing properties of some or all variables. Now, and I don't know what has changed, I get this error:
Error -1950678991 occurred at property node (arg 1) in NI_Variable.lvlib: SetRawCluster.vi -> PRC_SVsToLib.vi -> PRC_DumpProcess.vi -> ProcessToLib.vi.
The explanation suggests that an Engineering Full Scale is the same as an Engineering Zero Scale value, but I have checked all variables that use scaling (not all do) and I can't find any such fault. Since these low-level VIs have protected diagrams, I can't trace the source of the error. I have tried the same thing on other libraries and they work fine.
I have attached my library for anyone to verify or duplicate the problem and maybe find out what is causing this error.
I have recently installed the DSC patch, but this should not be related to the problem.
Thanks,
Mike
UK
Attachments:
Krystallon Variables.lvlib ‏142 KB

Hi Mike,
I think something has become corrupted in your library. When getting the names of all the shared programatically I get multiple entries for a couple of the X-GPS variables. I deleted all the X-GPS variables and WS-116 and it saves fine. I think you might need to delete and recreate these variables.
Regards
Jon B
Applications Engineer
NI UK & Ireland

String to Shared Variable error

Similar Messages

Maybe you are looking for