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

Similar Messages

...this "error"box "Saving iTunes Library"

everytime after i close my itunes appears this "error"box "saving itunes library" it doesnt seem to have any end...it goes on and on...and at last it shuts my computer down, without any his "action" result.
any help?(a)
Fujitsu Siemens Windows XP
fujitsu Windows XP
fujitsu Windows XP

Exclude your iTunes folder from your antivirus program.
For me it is NOD32, and whenever I re-install or upgrade I have to do this, otherwise the annoying "saving itunes library" error pops up on exit...
If you haven't done anything to the antivirus program, maybe you renamed your folder or the location where the iTunes folder is located and you have to change that in the antivirus program as well...
This worked for me... Hope it helps you out!

LV7.1 DSC tag engine VS LV8.6 DSC shared variables

I'm currently running LV7.1 with DSC and RT. To handle communications and logging RT variables I'm using the init / read / write publish.vi's on the RT side and datasockets on the HMI side (Windows XP). This has worked out great - new tags can be programmatically created in real time with the publsih vi's and then I go to the the .scf file and use the tag configuration wizard to add them to my scf file and handle data logging. This worked very well - the wizard would organize all of the memory tags into folders by block name used by the init publish vi. I could also select entire groups of tags and add hundreds at a time to the .scf file. Hardware Tag also worked in a similar fashion, organizing tags by controller and module folders. Now - looking at LV8.6.I found I can still use the init / read / publish vi's on the RT side - great. However there is not tag configuration editor as in LV7.1 to let me add large numbers of tags through a wizard. The closest thing I've found is to create a library to represent each block name from the RT init publish.vi then use "create bound variables" option under the library to bind the new shared variables to the RT memory tags. I can browse to the tags on the controller by network items, but when I add them it doesn't bring the block name of the tag as it did in 7.1, only the item name. I use a lot of PID loops that share the same tag names (i.e.: P,I,D, mode, output), so not including the block name represents an organizational problem. The problem with this is, it's very labor intensive compared to the wizard in LV7.1 DSC, especially talking about creating systems with thousands of RT memory tags. Also, there is a similar problem with hardware channels (I'm using compact FieldPoint). To log channels via DSC do I have to create a shared variable for each channel to access the DSC logging capabilities? Again how do I add all of the hardware channels in some organized fashion? I hope I'm missing some tool that is an analog to the tag configuration wizard to bring in these channels and organize them. Any help or suggestions would be appreciated. Thanks,Brad

Hi lb,
We're glad to hear you're upgrading, but because there was a fundamental change in architecture since version 7.1, there will likely be some portions that require a rewrite.
The RTE needs to match the version of DSC your using. Also, the tag architecture used in 7.1 is not compatible with the shared variable approach used in 2012. Please see the KnowledgeBase article Do I Need to Upgrade My DSC Runtime Version After Upgrading the LabVIEW DSC Module?
You will also need to convert from tags to shared variables. The change from tags to shared variables took place in the transition to LabVIEW 8. The KnowledgeBase Migrating from LabVIEW DSC 7.1 to 8.0 gives the process for changing from tags to shared variables.
Hope this gets you headed in the right direction. Let us know if you have more questions.
Thanks,
Dave C.
Applications Engineer
National Instruments

Error during launching executable with network shared variables

Hi,
I am launching an executable which deploys network shared variables before running the application, I am getting the follow error. can someone tell me whats going on.
thanks,
Attachments:
Untitled.png ‏28 KB

Mudda,
Is LabVIEW 2010 installed on the PXI chassis or was this program developed on a different computer?
If LabVIEW 2010 was installed on a different computer you may need the 2010 runtime engine on the controller. If the development environment is installed on the PXI controller then you should be fine.
How are you connecting to the PXI chassis is it on the network or do you have it directly connected to your development computer?
If you look at this forum the same error occured when another device on the network was sharing the same IP address.
http://forums.ni.com/t5/Real-Time-Measurement-and/Deployment-Completed-With-Errors-Network-Shared-Va...
Could you try plugging the PXI chassis in directly and see if that resolves the issue or changing the IP address?
Kyle Hartley
RIO Product Support Engineer
National Instruments

Is Shared Variable Engine with LV8 an OPC server ?

Hello
Is the shared variable engine with LV8 an OPC server ?
Does any OPC client can acces to Variable Engine OPC server an read shared variable ?
Can I build an installer and deploy my application with Variable Engine OPC server on other PC without LV8.
Thank you

Hi
You can communicate between an OPC serveur and LV8 and use shared variable. To deploy an LV8 exe application, you must have the run time engine installed on the PC without installing LV8. You can create a setup with LV 8 in which you can integrate the run time engine.
Kamal
NIF

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!

Front Panel binding of shared variables very slow initialization / start

Hello @ all,
I am using a server running Windows2000 and LV 8 DSC RTS for datalogging. All shared variables are deployed on that server.
I am now facing the problem, that all front panels running on the clients using the network shared variables on the server take very long to sync on startup. First the flags on the controls bind to the shared variables turn red, after up to ten minutes they start to turn green. The panels use up to 40 controls bind to the shared variables.
All firewalls are turned off. I tried to connect the client to the same switch the server is connected to. Same problem. Does anybody have a clue?
Thx for your quick answers.
Carsten

While I can't offer any solution to your problem, I am having a similar issue running LV8.0 and shared variables on my block diagram (no DSC installed).
When using network published shared variables, it takes anywhere from 30 sec to 4 min from the vi start for any updates to be seen. Given enough time, they will all update normally, however this 4 minute time lag is somewhat troublesome.
I have confirmed the issue to be present when running the shared variable engine on windows and RT platforms, with exactly the same results.
In my case, the worst offenders are a couple of double precision arrays (4 elements each). They will normally exhibit similar "spurty" behavior on startup, and eventually work their way up to continuous and normal update rates. Interestingly enough there are no errors generated by the shared variables on the block diagram.

Migrating large project from DSC 7.1 to LabView 2009 Shared Variables ... What's the next step after recreating my variables?

I am in the process of migrating a large distributed (multi-workstation) automation system from the LabVIEW 7.11 DSCEngine on Windows XP to the LabVIEW 2009 Shared Variable Engine on Windows 7.
I have about 600 tags which represent data or IO states in a series of Opto22 instruments, accessible via their OptoOPCServer. There are another 150 memory tags which are used so the multiple workstations can trade requests and status information to coordinate motion and process sequencing. Only one workstation may be allowed to run the Opto22 server, because otherwise the Opto22 instruments are overwhelmed by the multiple communications requests; for simplicity, I'll refer to that workstation as the Opto22 gateway.
The LabVIEW 2009 migration tool was unable to properly migrate the Opto22 tags, but with some help from NI support (thank you, Jared!) and many days of pointing and clicking, I have successfully created a bound shared-variable library connecting to all the necessary data and IO. I've also created shared variables corresponding to the memory tags. All the variables have been deployed.
So far, so good. After much fighting with Windows 7 network location settings, I can open the Distributed System Manager on a second W7/LV2009 machine (I'll refer to it as the "remote" machine henceforth) and see the processes and all those variables on the Opto22 gateway workstation. I've also created a few variables on the remote workstation and confirmed that I can see them from the gateway workstation.
Now I need to be able to use (both read and write) the variables in VIs running on the remote workstation machine. (And by extension, on more remote workstations as I do the upgrade/migration).
I have succeeded in reading and writing them by creating a tag reader pointed at the URL for the process on the Opto22 gateway. I can see a way I could replace the old DSC tag reads and writes in my applications using this technique, but is this the right way to do this? Is this actually using the Shared Variable Engine, or is it actually using the DataSocket? I know for a fact that attempting to manipulate ~800 items via Datasocket will bog down the systems.
I had the impression that I should be able to create shared variables in my project on the remote workstation that link to those on the Opto22 gateway workstation. When, however, I try to browse to find the processes on that workstation, I get an error saying that isn't possible.
Am I on the right track with the tag reader? If not, is there some basic step I'm missing in trying to access the shared variables I created on the gateway workstation?
Any advice will be greatly appreciated.
Kevin
Kevin Roche
Advisory Engineer/Scientist
Spintronics and Magnetoelectronics group
IBM Research Almaden

I have found the answer to part of my question -- an relatively easy way to create a "remote" library of shared variables that connect to the master library on my gateway workstation.
Export the variables from the master library as a csv file and copy that to the remote machine.
Open the file on the remote machine (in excel or the spreadsheet app of your choice) and (for safety's sake) immediately save it with a name marking it as the remote version.
Find the network path column (it was "U" in my file).
replace the path for each variable (which will be either a long file path or a blank, depending on the kind of variable) with \\machine\'process name'\variable name
where machine is the name or ip address of the master (gateway) workstation (I used the ip address to make sure it uses my dedicated automation ethernet network rather than our building-wide network)
and process name is the name of the process with the deployed variables visible in the Distributed System Manager on the gateway machine.
NOTE the single quotes around the process name; they are required.
The variable name is in the first ("A") column, so in Excel, I could do this for line 2 with the formula =CONCATENATE("\\machine\'process name'\",A2)
Once the formula worked on line 2, I could copy it into all the other lines.
Save the CSV file.
Import the CSV into the remote library to create the variables.
Note: at this point, if you attempt to deploy the variables, it will fail. The aliases are not quite set properly yet.
Open the properties for the first imported variable.
There is probably an error message at the bottom saying the alias is invalid.
In the alias section, you'll see it is set to "Project Variable" with the network path from step 4.
Change the setting to "PSP URL" with the same path and the error message should disappear.
Close the properties box, save the library, and then export the variables to a new CSV file.
Open the new CSV file in Excel, and scroll sideways to the NetworkrojectBound field.
You'll notice it is False for the first variable, and true for the rest. Set the field FALSE for all lines in the spreadsheet.
Scroll sideways... you'll notice there are two new columns between NetworkrojectPath and Network:UseBinding
The first one is NetworkingleWriter; it should already be FALSE for all lines.
The second one is Network:URL. That needs to be set equal to the value for each line of NetworkrojectPath.
You can accomplish this with a formula like in step 4. In Excel it was =U2 for line 2, and then cut and paste into all lines below it.
There is a third new field, Path, which should already be set to the location of the variable library. You don't need to do anything with it.
Save the edited CSV file.
Go back to the remote library, and import variables from the just-edited remote library CSV file.
Once you have imported them and the Multiple Variable Editor opens, click on done.
You should now be able to deploy the remote variable library without error. (Make sure to open the Distributed System Manager and start the local variable engine. It took me a few failures before I realized I had to do that before attempting a deployment).
Voila! You now have a "remote" library of shared variables that references all the shared variables on the master machine, and which should be deployable on other machines with very little difficulty.
It actually took longer to write out the process here than to perform these steps once I figured it out.
Kevin Roche
Advisory Engineer/Scientist
Spintronics and Magnetoelectronics group
IBM Research Almaden

Shared variables location

   I'm starting a fairly large project and wanted to organize it properly. When I needed a shared variable, I first created a new library. I was able to specify the location of this library in a sub-directory within my projects file structure.   Then I made some shared variables (single process). After saving the project, the shared variable files appeared in the main project directory, at the same level as the .lvproj file, not in the subdirectory where the library was created.
   Any tips for orginizing shared variables?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

   Thanks for the reply. Unfortunately, the problem remains:
   I first create the library explicitely, before creating any variables. I saved the library to a subdirectory. Then I create variables. When the variables are instantiated within a VI, at some point LabVIEW automatically creates vi files on the disk corresponding to these variables. These VI files were placed in the main directory with the project file, not in the subdirectory where I put the library. This is surprising to me and I would think this is a bug.
    My solution at this point was to create a "Project" subdirectory. I put the .lvproj and the .lvlib file in that subdirectory and now the shared variable vis appear there as well. This is a kludge.
   My main question at this point is: can you specify where these shared variable VI's get created and stored? I suspect that you could edit the .lvproj file or other xml files to change the share variable paths, but that is inappropriately difficult. I tried just moving the files to where I wanted them, but then the variables don't load. I managed to reload them, but at some point, they recreated themselves in the original location.
   At a minimum, the shared variable VIs should create themselves in the same directory as the .lvlib file that they belong to. At least you can specify where the .lvlib file lives.
Regards,
   Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Updating of shared variable

Hello There
I am using Shared variables (SV) on an RT host. The use of these variables seems to be functioning correctly. However, after certain events, which are not that frequent, I write the values in this variables to a spreadsheet.
What has happened on a number of occasions is that previous values that were stored in the SV are being written to the spreadsheet. I have been careful to employ VI to write to spreadsheet after the values are stored in the SV. I may or may not have had the file download link between the RT host and the desk top at the time of these errors.
I have independent hardware and software checking the operation of my RT controller, which was all correct, so the problem is simply related to file storage.
Can anyone help.
Thanks MAC_D

Thanks for your reply Wayne.
The shared variable is reading and writing correctly and there is no errors.
I am using these shared variables to control digital outputs, and i have verified using external hardware and software that my application preformed correctly.
The issue is that the correct values of the shared variables were not written to file correctly. Previous values were replicated.
Kindest regards

Network shared variables reconnecting network dropout

I've got a cRIO unit communicating with a Laptop using Network Shared Variables, with one of them being a 21 index array that is buffered.
The system connects and communicates fine, but occassionally the wireless card in the laptop is losing the signal from the WAP attached to the cRIO.
When this happens the Network Shared Variables never "reconnect" and start receiving values again once the Wireless link is restored. Is this an expected behavior?
When I tried using another industrial WAP instead of the laptop wireless card I do not get the drop-outs.
Ryan Vallieu
Automation System Architect
Solved!
Go to Solution.

Hello Ryan,
Thank you for contacting National
Instruments! I have looked into the issue you are experiencing and
wanted to ask you a few more questions. First of all, do you have a
time frame in which you allow for the reconnect? I believe that the
Shared Variables should regain connection after a short period but it
will not necessarily be a very quick process. It may take a few
minutes for the Shared Variables to reconnect.
The other
thing that may be happening is if you have error wires being passed
through the Shared Variables, it is possible that the error is not
being cleared and so it will always see the error and therefore never
reconnect. In this case you will have to filter this error out and
then clear the error in order to utilize the shared variables again.
If
you have any more specific information about your program that may help
us determine the reason for this behavior. Also a screenshot of your
code would also be helpful. Please let me know if you have any further
questions and I will be happy to assist you. I hope this helps!
Thanks!
Bob H
Applications Engineer
National Instruments

Problem Sharing Variables between 2 machines

I am having problems trying to create a project that would share variables between multiple computers. I am using Labview 8.2.1 (I am new to 8.2.1 and Shared Variable).
here is what i did:
1. I created the project with Client and Server VI's and a library containing shared variables, which both of them call
2. I placed this project onto 2 computers (XP on a local workgroup, no firewall, see each other).
3. On one of the computers I bound all shared variables to their counterparts on the other computer
The system is "almost working"
The problems are:
- I initially used wrong type variables for few items. I then modified the variables in both VI's and Shared Variable libraries and repeated the Steps 1-3 above.
But the sysrtem has some sort of a buffer somwhere, because it keeps bringing the old types of shared variables back (when I monitor them using Shared Variable Monitor).
- When I do binding to source, the system shows wrong variable types (for example DBL instead of U8).
- It takes almost a second to write and read shared variable (my network is quite fast)
I saw that the Labview Example with Server and multiple Clients uses 2 sets of shared variable and they bind - separate sets (different names) fro client and server within the same project. Do I have to do this or is this done just to simplify bindinga nd future distribution?
Is there a buffer/setup/file that I need to clear to get rid of "old" shared variable assignements? (I tried undeploy/deploy - does not help...)
Thank you very much,
Gleb.

Hi Gleb,
It sounds like the shared variable is not getting completely undeployed from the shared variable engine. I would recommend opening the shared variable manager and undeploying the library from there just to see that it is no longer in the engine. Then, redeploy the library and rebind your variables to the host library that you have deployed.
It is not necessary to have different sets of variables for client and host. The important part of the variable is what it is bound to, not necessarily what it is named. So just undeploy your variable, double check the settings of the host variable, then redeploy using the variable manager and rebind your client variables.
I hope this helps,
Brian Coalson
Software Engineer
National Instruments

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

Dsc shared variable property are saved to library?

Hi,
I would like to be sure to know if the shared variable properties like "alarm level" and "description" are saved to the library directly?
If not, where? database?
Also can we not add table to the dsc ms sql express database? (the one for alarms and events)
Thanks
Patrick
Message Edited by paubine on 09-04-2009 08:23 AM

The properties of the shared variables like alarm and description do get saved to the library. As for your second questions about a table in ms sql, can you tell me more about this? Are you using the LabVIEW DSC VIs to do this, if so provide a screen shot or your code or a good description. Tell me exactly what is going wrong, what behavior you expect and what you are seeing.
Thanks,
Anna K.
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

Similar Messages

Maybe you are looking for