From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Programmatically deploying/undeploying shared variables individually

Is this possible yet, or must the entire library be deployed/undeployed via the traditional library invoke methods? I have (to some regret) kept everything in a single library and would now have to create separate libraries and (seemingly) re-reference each variable contained in the new library. If I must go this route still, is there an easier way to move and re-reference these without breaking everything? Every item I will want to move is basically a sub address mapped to a single master I/O Server Modbus binding. 

0 Kudos
Message 1 of 4
(2,541 Views)

As an update to this: I have found that I cannot use this invoke method (app.library.UndeployLibrary) within the RT target. Now it looks as though I may need to create separate versions that omit the library altogether! Smiley Frustrated

 

Controller is a cRIO-9068. 

0 Kudos
Message 2 of 4
(2,513 Views)

What version of LabVIEW are you running, and do you have any extra toolkits?

 

My experience has been that you can only deploy variables by library, although I think that you can dynamically create shared variables in the SVE and then access them by name if you have the DSC.

 

Also, there’s a KB entry that might allow you to do the same trick, but with generating the new variables into a library. YMMV, of course

 

 

Message 3 of 4
(2,508 Views)

I will look into this. Thanks for the resource.

 

I guess I should backtrack a bit to explain my issue a little further. I am using I/O Server to create ModBus address objects as shared variables to pull data from a solar panel charge controller, which is how this slave device communicates data and other status information. I've run into an issue, which seems to be implied through careful version control, where having this Modbus shared variable library deployed will actually cause module I/O failure if the slave controller is powered off for x amount of time, or the serial cable is unplugged. It's like the system times out the library or something, at which point I lose I/O and have to power cycle the controller. 

 

I isolated this test by branching out a completely identical project and just removing the Modbus library, deleting any object in the code associated with the library. No issues when these libraries are undeployed. Since I had everything under the same .lvlib, I partitioned the lvlibs, one for the couple shared variables I use, and then another for the Modbus library since I'd had no luck deploying by individual object. This is where I ran into the issue of the RT side of things not allowing library deployment. 

 

0 Kudos
Message 4 of 4
(2,485 Views)