LabVIEW and OpenG on a network

[jeffwass]

In our research lab we have a few Windows XP machines, networked together, for data acquisition and processing purposes. The actual computer I'll be using depends on which experimental system I'll be using, but I'll be using the same acquisition and storage VI's on each computer.

The issue comes with synchronizing VI updates. If I update RoutineX on Computer1, then if I use RoutineX a few days later on Computer2 I want to use the updated version. And similarly, if I update the routine again, I want the changes back on Computer1.

The way I am dealing with this now is by arbitrarily picking one lab computer as a 'server', where I store all my VI's. When I load VI's to insert, I always do it through the network, so VI's have a pathname like :

"\\ComputerName\username\Routines\Acquisition\Measure.vi"

This method works pretty well, all my routines work fine and will be properly updated if I change them, no matter which computer in the lab I am accessing them from.

I have just started using some other user-supplied tools, such as LuaVIEW and OpenG. LuaVIEW can put its VI's and palette menu anywhere, so I do that over the network. But - the OpenG tools want to go to the local computer, in the LabVIEW install directory. So for I need to install the OpenG toolkit on each local computer that I want to use it.

I'm wondering I'll be shooting myself in the foot sometime down the road. As long as each computer has the exact same version of OpenG stored in the same path, then it shouldn't be a problem whether I use a subVI that comes from the network or locally.

I'm wondering if anybody else has thought about these issues, even if you don't use OpenG or other add-on libraries, to keep your usage of VI's synchronized from a network.

[jpdrolet]

In our research lab we have a few Windows XP machines, networked together, for data acquisition and processing purposes.  The actual computer I'll be using depends on which experimental system I'll be using, but I'll be using the same acquisition and storage VI's on each computer.

The issue comes with synchronizing VI updates.  If I update RoutineX on Computer1, then if I use RoutineX a few days later on Computer2 I want to use the updated version.  And similarly, if I update the routine again, I want the changes back on Computer1.

The way I am dealing with this now is by arbitrarily picking one lab computer as a 'server', where I store all my VI's.  When I load VI's to insert, I always do it through the network, so VI's have a pathname like :

"\\ComputerName\username\Routines\Acquisition\Measure.vi"

This method works pretty well, all my routines work fine and will be properly updated if I change them, no matter which computer in the lab I am accessing them from.

I have just started using some other user-supplied tools, such as LuaVIEW and OpenG.  LuaVIEW can put its VI's and palette menu anywhere, so I do that over the network.  But - the OpenG tools want to go to the local computer, in the LabVIEW install directory.  So for I need to install the OpenG toolkit on each local computer that I want to use it.

I'm wondering I'll be shooting myself in the foot sometime down the road.  As long as each computer has the exact same version of OpenG stored in the same path, then it shouldn't be a problem whether I use a subVI that comes from the network or locally.

I'm wondering if anybody else has thought about these issues, even if you don't use OpenG or other add-on libraries, to keep your usage of VI's synchronized from a network.

3348[/snapback]

OpenG VIs are put in the user.lib directory to be easily located by VIs using them. When a VI calls a VI from user.lib, the callee's path is stored relatively to user.lib directory in the caller. Then it is not dependent of the path where LabVIEW is installed and OpenG VIs are easily ported e.g. not always searching and relinking to new location on a new target. In your case, when a VI is saved from one computer and opened from another, it will always link to the local version of the OpenG VI, exactly as it does for VIs from vi.lib.

Another solution may be to share the LabVIEW directoty on one computer. On other computers, set the path option "Library Directory" to this share. Then all LabVIEW instances will share the same root directory. That includes the same vi.lib, user.lib, instr.lib and also help and project(Tools) directories. You will have to install OpenG only on the shared instance of LabVIEW

I used to do that with LabVIEW executables but the "Library Directory" is not effective anymore in recent versions of LabVIEW (even if the option is still available, it doesn't work).

Edit: See here

[Jim Kring]

In our research lab we have a few Windows XP machines, networked together, for data acquisition and processing purposes.  The actual computer I'll be using depends on which experimental system I'll be using, but I'll be using the same acquisition and storage VI's on each computer.

The issue comes with synchronizing VI updates.  If I update RoutineX on Computer1, then if I use RoutineX a few days later on Computer2 I want to use the updated version.  And similarly, if I update the routine again, I want the changes back on Computer1.

The way I am dealing with this now is by arbitrarily picking one lab computer as a 'server', where I store all my VI's.  When I load VI's to insert, I always do it through the network, so VI's have a pathname like :

"\\ComputerName\username\Routines\Acquisition\Measure.vi"

This method works pretty well, all my routines work fine and will be properly updated if I change them, no matter which computer in the lab I am accessing them from.

I have just started using some other user-supplied tools, such as LuaVIEW and OpenG.  LuaVIEW can put its VI's and palette menu anywhere, so I do that over the network.  But - the OpenG tools want to go to the local computer, in the LabVIEW install directory.  So for I need to install the OpenG toolkit on each local computer that I want to use it.

I'm wondering I'll be shooting myself in the foot sometime down the road.  As long as each computer has the exact same version of OpenG stored in the same path, then it shouldn't be a problem whether I use a subVI that comes from the network or locally.

I'm wondering if anybody else has thought about these issues, even if you don't use OpenG or other add-on libraries, to keep your usage of VI's synchronized from a network.

3348[/snapback]

Hmmm, it sounds like you could benefit from a networked source code control system (such as CVS or SubVersion) to keep all of your project files sync'ed. Once you get over the learning curve, this is light years better than a networked project folder.

Jean-Pierre summed up most of our reasoning for putting files beneath user.lib. But, you can find a little more info on OpenG's integration strategy here:

http://www.openg.org/tiki/tiki-index.php?p...grationStrategy

Also, we are working on a better way to keep packages synchronized between developers/systems using a project. We are going to support a system configuration file that will detail all the package requirements of a project and easily allow you to change between configurations. Couple this, with a networked repository of packages, and getting the right OpenG packages installed will be a breeze. OpenG Commander is coming soon!