Labview 8.2.1 with Windows Server 2003 ?

Question

Hi Everyone,
(I use LabVIEW RT DSC 8.2.1 and I will be upgrading to LabVIEW 9 this summer)
I have a problem :
Description of the control architecture  :
I am working with around 25 NI controllers (5 PXI, 3 Crio and the rest are cFP&FP)
I have one server that is collecting (read & write by SV binding) most of the signals from those controllers into SV libraries.
The server is also responsible to some processes like (non linear scalings, watchdogs, restarting system....) - processes that concern all clients.
The Clients control the operational of the facility with applications that read & write from (or to) the Server SV libraries.
Problem :
The Sever is working very slow, and it turns out that originally the server is from a "PIZZA IBM" type and was coerced to work with XP (Service Pack 2, 32 bit) Windows OS.
The computers department told me that this Server "PIZZA IBM" is not suited to work with XP and they did some patching in order to make it work with XP.
I think that is the cause that the Server is working not properly, then I want to install Windows Server 2003, but NI told me that they do not support it.
(maybe this is the reason that originally we didn't install Windows Server 2003, since we use LabVIEW all over)
What should I do If I want a proper Server with Labview?
Is there anyone else in here that is using a server? so what OS is installed on it ?
How does other facilities sovle this problem?
Sincerely Yours,
Amitai Abramson.

Answer 1

Jeff,
Thanks for the extremely detailed post.  I have actually been experimenting with this combination of software for the past couple weeks (i.e. OpenSUSE 10.2, DAQmx, LabVIEW 8.2.1).  Your steps match mine very closely.  I did have a one thing to add, and one question about your steps.  First, I just want to mention that NI-KAL 1.6 has been released and it fixes several issues when installing NI-KAL with newer kernels.  This is available at:
http://joule.ni.com/nidu/cds/view/p/id/850/lang/en
I would highly recommend using NI-KAL 1.6.
Second,  I wanted to ask about step #2 where you modify the modpost.c file.  When I ran updateNIDrivers I was not required to make this change.  However I did have to increase the allowable symbol length.  I changed the line:
#define SZ 500
to
#define SZ 1024
in modpost.c.
I then proceeded to follow the steps you mentioned and was able to run updateNIDrivers without error.  Could you test to see if changing the allowable symbol length fixed the problem without having to ignore the "parse error in symbol dump file."  I don't exactly know what the read_dump function does but it always makes me nervous to ignore errors.  Since NI-KAL uses modpost to install a kernel module, this failure may be important, although I don't know for sure.
Once again thanks for your awesome post.
Regards,
Neil S.
Product Support Engineer
Multifunction Data Acquisition
National Instruments