Shared Variables in Built Application containing a Web servicer and Web Services VIs

[mjaspan]

I'm deploying a built application with LabView 2009 and having trouble with Shared Variables. I have a suspicion what's going wrong but am puzzling over how to proceed. I'll describe it in more detail below in the hopes a generous programmer will throw me some pointers. (pun? what pun?)

The application consists of several VIs (front panels on the screen) built as an application (EXE) and Web services VIs (RESTful) together in one Build with Shared Variables. The trouble is that it appears as if there are two instances of each Shared Variable; one from the application VIs in the EXE and one from the Web services VIs. The values in the Shared Variables are communicated correctly between the application VIs and also between the Web Services VIs, but not between the application Vis to/from the Web Services VIs.

--

more detail:

I have 3 VIs which control various instruments. These VIs have front panels intended for human users to interact with. These VIs are all in the same Project where several Shared Variables are declared. The VIs share data using these Shared Variables.

The Project also includes a handful of Web Services VIs which respond to HTTP requests. These VIs are built with the RESTful specification. These VIs also use the same Shared Variables to communicate.

Building all of this into one application took some doing. I finally figured it out by using the following instructions to glue it all together and create an installer.

http://zone.ni.com/d...p/id/7747#toc12

In summary, the directions say to create a Web Services (RESTful) Build Specification with the Web Services VIs, then Build it. And then include the Built web services (niwebserver.conf) into an Application (EXE) Build Specification with the application VIs. After using the correct magic runes (as described in that link) It all gets bundled into a neat package complete with installer. Simply delightful.

The trouble is that the Shared Variables behave as if there are two instances of each variable - one for the application VIs and one for the Web Services VIs. I can see how this is a likely outcome of this two-step build procedure, however I am unsure how else to create a Build Specification which includes both kinds of VIs (Application and RESTful).

--

Example story:

ApplicationA.vi: set Variable X = 5

ApplicationB.vi: read Variable X

result: 5

WebServiceA.vi: read Variable X

result: 0

WebServiceA.vi: set Variable X = 10

WebServiceB.vi: read Variable X

result: 10

Application B.vi: read Variable X

result:5

--

Anyone out there worked on something similar? Looking for suggestions for convincing the Shared Variables to behave as I desire. (ie one instance for each).

I am using Single Process shared variables. I suspect that a possible solution will involve using Network-Published shared variables, though I'm not clear if that's the best way to go given that this all resides on one machine and one application. I am in the process of investigating the Network-Published shared variables to determine if they will work here. Alternatively I have built VIs which communicate using VI server and pulling/pushing values directly from/to the Front Panels, but that feels like having to start my car by manually turning the crank at the front bumper....

If it helps I can produce a stripped down version of my Project which illustrates the issue.

Thanks for any advice,

Martin

[PaulL]

Martin,

I'm not sure I understand everything you are doing, but, yes, using single process shared variables might be a cause of the issue you see. Use single process shared variables only to share data within a VI. (See Using the LabVIEW Shared Variable.)

For the record, you can use networked shared variables to communicate between processes running on the same machine as well as on different machines. (The communication performance will just be better if everything is on the same machine.) (Hmm.... I don't know that you couldn't use networked shared variables to communicate within a process--I think this would work but that certainly is not their purpose.)

(A bit of a tangent: I just realized that pretty much if two things really have to run in parallel and communicate with one another I make them separate processes anyway.)

Paul

P.S. I liked the pun.

[mjaspan]

Paul,

thanks for the feedback.

Single process shared variables can be used to communicate between VIs as well as within a VI. Referring to Using the LabVIEW Shared Variable, the key is that the multiple VIs be in the same application instance. This is the feature I'm trying to use.

To be more concise about the challenge I'm trying to solve, I'm trying to compile and build a project which includes both regular VIs and Webservice VIs *in the same application instance*.

It works fine to compile compile and build multiple regular VIs in same application instance OR multiple Webservice VIs, but not both. Apparently the instructions at LabVIEW Web Services FAQ, only partially accomplish building them all in one application instance as evidenced by the separate-instances of the single process variables. Probably what it accomplishes is an application instance within an application instance.

I'm still working on it. I'm poking around with network shared variables now. If that fails I'll see if the folks at NI have an idea about how to compile and build a project which includes both regular VIs and Webservice VIs in the same application instance.

thanks,

Martin

[PaulL]

Single process shared variables can be used to communicate between VIs as well as within a VI. Referring to Using the LabVIEW Shared Variable, the key is that the multiple VIs be in the same application instance. This is the feature I'm trying to use.

You are correct. I didn't read the whole sentence correctly and, well, it reveals I don't use single-process shared variables. (We always use the networked versions.)

When we use networked shared variables in two projects we can alias one to the other (so LabVIEW really does deploy two libraries in that case), but I don't know what to do for single-process shared variables. I don't know why LabVIEW wants to deploy multiple instances of a single library if there is only one library (and one application instance) in the project. I would definitely agree it is time to call NI! I wish I knew more!

[mjaspan]

Problem Solved.

Paul, you were right, the solution resulted from calling NI.

Luckily my company has the support subscription. The tech support guy I reached at NI talked me through it.

The solution was two fold. (I'd tried both solutions on my own, but not at the same time)

First, it's important for all of the VIs to be within the same application instance for the Single-Process variables to work AND it does not seem to be possible to prevent the Web Services VIs from existing inside their own application instance.... Thus Network-Published shared variables are required.

Second, in Build Specification, I needed the "Deploy shared variables at application execution" check box. Apparently things work intermittently (rather than not at all) when I neglected properly deploy the shared variables.

I've built a small example Installer which deploys the VIs and the Webservices VIs and the Network Shared variables all work. I'm now incorporating the changes into my real system.

Thanks for the response. Hopefully if someone else stumbles on this issue, they will also stumble on this discussion.

Martin