LabVIEW 8.5 on a multi-user Windows 2003 Server
(1 votes, average: 4 out of 5)
Loading ...
Large majority of LabVIEW developers use Microsoft Windows as the development environment. However only single user Windows environments namely Windows 2000/XP/Vista are supported by National Instruments. We lately experimented installing LabVIEW 8.5 on a Windows 2003 server with multiple simultaneous users over terminal services remote desktop connections. Our initial experiences are encouraging.
Although Windows 2003 server was used for this experiment, the results can be applied to other Windows environments with multiple users as well. It can be beneficial to more carefully separate multiple users all using a single workstation with a single LabVIEW installation.
Background
Windows 2003 Server is a server environment from Microsoft that’s based on Windows XP platform. As most components of the server environment are in common with Windows XP, it’s propable that most XP applications run on top of Windows 2003 server. We decided to test if we can get one LabVIEW installation to properly work on a multi-user Windows environment.
The LabVIEW applications we develope communicate with an enormous bioinformatics database. The database transactions forms a bottleneck of our system. We would greatly benefit if the database would be running on the same server as the LabVIEW applications. Our LabVIEW applications are constantly under development. Therefore it’s not meaningful to build an executable of each version of the applications, but rather execute the applications directly under LabVIEW development environment. From these starting points we decided to set-up a Windows 2003 server environment with terminal serivces service to allow remote desktop connections of multiple simultaneous developers. We installed LabVIEW into this environment and set it up to allow multiple developers simultaneously develop and run their LabVIEW applications on the server.
Installing and setting up LabVIEW
The installation of LabVIEW into a Windows 2003 server environment is rather straight forward. The installation requires administrator level priviledges but otherwise there is nothing special in the installation itself. However setting up LabVIEW for the multi-user environment requires some extra steps.
LabVIEW Configuration File
First we noted that simultaneous users cannot share the LabVIEW configuration file located under LabVIEW installation folder. Instead each user needs to be able to have a configuration file of their own. LabVIEW has a special command line argument that allows manually setting the configuration file used. We noted that if we set LabVIEW to use configuration file under %HOMEPATH% symbolic folder, LabVIEW allows each user to customize their LabVIEW development environment separately from other users. So after installation of LabVIEW we changed all LabVIEW shortcuts located below folder C:\Documents and Settings\All Users to start LabVIEW with the following command line
“C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe” -pref “%HOMEPATH%\LabVIEW.ini”
Windows Explorer File Associations
When a LabVIEW file is double clicked, Windows exploer calls LabVIEW with the file as an argument. By default LabVIEW installation will not use per user configuration file when opened by double clicking a LabVIEW associated file. Therefore we need to modify the file associations so tha LabVIEW is called with the above mentioned user specific configuration file.
The command line associated with each LabVIEW file type is defined in Windows registry. These registry defined command lines need to be modified. We used Creative Elements Power Tools Registry Agent to search and replace the registry.
We searched entire Windows registry for the following line in the data field
“C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe” “%1″
We replaced the value of each found data field with the command line below
“C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe” -pref “%HOMEPATH%\LabVIEW.ini” “%1″
Further we searched again the entire registry with a second command line associated with LabVIEW templates files
“C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe” /n “%1″
and replace the found data fields with the following command line
“C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe” -pref “%HOMEPATH%\LabVIEW.ini” /n “%1″
After these two replacements, LabVIEW is properly configured to use user specific configuration file when LabVIEW is opened by Windows explorer when a LabVIEW file is double clicked.
Configuring Windows Environment
In a single user LabVIEW environment it’s normal to use LabVIEW with Administrator priviledges. However in a server environment this would be a security issue. So we added our LabVIEW users only to Users group within Windows user account and group management. Members of Users group don’t have write access to files located under Program files. Therefore all modifications to the LabVIEW installation such as installation of add-on libraries require loggin in as an Administrator.
Windows Terminal Services can be run in either Full Security mode or in Relaxed Security mode. The latter can be used to relax security settings of remote desktop connections if there are compatibility issues with Windows applications. We used the Full Security mode and have not found any compatibility issues with LabVIEW so far.
Even though the LabVIEW installation can be shared between the users, the source files under development cannot be shared. Eahc user needs to have their own set of source files. We use SVN repository to store our source code. We installed TortoiseSVN to the Windows 2003 server environment and checked out our source files for each user separately to a project folder under user’s My Documents.
Conclusions
Our experiment showed that LabVIEW can be used in a Windows 2003 server environment at least when LabVIEW specific hardware is not needed. Setting up the environment requires a some more work than setting up a LabVIEW on a single user computer. However, when set up properly, multiple developers can use the same LabVIEW installation to develop, debug and execute even the same project simultaneously. LabVIEW application instances seem to be very well separated from one another. Each application instance can use their own version of the same file without problem as long as the files are located in user specific folders.
I want to emphasize that all our results are preliminary. We have not yet done extensive testing of the server environment with LabVIEW. Furthermore if you plan to install LabVIEW on a server environment, you should verify your local National Instruments sales representative that your LabVIEW license allows such usage.
Print This Post
6 Comments
Make A CommentComments RSS Feed TrackBack URL
November 27th, 2007 at 9:18 pm
We just had our first problem after using the system for a while without problems. There were two simultaneous LabVIEW instances running file conversion from a proprietary format to HDF5 as suddely everithing got meshed up. There was something wrong with the available system resources. We were not able to read or write a single data file. The system could not even load administrator profile. Reboot solved the problem. We have no clue what was going on. Before I rebooted there was more than 3GB of free memory, more than 2TB of free data disk and more than 200GB of free system disk. I was thinking of memory fragmentation or something related to file handles. However we are still unaware what happened.
January 14th, 2008 at 6:59 pm
If you only wish to use Win2003Server to allow LabVIEW to take advantage of more CPUs or greater than 4GB of RAM, would you still need to make the modification to at way LV is launched? (assuming only one user on the Win2K machine).
What about communication protocols used by LV? (LOGOS, etc.) Would these be supported in the Win2003Server environment?
Finally, it has been my experience that building you LV app into an exe can greatly improve it’s performance. You should consider this even though you are always changing you app. Especially if performance is a consideration.
January 20th, 2008 at 11:51 pm
John, I haven’t tested LabVIEW communication protocols on the Windows server environment so I cannot say anything about them. However, as Windows 2003 server mainly relies on exactly the same protocol stacks as Windows XP, I would expect the communication protocols to work without trouble. On the other hand, I wouldn’t rely on all the NI hardware drivers to work without problems. Hardware drivers may need to work directly in kernel space and I guess kernel environment is not identical in the server and the workstation Windows environments. I don’t know if this helped you at all…
February 10th, 2008 at 11:46 am
We’ve been using Labview on Windows 2003 Server for the past 4-5 years with essentially no issues. At one point, the NI Motion drivers wouldn’t install, but that was for only one version. Otherwise, everything we’ve used installs and works the same as on XP. We use NI-DAQ, NI-IMAQ, NI-VISA, NI Motion.
We only run one instance of Labview–under administrator privilege just to keep things easy. NI doesn’t officially support this OS, so it’s difficult to resolve any problems with drivers. But we’ve never had any reason to suspect that the driver or other behavior was different from XP.
February 27th, 2008 at 5:05 pm
This is almost what I was looking for. However - since in our case we do not require LabView development, I was simply considering runing LV executables and the LV RunTime Environment. Does anybody have experience doing that on a Win20003 server?
Also - do you have any experince with using the LabView webserver in connection with IIS?
February 28th, 2008 at 10:48 pm
Ulrich, would you expect to run multiple instances of the same application simultaneously? Would the users running the application be with admin privileges, power users or with limited rights only? And what scenario do you exactly mean with using LV webserver in connection with IIS?