Errors when Programmatically Deploying a Shared Variable on a Real-Time Target

[teslaaaa]

When I deploy a library using the invoke node above. If the library contains variables which are network published or single process it will deploy fine.

But if the library contains variables which are I/O Aliased. Then i recieve an error:

Error -2147467259 occurred at Invoke Node in Test Deploy.vi

Possible reason(s):

LabVIEW:  (Hex 0x80004005) Unspecified error.
=========================
NI System Configuration:  (Hex 0x80004005) Miscellaneous operation failure.

Method Name: Library:Deploy Library

But if I deploy the same library thru the project explorer it works just fine.

Ideas?

[Bob_Schor]

I (sadly) gave up on deploying NSV.  I actually had a scheme that seemed to work (though it was annoying to wait for the deployment each time I ran the program), and it completely failed when I tried to do this from an executable.  So now I say "LabVIEW Project Is My Friend" three times a day ...

BS

[marcello.zoppetti]

Hi teslaaaa,

it's a couple of hour that I'm looking for a topic talking about deploying shared variables and finally get your!

The problem is the same: if I try to programmatically send a library with a shared variable which is I/O aliased the system return error code -2147467259.

I see that the data of first post is one year old, maybe you (or someone) finally got solution and would share it with the community 🙂

[teslaaaa]

Unfortunatly no great fix was found, NI documented the error and put it in a list of potential fix's, but i dont believe it has ever been fixed.

My work around was to deploy all modules and channels from the project exporer window. Create a real time application, make it "run as start up", then reboot the chasis. I then verified that the program was running on the chassis.

Then I created an image of that chassis with the  "Create system image.vi" 

Then from your UI.vi in the intialize case i would check the chassis to see if it was running the real time application already (VIA a UDP heart beat check) , and if not then have it deploy the image, and reboot the chassis.

This is not a great fix, because it takes 3-4 minutes to deploy an image. So every time you need to load a new program into your chassis it will take 3-4 minutes before the UI can communicate with it. Not ideal

[Bob_Schor]

My mileage varies.  As I wrote earlier, my Network Shared Variables are hosted on my Remote Target.  When I build the executable for the Remote (a .RTEXE file), I specify it as "Run as Startup".  I also have the Remote program set so when it exits, it reboots itself.

Now when I run my Host program (assuming that the Remote is already powered on), it is instantly available for connecting.  Even if I forget to turn the Remote on (and thus my Host "hangs" waiting for the Target), it takes less than a minute for my Remote to boot and start running its StartUp code, which is the Remote Executable.

Bob Schor