NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

TestStand 64bit version

Solved!
Go to solution

Hi

 

When will TestStand come in a 64Bit version?

 

Regards Bjarne

0 Kudos
Message 1 of 16
(5,438 Views)

Hi Bjarne,

 

Creating a 64-bit version of TestStand is something on our roadmap, but there is currently no set timeframe.  Due to increased customer requirements for 64-bit support, we are making this feature a priority.  I have a couple questions for you to clarify your needs for 64-bit support:

 

  1. What requirements of your application require use of 64-bit code? 
  2. What type of 64-bit code modules are you looking to call through TestStand?
  3. Is there a set timeframe where you will absolutely need a 64-bit version of TestStand?

In the meantime, it is possible to call 64-bit code modules from the current version of TestStand, but there are a number of considerations and caveats.  The following KnowledgeBase article discusses the implementation in detail:

 

KnowledgeBase  5TUCSLXU: Can TestStand Call 64-Bit Code Modules?

Al B.
Staff Software Engineer - TestStand
CTA/CLD
0 Kudos
Message 2 of 16
(5,430 Views)

It's because our IT department only support WIN7 64bit and in that case thougth that it would be best to run LV and TestStand 64bit too. Also because we hopefully are introducing TestStand in the near future and it would then be future safe. And maybe be rid of some of the caveats.

 

/Bjarne

 

0 Kudos
Message 3 of 16
(5,420 Views)
Solution
Accepted by topic author Briton

Hi Bjarne,

 

I want to clarify that the current 32-bit versions of TestStand and LabVIEW are both fully supported on the Windows 7 64-bit Operating system (I am actually currently using it), since the 64-bit operating system provides a layer to execute 32-bit applications.  The compatibility issue occurs in the case that you try to call 64-bit code modules within the 32-bit TestStand process, since "bitness" cannot be mixed within a single process.  Currently, calling 64-bit code modules can only be accomplished by running the 64-bit code modules in a separate process, as described in the article I referenced previously.

 

Hopefully this clarifies things for you!  Let me know if you have any other concerns about using TestStand on a 64-bit Operating system.

Al B.
Staff Software Engineer - TestStand
CTA/CLD
Message 4 of 16
(5,411 Views)

We have a situation where we have to use LabVIEW 64 bit to call a 64 bit driver on a 64 bit (Windows 7) operating system, 64 bit computer.  Will 32 bit Test Stand be capable of calling the 64 bit LabVIEW module?  We need to know this as we are unable to get the device to work using 32 bit drivers on a 64 bit operating system.

 

Actually I did find some knowledge base info after I posted this:

http://digital.ni.com/public.nsf/allkb/4AB63B9B0EFA23D28625761D0053B8B0

 

0 Kudos
Message 5 of 16
(5,183 Views)

Any new on this topic?

 

I've my development platform, along with the target one, that is 64 bits with Windows 7.

Application runs as a sequence over TestStand 2013, at the moment, and calls function developed in a DLL vrom CVI 2013.

From DLL I call functions from HW driver through DLL (.lib, .h files). I've managed the fact that they all exist in 32- & 64-bit version, so I'm able to compile project in Release/Debug for both 32 & 64 mode.

 

In 32 and in 64 bits, I've a function that creates a general fault at exit: it is a function where I call a set of ones from a driver. A soon as I place one fonction from driver in my function I've the error.

I tried to make an executable in CVI, calling the same CVI function that integrates Driver calls and it is OK...

 

As a result, I think it is related to jump back to Teststand that is work, not the driver.

 

How is it possible to make your application operate on such HW configuration?

 

Regards

0 Kudos
Message 6 of 16
(4,701 Views)

If you create a 32-bit CVI executeable, does it work or does it give the same error as TestStand? What is the error you are getting? Have you tried debugging your CVI dll as called from TestStand? You can launch the teststand sequence editor from CVI to debug it, or attach to the process for debugging from CVI.

 

-Doug

0 Kudos
Message 7 of 16
(4,687 Views)

If I create a 32-bit CVI executable calling individually fonctions from driver DLL, it is OK. Same in 64-bit.

 

If I create a function with tTestData & tTestError parameters to be "TestStand call like", placed in a my own DLL, called from a main function (for a CVI executable) it crashed in 32-bit & in 64-bit, if I call the function from TestStand, it crashes also.

 

Issue may be with definition of tTestData & tTestError?

0 Kudos
Message 8 of 16
(4,676 Views)

@R1M wrote:

If I create a 32-bit CVI executable calling individually fonctions from driver DLL, it is OK. Same in 64-bit.

 

If I create a function with tTestData & tTestError parameters to be "TestStand call like", placed in a my own DLL, called from a main function (for a CVI executable) it crashed in 32-bit & in 64-bit, if I call the function from TestStand, it crashes also.

 

Issue may be with definition of tTestData & tTestError?


Most likely there is an issue in your code modules with how tTestData and/or tTestError are accessed or used. Have you tried debugging your code module to see exactly where the crash is occurring?

 

Also, you don't have to use tTestData and tTestError at all. TestStand can call many different prototypes of functions. If you prefer a simpler set of parameters you should still be able to call it from TestStand. tTestData and tTestError are somewhat of a legacy feature from before TestStand supported flexible prototypes. Now that TestStand supports flexible prototypes (and has for many years) you can specify just about any standard C prototype for a function call.

 

-Doug

0 Kudos
Message 9 of 16
(4,665 Views)

I made debug and error appears when jumping from closing braket }, after the return instruction.

It is not in our C code...

 

Our application was operating with Testand3.1 and CVI 8.1. Before any change in the parameter communication, with impacts on all the function, I'd like to get application operate!

Optimization due to new version capabilities are good but main function is the most important to keep, from my point of view.

 

Regards

 

0 Kudos
Message 10 of 16
(4,654 Views)