Programming batch modify properties of shared variables DSC Module

DSC module to establish a large number of shared variables, you need to modify the property values programmed variables, rather than setting property values when creating variables.
DSC module to build tens of thousands of shared variables, alarm limit properties of these variables need to be set after the software is released by the customers themselves, rather than set when you create the variable.
So many variables, how programming in the software interface can be set variable attributes?
Solved!
Go to Solution.

请参考http://digital.ni.com/public.nsf/allkb/5292824E278CF8B948257254002DEE60

Similar Messages

Shared variable / DSC problen

hello out there,
i've got a big problem with labview dsc. i've created library within
an project with several network-bind shared vars (connected to a
symbolic siemens opc server). the problem is that sometimes, when i
use these variables (just drag and drop from the projectexplorer), the
values seemes to be currupted (especially 0). siemens' opc scout say's
there is a value and also NI's shared variable monitor do so.
open to all criticism.
r.p.

Shared variables must be initialized with a known value, and the node must be ran at least once, before predictable behavior can be expected. They don't behave like plain old global variables. The shared variable manager proves this out, as you've seen.
The easiest way to accomplish this is to have each shared variable you'll use in your application's initialize routine, and "read it out" and write to it once before ever using it in the main application.
Message Edited by Broken Arrow on 12-16-2008 09:47 AM
Message Edited by Broken Arrow on 12-16-2008 09:48 AM
Richard

What happened to my shared variable DSC alarms?

I would like to programmatically alter the alarm levels of my shared variables using the recommended datasocket write method, but for some reason my alarm levels disappear. If I open Variable Monitor, sometimes the alarm data isn't there. I have them configured, and sometimes they are there. This also means that the Datasocket URL doesn't exist for the alarm levels. Why is that?
Attachments:
Shared Variable Monitor.JPG ‏94 KB
Shared Variable Properties.JPG ‏46 KB

Hi Brian,
I am not sure what resource pointed you to using Datasocket Write to change the alarm levels of a shared variable programmatically, but that is not the recommended method.
One resource that you I suggest you check out is the example called Library Generation.lvproj, it is in the example finder under Toolkits and Modules->Datalogging and Supervisory Control->Fundamentals. This shows how to add variables to a library and set the alarms.
For an existing library, please check out this Knowledgebase article, which describes getting a shared variable reference. One you have the reference, you can use the property "Alarming..." to set Hi, Lo, etc. Then, once you're done, redeploy the library programmatically (Deploy Library.VI).
Best regards,
-Sam F, DAQ Marketing Manager
Learn about measuring temperature
Learn how to take voltage measurements
Learn how to measure current

Shared Variables - Properties

Hello,
I have a couple of questions about properties of Shared Variables (SV). They can be configured either by using the dialog box (right-click on SV -> Properties), or programmatically via the "SharedVariableIO" property node. Have a look at the NI-Examples to see how SV can be created programmatically by using the DSC module.
1) The dialog box offers a property "Variable Type" which can be "Network-published", "Single-Process" or "Time-Triggered". The "SharedVariableIO" property node gives no access to this property. Does anybody know why? The same question can be rephrased: How can I create a "Single-Process" SV programmatically?
2) The "SharedVariableIO" property node has two items, "Network.OnScan" and "Network.ConnectionType", which have no direct correspondance to any of the properties available in the dialog box. What is the exact meaning of those properties? The on-line help isn't of much use here...
3) Mutliple SV can be edited by using the Multiple Variable Editor (Tools->Shared Varaible->Multiple Variable Editor). A cool feature is the import/export of CSV-files. I am interested in programmatically creating SVs from the information stored in such a CSV-file. Reading the file is no problem, but connecting the file entries to the properties of the "SharedVariableIO" property node would be quite some job. In principle NI has already solved that within the Multiple Variable Editor. I guess there is a bunch of VIs somewhere below "....Program Files/NI/.../vi.lib that do exactly this thing. Does anybody know, if these (which ones?) are available for public use?
Regards,
Dietrich

dietrich wrote:
1) The dialog box offers a property "Variable Type" which can be "Network-published", "Single-Process" or "Time-Triggered". The "SharedVariableIO" property node gives no access to this property. Does anybody know why? The same question can be rephrased: How can I create a "Single-Process" SV programmatically?
You can't. The single-process shared variable is an old style LabVIEW global placed under the shared variable abstraction. There is currently no way to create those on the fly. Time-triggered also cannot be created programmatically. I confess I don't know enough about them to know the reason why.
dietrich wrote:
2) The "SharedVariableIO" property node has two items, "Network.OnScan" and "Network.ConnectionType", which have no direct correspondance to any of the properties available in the dialog box. What is the exact meaning of those properties? The on-line help isn't of much use here...
Network.On Scan = read/write hardware? - this allows you to programmatically control when you are reading from or writing to configured hardware.
Network.ConnectionType = connect to hardware even when no one is viewing me? - this has 2 choices, UpFront & OnDemand, UpFront means that the variable will be connected to hardware even when no one is connected to the variable. This is useful when you want to reserve hardware or when logging is enabled. OnDemand means that you disconnect from hardware whenever no one is reading the variable.
dietrich wrote:
3) Mutliple SV can be edited by using the Multiple Variable Editor (Tools->Shared Varaible->Multiple Variable Editor). A cool feature is the import/export of CSV-files. I am interested in programmatically creating SVs from the information stored in such a CSV-file. Reading the file is no problem, but connecting the file entries to the properties of the "SharedVariableIO" property node would be quite some job. In principle NI has already solved that within the Multiple Variable Editor. I guess there is a bunch of VIs somewhere below "....Program Files/NI/.../vi.lib that do exactly this thing. Does anybody know, if these (which ones?) are available for public use?
I would advise against using any of these. National Instruments can change, or remove, those underlying files at any time as a result of modifications to the MVE. That could cause issues for any code using those sub-VIs.
Regards,
Robert

Enable shared variable buffer

Dear all,
I'm writing on a program to create shared variables programmatically. I use the examples available in labview and DSC 8.0 as reference. I'm able to create and set the different properties such as scaling, alarms, inital value etc for the shared variable(s). However, when i wire a boolean "true" to " enable buffering", it doesnt seems to work. I checked the shared variable created in the shared variable engine, the variable is created but the buffering cant be enabled programmatically. Can anyone guide me what's the fault? thanks.

Hi,
The VI worked without any problem though I had to change the shared variable name. One thing to note about changing the properties of shared variables programmatically using the shared variable I/O is that it only affects the deployed shared variables and not the actual library file. In essence, these changes are not saved in the library. So the shared variable properties window will not reflect the current status of the "Network.UseBuffering" option. To verify that the "use buffering" is enabled, place another "Network.UseBuffering" property node on the block diagram and read the current state from it.
Attached is a modified version of the VI with the current status of the "Network.UseBuffering" property for the deployed shared variable.
Tunde
Message Edited by Tunde A on 03-05-2007 12:34 PM
Attachments:
Modified_buffering_error.vi ‏10 KB

Datasocket read stop but shared variable can update

Hello ,
I program with datasocket open/read, sometimes the read stops and after some time,maybe 10s, it go on reading, I compare this with shared variable (DSC) and found
the shared variable can update ,I don't know what happen to my program.
( the reason I'd like to use datasocket is that I need to change the ULR dynamically , I have many OPC tags to read ( 100 PLCs time 80 tags per PLC ) )
thanks for your help!
Solved!
Go to Solution.
Attachments:
shared variable VS datasocket.jpg ‏23 KB
shared variable VS datasocket.vi ‏17 KB

Hi~
The read function waits for items to be updated, and 10ms is the default time for this waiting. Setting wait for updated value to false will probably solve this issue.
PS: URLs of variables could be changed programmatically, see this document if you like.
Good day

How to add a new Shared Variable programmatically to an existing and deployed library?

Hi there!
I am trying to accomplish this on both LabVIEW 8.6 and LabVIEW 2010 and seems like it's not any different in this situation.
My case: A project has a library with 4 Shared Variables (SVs). The library and the variables are deployed (visible in Distributed System Manager 8.6/2010). I want to add 2 more variables into this library. It is possible to do this manually from Project Explorer window's options menu. But while running an application it has to be done programmatically. Can I provide the library reference to the one currently existing without creating a new one?
"Create Or Add Library To Project" function in the Datalogging and Supervisory Control (DSC) toolkit does not help in this case. That function, as the name suggests, just tries to create a new library in the project.
Two possible methods:
The function "Add Shared Variable To Library" (DSC>EngineControl>Libraries & Processes) needs a library reference, which could be provided via "CreateOrAddLibraryToProject" function, but this function tries to create a new library, and if I provide the path of the existing library it throws an exception that the library already exists in the project (yes, as I wrote above, I need to add new variables to an existing and deployed library).
OR
The function "Create Shared Variable" (DSC>EngineControl>Variables & I/O Servers) will add Shared Variable in a process, and not physically in a library file, and the problem (limitation) with this approach is that it doesn't allow to add complex data type Shared Variables (for example in LabVIEW 8.6 it has only 4 datatype options in input parameter, and even in LV2010 it does not have "Image" datatype that I need).
The scond method is my preferred method as it allows to work on Online Shared Variables and doesn't create them physically in libraries (and this is good as the variables' scope remains only till the Variable Engine is running). But it doesn't support advanced data types, and the first method is powerful in terms that it supports to virtually any datatype, it just seems tricky to get that reference to the library.
Any tips?
Thanks ahead!
Vaibhav

<<<<>>>>
As the above two images show, while a library does not exist, it is easy to use the "CreateOrAddLibraryToProject.vi" which will add a new library to the project (if it doesn't exist on file system, a new library will be created) and that way, using the reference (the green wire going out from the function and the Case Structure, can be used to add Shared Variables to the library. The problem was what to do when a library already exists in the project, how to add more variables to it. I was looking for a way to get a library reference, and somehow I could not see it inside a Project's property (VI Server functions). Hence I posted the question. And upon continuing my search, I found it on the Application's property list.
I hope it was useful for someone else as well. And thanks for the replies. Please share a better idea if you have.
Vaibhav

Shared Variable Engine on Windows PC w/o full install of LabVIEW

I have the NI Developer Suite (8.20) and need some conformation before I get too deep in a project.
First of all, it is my desire to become very efficient on develop compiled executables with LabVIEW 8.20 as my NI Developer Suite license allows me to deploy these programs to any number of machines without facing copyright infringement. I have been successful with this to a certain degree, but am still having problems in the testing stages of my application especially in cases where the hardware I am trying to target does not exist on my developing station. If anyone can point me to white papers that would help me get the mindset to develop in this way, I would appreciate it.
Onto the topic of this post:
I am just scratching the surface of the shared variable interface that is available in LabVIEW 8.2. My project involves two computers where both of them need to share variables back and forth from each other. I've been reading everything I can get my hands on and I am having a hard time answering my unlying question: Is it possible for both of these machines to be running compiled LabVIEW programs and still manage the shared variables between them? That is to say, can one of the machines have the Shared Variable Engine running on it as a Windows service, or compiled into my application executable.
I've read that I can access shared variables from my compiled LabVIEW application through NI-PSP. I am wondering what my limitations would be sans-LabVIEW installation other then the troubleshooting head ache you get from developing applications without direct access to the hardware.
Thank you for your time and submissions.
-Nickerbocker

I am trying to get the "Shared Variable Client - Server" project example compiled so that both the server and client vi's can be run as executables on a standalone machine.
I have created 3 build specifications:
1. "My Server" which is the compiled EXE of the server.lvib. Added that entire library to the source.
2. "My Client" which is the compiled EXE of the client.lvib. Added that entire library to the source.
3. "My Installer" which is the installation package of the vi's and NI supporting software. In the additional installers I have added:
* NI DataSocket
* NI LabVIEW Run-Time Engine 8.2
* NI Measurement & Automation Explorer 4.1
* NI Variable Engine
* NI Variable Manager
* NI-DAQmx 8.3
Some of those are added for future needs. Installed the package on my target machine and run the server executable it appears to run fine but I get various error messages from my client.exe package (which I won't go into detail here, yet). Upon stopping the server I get the message "LabVIEW: (Hex 0x8BBB0005) Unable to locate variable in he Shared Variable Engine. Deployment of this variable may have failed."
I check the services running and see that the "National Instruments PSP Server Locator" and the "National Instruments Variable Engine" are both in the list and "Started." I open up the Variable Manager that has been installed on my target machine and manually add the "waveform" and the "command" variables under a process I call "server" and start the process. After that I start my server.exe that I have compiled from the server.lvib library. The process gives no error messages until the stop button is pressed, and then I receive the message "LabVIEW: (Hex 0x8BBB0011) The connection to the server was disconnected."
The compiled programs run fine on my development machine as well as the uncompiled VIs within the LabVIEW development enviornment. Something tells me that I simply do not have the Variable engine properly configured on my target machine. Also, the process and variables should automatically be populated under "Local System" in the Variable Manager, right? I do not need to add them manually, or do I?
Thanks for your input!
-Nickerbocker

Where can I find the "Shared Variable Properties" VI to be used in my program for configuring SV remotely?

I was using the "configure Alarms" and "configure Logging" VIs to design two user interfaces to make use of these VIs when I came across a problem. In both VIs you can enable logging of alarms. So which one is valid? Which one has priority? Then I looked at the "Shared Variable Properties" built into the project explorer. Now I realize that I am spending all of this time redesigning this properties dialog (which also has two options of enabling logging of alarms (on the Alarms tab to the far right side as well as on the Logging tab). So now my question is, how do I access this "Shared Variable Properties" dialog through my program (Note: this would be on a different machine than where the shared variables are set up. The point is to configure shared variables remotely).
Thanks
Matt

Here is a VI I re-created and posted for all. I'm not sure why NI doesn't provide their VI to the developer. The only thing I can't figure out is that when reading in the "Ack Type" into a variable, it generates an error. It will work if you go into "project explorer" and right click on the library with the shared variable and "deploy" but eventually stops working. I have tried using the "undeploy library" and "deploy library" to see if this would be a work around but had no success.
Just pipe the path of the shared variable into the vi.
Mattk
Attachments:
Shared Variable Properties.vi ‏95 KB

Shared Variable Properties and DSC

Is there a way to assign engineering units to a shared variable as a
configuration parameter? This should be on the "Scaling" page of
the shared variable properties. It seems this is a logical and
convenient place to track units. Assigning units programmatically
using the Scaling:Units property is awkward (to say the least).
On similar lines, why aren't shared variable properties automatically
saved to the DSC historical database? Every trace should have a
set of information that exposes ALL the shared variable properties that
created it. Take something like engineering units for
example: then you would know what kind of historical trace you
are looking at! This seems so basic I can't imagine why it was
missed.
Unless I missed something -- please enlighten me.
Regards,
David Moerman
TruView Technology Integration Ltd.

Hello David,
You are correct in that the units property is not exposed on the
Scaling page of hte Shared Variable properties dialog, and it sounds
like you are already well aware of the existing method to access this
property through the property node interface. As you have also
discovered, the Citadel database that we use with DSC does not have a
built-in provision for storing metadata about the shared variable from
which a trace originates. You can emulate this with, for example, an
array of strings which is also logged to the database, with each string
containing the metadata for a particular trace.
Since it seems like having these features would benefit you, I
encourage you to let our DSC development group know your needs by
filling out product feedback, accessible on our site at
http://www.ni.com/contact . This will send a feature request
directly to the appropriate R & D group, who reads and evaluates
every suggestion made. This is your most direct way to let us know
what features would best meet your needs.
Cheers,
Matt Pollock
National Instruments

Performance of Modbus using DSC Shared Variables

   I'm fairly new at using Modbus with LabVIEW. Out of the roughly dozen tools and API's that can be used, for one project I'm working on I decided to try using Shared Variables aliased to Modbus registers in the project, which is a DSC tool. It seemed like a clever way to go. I've used Shared Variables in the past, though, and am aware of some of the issues surrounding them, especially when the number of them begins to increase. I'll only have about 120 variables, so I don't think it will be too bad, but I'm beginning to be a bit concerned...
   The way I started doing this was to create a new shared variable for every data point. What I've noticed since then is that there is a mechanism for addressing multiple registers at once using an array of values. (Unfortunately, even if I wanted to use the array method, I probably couldn't. The Modbus points I am interfacing to are for a custom device, and the programmer didn't bother using consecutive registers...) But in any case, I was wondering what the performance issues might be surrounding this API.
    I'm guessing that:
1) All the caveates of shared variables apply. These really are shared variables, it's only that DSC taught the SV Engine how to go read them. Is that right?
   And I'm wondering:
2) Is there any performance improvement for reading an array of consecutive variables rather than reading each variable individually?
3) Are there any performance issues above what shared variables normally have, when using Modbus specifically? (E.g. how often can you read a few hundred Modbus points from the same device?)
Thanks,
    DaveT
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.
Solved!
Go to Solution.

Anna,
    Thanks so much for the reply. That helps a lot.
    I am still wondering about one thing, though. According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float. When I create a channel, I pick the F300001 option, and the address that is returned is a range: F300001 - F365534. The range would imply that a series of values will be returned, e.g. an array. I always just delete the range and enter a single address. Is that the intention? Does it return the range just so you know the range of allowed addresses?
   OK, I'm actually wondering two things. Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000? For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0. How would that be handled in DSC?
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.

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.

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

Dsc opc shared variables yields Server Failure

I've been struggling with the transition from DSC 7.1 to 8+ ever since the release of version 8. I use the Allen Bradley OPC server supplied with the DSC module (Industrial Automation OPC Servers v 5.1) to communicate with a PLC 5/30 via Ethernet, or at least I did when I was using 7.1.
Prior to today I always failed to get the shared variables that were bound to addresses in the OPC server to deploy, usually getting an error number that started with -19. However today I finally got it to deploy by keeping the I/O server and the shared variables in separate libraries within my project. Now that they deploy I find that I am unable to monitor them. I keep getting a Server Failure. I have browsed the forums here heavily, and the documentation all relates to remote OPC, which is not what I'm doing here (OPC client and server are on the same machine). I tried changing the login account for the Variable Engine service anyway, but that doesn't help, so I put it back.
I have had some luck simply binding my front panel objects to the OPC server addresses using Datasockets, so it appears that my OPC server is working. However, Datasockets is not a viable option for me because there are times when my project needs to write to a large number of addresses in the PLC sequentially, which never works over datasockets (in my experience).
We have continued to work in version 7.1 because of the challenges of moving to 8+, but since we can no longer purchase DSC runtime licenses for version 7.1 in order to deploy, it seems that we MUST move forward to 8+ or abandon LabVIEW altogether (which is certainly an option).
For clarification, I am now working with version 8.2 (but I've been fighting with it since 8.0 without much success). If anybody out there can think of a critical step that I might have missed that might cause this, or if there is a known solution, I could really use (and would greatly appreciate) the help. Thanks!

Nobody out there seems to have any answers for this, so I kept pounding on it (and pulling my hair out). In the end I finally succeeded in getting one of my old 7.1 DSC projects to run on 8.2. Here's what I did:
1. I begin with a fresh installation of Windows. I tested it with both 2000 and XP Pro. Vista RC1 will absolutely NOT work!
2. Install LabVIEW 8.2, DSC 8.2, and just the OPC server that I need from the IA OPC CD (in my case the Allen Bradley server)
3. Open the IA OPC server editor, and create a new file with an object in it for my PLC (PLC 5/30, Ethernet in my case)
4. Save, set it as the startup file
5. Run LabVIEW, create an empty project
6. Add an IO server
7. Launch Multi Variable Editor, load project file created in step 6, and bind one variable to PLC address
8. Save all. Uncheck auto deploy for the library, and deploy all.
9. Launch variable monitor, browse to new variable, double click to monitor.
10. This will ALWAYS fail with "server failure". Don't worry, just exit completely out of LabVIEW.
11. Stop the Variable Engine service.
12. Run OPC server editor again, and load up the lpd file from your old project. Modify if needed, save, and set as startup
13. Start the Variable Engine service again.
14. Launch LabVIEW
15. Create a new empty project (I created mine in the same directory as my old 7.1 project resided)
16. Add an IO server, and uncheck auto deploy for its library
17. Save all
18. Run Tools->DSC->Migrate->import scf
19. Convert your old SCF file
20. Add the new library to your project (it will be named LabVIEW)
21. Uncheck auto deploy for the "LabVIEW" library you just added
22. Right click on the "LabVIEW" library and do deploy all
23. Save, and open the variable monitor
24. Browse to a tag in the LabVIEW library, and double click
25. This time it will actually monitor the variable, with a status of "Good"
26. Now you can add your main front panel VI to your project, open it and run it
27. Version 8.2 will select the proper legacy tag read/write VI's, whereas 8.0 does not. The writes however do not work. Replace them with shared variable writes. The reads work fine.
28. The empty project that you created in step 5 is a throw away. It will never work anyway.
29. So far the only variables that I can get to work at all are the ones that I import from an scf file, which is a pain, but if I must create all my tags in 7.1 and import them into 8.2 I will (for now). I may try exporting to Excel and copying variables that work in order to get functional new variables, since binding them in the editor does not work.
I hope this helps anybody else out there struggling with moving to 8+ DSC. I saw a few posts with similar issues, but without ANY answers at all. It's a convoluted solution that doesn't make a lot of sense, but for me it is repeatable.

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

Programming batch modify properties of shared variables DSC Module

Similar Messages

Maybe you are looking for