Shared Variable VI development on machine other than server

[CoastalLabVIEWER]

I'm about to do my first shared variable code, I read the white paper

http://www.ni.com/white-paper/4679/en

Something that isn't immediately clear to me is the expected work flow in actually creating ALL the VIs using the shared variables.  I tried creating the project and the variable as per instructions, easy.  But I'm going to have one of those VIs running as the server of the data and one as the client.  Would these be two seperate project files with the same variable name and type?  One project file with seperate builds for server and client executables?

Actually, SV might not even be the best way to do what I need.

I have a PXIe machine with a slot 0 controller that has a mux (a pxi-2503) and dmm (pxi-4072) for getting measurements from multiple channels.  Rather than calling via VI server every time I want to grab a measurement I'd rather have an application running waiting on commands.  I was thinking of creating a crude command/acknowledge data avail/acknowledge scheme to synchronize the PXI slot 0 with the client that will be requesting the data, but I can imagine there is probably a more suitable framework that someone else has no doubt tackled?

I just need to guarantee that the rack takes the measurement when I want it to (ie, after some other action I've triggered the system to perform) and that the data I get back from it is identifiable.

Ideally, I'd have a MXI controller and this gets really easy but I won't be able to get ahold of one for months if at all so I'm going this route for now.

[MarcusB]

To answer your question about workflow: you can just have one project with seperate builds for the server and client executables. Just be sure in your build properties you have included any shared libraries for each build.

[CherryPointer]

Hi Marcus,

When I drag a shared variable from the project window into the block diagram and then left click it and go to browse, I'm only presented with variables on my local machine to choose from.  If I switch into programmatic access and then go to browse I'm presented with a nice list and am able to browse to the remote shared variables and select it for my constant/control.  This works fine and I'll remember to do this from now on, I just wonder why the two different behaviors.

I have this working quite well provided I go ahead and start the VI running either with a built exe or through the vi.  As these instruments are going to ultimately be sitting in a headless (no monitor/mouse/keyboard) PXI with slot 0 rack, I am now trying to figure out how to either start these VIs running remotely.  I thought I'd just be able to drop the .exe into a windows scheduled task and have it run on start up.  This works fine but my client VI doesn't communicate.  If I go ahead and log in to the machine I can see the exe running in the Task Manager.  If I kill that exe and start a new one then I'm able to communicate with the VI though with some initially odd behavior, almost as if when I was running it on the client the SVE had changed the states of the variables locally and then when the new process was started it latched those states and causes me to have race-like conditions.  If I then kill that exe and start another one everything is in its expected "default" state and I don't have race like conditions or get into unexpected states.  I can probably add some code on the client side to avoid this weird behavior but I'd rather understand why things aren't working.  My guess is the SVE and other NI processes on the headless box aren't starting properly until I actually log in?