Windows XP 64 bit

[pwaszkewitz]

Does anybody have experience running TestStand on 64-bit Windows XP?

I know, it is not officially supported and as far as I know, all 64-bit support goes in the direction of Windows Vista (which, frankly, does not interest anyone here. The mood seems to be: stick with XP until Windows 7 is around), but perhaps someone tried it anyway on 64-bit XP.

Regards

Peter

[deyyoung]

I would be curious to know if anyone has experience with this as well.  Specifically, can a test step (sequences, code modules, etc) built on a 32bit XP system run on 64bit XP with no modifications?

[drohacek]

From a theoretical perspective, everything at the TestStand level should work just fine if you develop it on a 32-bit OS and execute it on a 64-bit OS (XP, Vista, or 7). These 64-bit OSs support running 32-bit processes and your TestStand application, engine, and steps will all run in a 32-bit process space. However, we have not thoroughly tested TestStand on XP 64-bit, so we do not claim to support it.

At the lower levels (code modules), things get a little more complicated. If your code module calls into a driver (e.g., NI-DAQmx), then that driver must include 64-bit kernel-mode support, even if the process that is calling into the driver is a 32-bit process.

All currently supported NI drivers do provide 64-bit kernel-mode support for Windows Vista (64-bit), but not for Windows XP (64-bit). At some point in the future, we will also support Windows 7 (64-bit). 

So in a nutshell, whether your TestStand steps will work on 64-bit XP all depends on what your TestStand steps are doing. If they are calling into drivers, it is those drivers that must provide 64-bit-specific components in order to work.

David Rohacek

National Instruments

[deyyoung]

Thanks for the input!  We started to test this out, but figured why bother when we can just as easily install 32bit XP and not have worry about it.

[pwaszkewitz]

Well, we cannot avoid a 64-bit system, be it XP, VIsta or 7, for memory reasons (processing images in the GByte range). As far as I understood, TestStand cannot call 64-bit modules directly, so since we have to use a 64-bit library, we need some kind of intermediate, which can be either an ActiveX or a .NET assembly.

So I see the system setup as follows: TestStand controls a 64-bit process via its ActiveX- oder .NET-interface and that process carries out the actual 64-bit computations.

Regards

Peter

[drohacek]

We are currently trying to figure out exactly how to prioritize development of a 64-bit version of TestStand. This will take a lot of effort. 

It would be helpful to us to know if others in the community would use a 64-bit version of TestStand. Could anyone out there who would use a 64-bit version of TestStand please respond to this thread to let us know about it. It would be helpful also to know 1) what about your application requires a 64-bit process; 2) what languages/environments you use for your code modules (e.g., .NET, C++, CVI, LabVIEW).

David Rohacek

National Instruments

[Manooch_H]

We are also working on documenting how users can call 64-bit code modules from TestStand in the form of KnowledgeBase articles. There is a KnowledgeBase Article online that discusses calling LabVIEW 64-bit Code Modules from TestStand. A broader KnowledgeBase that discusses calling 64-bit DLLs is in the works. I'll be sure to post it to this thread when it is ready so that you all may provide your feedback.

[pwaszkewitz]

We would definitely use a 64-bit TestSTand for selected projects. Main reason is that we increasingly have the requirement to process large (line-scan camera) images in our systems, i.e., images in the area of 128 to 1024 MBytes. Add a few intermediate images for the computation and you exceed the memory capacity of 32-bit system rather quickly.

Our code modules are typically C++ and/or C#.

Regards

Peter

[david_jenkinson]

Yes I would like to see a 64-bit version of teststand.

We run some of our test cases for days at a time.  We run into memory issues.  We have experimented with "on-the-fly" reporting, but this option is undesirable because it purges results from the result cluster, which we need to maintain.  We need to maintain the results because we have the option at the end of our sequence to choose to log to database or not, depending on the results, or the type of test, in an effort to keep the database free of data that is not wanted or needed.

We have just recently got running a station running vista-64, running teststand/labview/vision (imaqdx), and all seems to run fine so far.  We have 6518 and 6521 daq cards, and basler firewire cameras, all drivers seem to work.   So now all we need is a 64-bit version of teststand to take full advantage.  I understand there is already a 64-bit labview.  Is there a version of 64-bit vision?

Thanks

David J.

[ICodeFreely]

We have been asking about a 64-bit TestStand for several years through our NI representative.  We are reaching the point where we will have to code our own simplistic 64-bit version just so we have some "sequencing" capability.  Large imaging is driving our need for 64-bit.  Does anyone know of any sequencing type products similar to TestStand available from other vendors?  The majority of our calls will be to our own custom .NET code.