Shared Variable issues with real-time executable

[abanica]

We have a PXi target running Labview Realtime 8.5 and we use a series of shared variables to communicate between the target and the client software. The code has been developed (and extensively used) over the last 2 years and has not presented any problems with the shared variables when deployed from the Project Explorer (for both the target and Laptop based client software). However, when trying to run an executable version on the PXI real-time target of exactly the same code the shared variable engine seems to fail on initial loading. Since it is an executable it is difficult to display any errors but it seems that the crash happens right at the beginning of the program when we try to initialize a number of shared variables. Sometimes it does load but probably only 10% of the time. When connecting the Debug tool to the code and restarting the executable it is runs with no issues. Once however we did manage to capture and error (error -1950678982 The shared variable client-side read buffer is full).

I have checked a number of posts in the Knowledge Base (for example How Do I Deploy Network Shared Variables from a Compiled Executable?) but it has still not solved the issue. Any thoughts and suggestions?

Adrian

 

[Will_S.]

Hi Adrian,

To confirm: are you in fact using an Invoke Node to deploy your shared variable library from within your executable? Do you have buffering enabled?  Are you using RT FIFO? In what order are you starting your host/target? Which is hosting the variables?

[abanica]

Will, the shared variable library has about 30 variables in it and some use buffering while others use the RT FIFO feature (but not all of them). Typically we start the RT target first while not connected to the host and the host will connect at a later time (the RT target is supposed to startup in this mode and start recording data independently of a host or not). Due to this I did try the InvokeNode within but I got an error (what I recall is that the error was 'Function not supported' or something like that). If this is a path that I will have to go on I can dig into it and forward the actual error that it generates.

[Justin_P]

Hi Adrian,

Will asked a good question.  What is hosting the shared variable the host or the target?  If they are on the target check to make sure that they are deployed in the Shared Variable Manager before you run the executable.  If your shared variables are hosted on your real-time host machine then you should be using the invoke node to deploy the shared variable.

Please let us know where the shared variable library is located.

[abanica]

It is hosted on the RT target and at one point I did try the invoke node function but got an error as mentioned above. I am planning to retry it in the next two days and find out exactly what the issue was. I am running Labview and RT 8.5 so it should be supported. Would I have to use a sequence structure since the SVE takes a while (seconds) to deploy and ensure that no code gets executed before it is up and running?

[Justin_P]

The wait with the sequence structure is the way I would do it (if someone has better way please feel free to chime in).  I would also place an error indicator right after the deploy invoke node for debugging. 

Please give me an update after you get a chance to test this.

[abanica]

Finally back in the lab and I was able to test the Invoke Node code again. I did get Error 1043 as I remembered from last time. This error seems to indicate that the Invoke Node Library:Deploy Library Method is not supported in Real-Time. However, the help indicates that it is supported by Real-Time Operating System but I am not sure if this includes the case when running as an executable. I also read somewhere that the SVE can give misleading errors sometimes so just to make sure that I am using the method correctly here are the inputs to it:

- left the IP address empty

- the path for the library is C:\ni-rt\startup\data\Shared_Variable_Library.lvlib. Is this correct? Does it have to be a relative path or not include the library name?

The version of Labview RT I am using is 8.5 as reported by MAX. At this point I am stuck from the looks of it...

[abanica]

I should have added that the method does not work even when trying to execute it from the Labview Project manager so is it really not supported by 8.5?

[Justin_P]

Hi Adrian,

Right click on your  shared variable library in Project Explorer and select save as.  Now just save the library to you C:/ drive. Now put this code at the start of your program (use the IP of your target).

You shouldn't have to wire anything else to it.  Let me know if this gives you any issues.

[abanica · Accepted solution]

I have been testing it for a few hours now and I can't make it fail again. The big difference in my implementation was to use your suggestion and not wire the error cluster throught the method since the error it generates was causing a number of issues later on. So let me then summarize the final configuration that seems to work:

- running and executable on a Real-Time 8.5 target, booting it up while not connected to a client. Shared variable library hosted on the target and needs to load by itself.

- I added a flat sequence structure on the 'main' vi (the top executable vi) with an Invoke Node method (as shown above) in the first structure together with a timer of 10 sec and the rest of the code in the second part of the structure. The shared variable library was copied to the target in a data directory and the path provided to the method (same path as above) and the IP address was that of the target.

I found out that it takes about 8-9 seconds for the shared variable engine and the library to start (I am sure more is going on that just that) and it is important to wait this time before initializing shared variables or the behaviour was unpredictable. The method still generates Error 1043 (function not supported) but I simply ignore it now and it seems to work.

Thanks for your help! I will let you know if there is some instability in the future but it all looks good as of now.