Datasocket shared variable api

[GoCougs]

The newest version of our drivers are fully supported and compatible with the 4 previous versions of LabVIEW. So installing the newest version of IMAQ would still be compatible with LabVIEW 8.6. Both versions would work with the same version of IMAQ drivers

[Vaibhav]

Thank you very much Scott!

Here, I have received some of the most clear answers so far. 

Will start installing the LV 2010 Fall version on one of the computers now.

A step further in the shared variable implementation - 

When I build an installer of my application, if I have used shared variables in the included VI's, do I have to explicitly specify any toolkit in the supporting files? Or the files/support needed for shared variable will automatically be included? Since I will make VI's which will be installed on other computers, I will have to use "Target specific" shared variables. But how do I "move" a shared variable? By including only the containing library in the installer/builder?

[GoCougs]

I found an article that answers all of your questions here https://www.ni.com/en/support/documentation/supplemental/07/using-shared-variables-in-executables.ht... This article should give you a good idea of how to use shared variables in an executable and how to avoid potential problems that can occur when using them. I hope that helps!

[Vaibhav]

Thanks a lot. Reading now. 

In fact, my programs are already with datasocket, and due to one limitation of datasocket, I started exploring shared variables for sending/receiving messages also. Till now I had implemented shared variables for globally sharing a variable data only. And I need to check every aspect of shared variable implementation, to see if it's worth changing the whole programs or not. Because for that limitation of datasocket I already have a workaround logic in mind.

Seems like there are many articles on Shared Variables, but they are all scattered under several titles, and the LabVIEW is not an exhaustive collection.

Will thoroughly read the article and related articles, and make some sample tests and will get back to you in case if I find any issues. Thanks again for all the support. 

[Vaibhav]

Some confusions/doubts.

1) As mentioned in the comments in the document Using Shared Variables in Executables, I am also not sure how the Shared Variable Engine will be installed on the computer not having LabVIEW? Or do I really need to install SVE on each and every computer using (subscribing) the shared variable, and not necessarily publishing them? In my project, only one computer will have the shared variables hosting and this computer's application won't be installed on some other computers (for now at least). So the client applications (subscribers only), being built for installations on other computers without LV, really need SVE on those computers? If yes, how do I install SVE there?

2) As I understand, there are two ways to use shared variables at client side (subscribers) - 1. by referring the "psp" URL in block diagrams to datasocket functions, or 2. by creating shared variables in the projects of these client applications and binding them to the original (publisher) shared variable (using "psp" in the properties window), and then just dropping these bound shared variables as nodes in my client applications. As I understood, the datasocket way of accessing the remote shared variable does not support buffering (my experiments told me this). And if I want to use shared variable nodes (without datasocket functions at all), I must create a bound (subscriber) shared variable for each corresponding publisher shared variable. In this case, the configuration of "psp" is only at design time and nowhere in the program I would have to mention "psp" URL. And the variables thus created can be deployed as these help pages mention. Right?

3) In the document, “How Do I Deploy Network Shared Variables From a Compiled Executable?” in the section "Before LabVIEW 2009" it is explained how to include the shared variable library in the build. And the next section - Deploying Shared Variables From Windows - says about deploying. I am not sure if the section "Deploying Shared Variables From Windows" is a subsection of section "Before LabVIEW 2009" or is an alternative method for deployment in versions prior to 2009.

It is not clear if I need to do both of the steps for versions prior to 2009. From the point 3, it seems like both the steps are necessary. And in that case, i.e. if it is mandatory to programmatically deploy the library using method describe, what path shall I give? A relative path (since the library will be moved along with the application to another folder on another computer where it will be installed)? Or I should just select the file and it should be fine. It says to select the library file. But not sure if they mean to say "select from the executable's data folder" since this data folder will be created after generating an EXE. So logically I should just select the library from my hard disk's location (and it should automatically "find" it from the included libraries in my build). Am I getting it correctly?

-----------excerpt from the document---------------

Before LabVIEW 2009
In order to use a network shared variable in a compiled executable in versions of LabVIEW prior to LabVIEW 2009, it is necessary to first deploy the shared variables before they are to be used in the program. When you create a new application (EXE), under Build Specifications»Application (exe)»Source Files, add your top level VI as the Startup VI and then add all libraries that contain network shared variables to the Always Include (previously Support Files) list. Also, make sure to set the Destination of the libraries to be Support Directory in the Source File Settings category.

Deploying Shared Variables From Windows
This can be done by utilizing the Deploy Library method of an Application Control. To find the Deploy Library method:

1. Right-click the block diagram to bring up the programming palette and go toProgramming»Application Control and place the Invoke Node on the block diagram
2. Using the hand tool, click Method and select Library»Deploy Library

3. Use the Path input of the Deploy Library invoke node to point to the libraries containing your shared variables. If the libraries were included in the executable's Support Directory, as directed above, the libraries will be copied to the executable's data folder. Point the Path input to these libraries.

[Verne_D]

What have you tried thus far? Are you running into errors or just looking for clarification in the documentation? Regarding your first question, you can include the NI Variable Engine in the additional installers category when building an installer for your application. You'll notice that in the components installed in the standard run-time engine, the Variable Engine is included. The Before 2009 methods are an alternate procedure.

I'd recommend giving this a shot and let us know if things are not working.

[Vaibhav]

Ok, thanks for your attention and the answers. 

Here's my situation - 

I am building a large scale system for research/demonstration purpose, and in my university lab (the two labs for me), there is hardly any computer left without a LabVIEW installation on it.

And once done, the project applications will be run mainly over computers without LV (outside our Univ. network). So it is very much necessary for me to make sure the installers don't miss something, and it's difficult for me to test it practically here (due to lack of computers without LV installation). This is one reason I am confirming here a lot. In the past I have built installers, and it took me some time to make sure what is needed and what is unnecessary in an installers. Because the installers (even for a small application) are very large. 

Another reason is that, I have spent too much time on working with Datasocket servers and there is one functionality in which I was totally mistaken - multiple writers to the same item at the SAME time. I started a thread for this too, because I didn't know what is the reason. And I made this discovery only after spending too much time in coding (wiring) and designing my whole application. You can imagine, my whole application structure was based upon the assumption that I can write to the same datasocket item from multiple points. This is true, but not very true. I can write from multiple points, but not if they all happen on the same time. And there was no way for "guessing" this, because I assumed the "timeout" input/output in the DataSocket Write function is for THIS (like for Queue). Wrong assumption. Very expensive assumption. And I could reach to this revelation only after making a test run (when one part of the system was completed, because only then I could see "realistic" scenario). 

And now I need to change my program architecture because of this. When the programs are too big, and if some key functionality (implemented on 50 places) needs to be carefully replaced, it makes you think too much before you commit such mistake again. So in the case of Shared Variables, I am trying to make all points clear and no assumptions, not even the simplest assumption. 

I can still use datasocket by changing the logic and introducing queues, but that's not the point. I don't want to go further with some more assumptions only to find that I made a wrong selection, or my logic was wrong, due to my half knowledge.

So, basically I am just going through a learning phase to make sure how things work. And in that way, I asked several questions. 

Now, about what I have tried so far -

I have already implemented shared variables and bound shared variables, and they work well. Also I deployed them programmatically (programmed and  built on LV 8.6 machine, and executed on LV8.6 machine too). And let me tell you, the two methods under "Before LabVIEW 2009" are not an alternate procedure. They are two steps - first the library must be included in the builder (EXE) and for this to run well, it must also be deployed inside the program. At first I just deployed in the builder and programs didn't run well. I had to deploy it also inside the program using "deploy library" function. Please let me know if this is not correct (if they are indeed an alternate procedure). Because my question about which path to mention in Deploy Library function, still continues. In my test, I put just "data\library.lvlib" (a relative path, because I know the data folder is just in the same directory as the application exe), but am not sure about the installer directory structure.

My second question about PSP URL was more of a conceptual. Because no one document clearly says that "there are two ways of using shared variables, either manually by project explorer or by psp url for datasocket" (another way introduced in 2009 was programmatically creating shared variables). The usual language used in documentation is somewhat fuzzy, it says about one way and not very clearly about the other way. So there is always a confusion, because I need to know the contexts in which one or the other method is recommended. I guess I have figured out now. 

In my application, I have some shared variables which can be predefined and then there are shared variables which are created dynamically (as a user logs on, the server should create it). For datasocket items, this was very easy, and natural. For shared variables, now I made a test and it works - for those predefined shared variables, I create subscriber libraries (with variables bound to the server/publisher variables) and deployed in client applications and for those dynamic shared variables I use "PSP" URLs with Datasocket (assuming the variables are created already on the server). Any comments to improve this method are highly appreciated. The dynamic creation of shared variable is also possible in LV8.6 (in DSC there are libraries and processes) but I am not sure if it's possible in my case. I still have to study that. 

Thank you!

[jgcode]

---

@Vaibhav wrote:

And once done, the project applications will be run mainly over computers without LV (outside our Univ. network). So it is very much necessary for me to make sure the installers don't miss something, and it's difficult for me to test it practically here (due to lack of computers without LV installation).

---

I would recommend looking into Virtual Machines.

Depending on the use case, it can be an easier and cheaper alternative than a physical test machine.

Cheers

-JG

[Vaibhav]

Hi JG,

Thanks for your comment and sorry for being slow in reply. 

Yes, VM are surely a good option, but I have had bad experience in the past with VM installed on one of my machines. Besides using up a big memory allocation, the VM also created other problems in the system that I had to undo it. 

But the availability of test machines is just minor issue. The major one is that the real system testing for my purpose happens only after a big scale installation/implementation of the program, because certain complexities appear only at that level. So if I know certain limitations of a functionality beforehand, it would save up lot of troubles later. Hence doing all this research. Lately have been trying many things and so many exciting discoveries as well as setbacks are found. 

Looking at the number of recent and old threads covering the issues involving Shared Variables and Datasockets, I guess there are many LV soldiers out there fighting the same war.

🙂

[Vaibhav]

Well, I tried many things and updations and ran into some situations like this (as I had feared in this message thread, but now resolved) and this+this as some other problems related to Shared Variables.

Just sharing information to someone who might run into similar situation, or someone who may have a better solution.