|NI TestStand 2014 Help|
|NI TestStand 2014 SP1 Help|
|TestStand 2016 Help|
|TestStand 2016 SP1 Help|
|TestStand 2017 Help|
The bitness of the user mode portion of any driver TestStand loads in-process must match the bitness of TestStand, regardless of which adapter you use to communicate with the driver. As a workaround, 64-bit TestStand can use in-process 32-bit drivers by invoking them indirectly with a remote sequence call.
Drivers you invoke out-of-process using the LabVIEW Adapter do not have to match the bitness of TestStand. TestStand can invoke LabVIEW code modules using an external (out-of-process) instance of the LabVIEW development system. In this case, the bitness of LabVIEW must match the bitness of the driver, but the bitness of LabVIEW does not have to match the bitness of TestStand. You can make cross-bitness calls using the LabVIEW Adapter only when you use the LabVIEW development system. Code modules that execute using the LabVIEW Run-Time Engine execute in-process and therefore must match the bitness of TestStand.
Similarly, the bitness of an out-of-process COM server you call using the ActiveX/COM Adapter does not have to match the bitness of TestStand.
The bitness of drivers you invoke using the LabWindows/CVI Adapter must match the bitness of TestStand even when run out-of-process using the LabWindows/CVI development environment.
If most or all of the in-process drivers a test system uses are available for only one architecture, National Instruments recommends using the bitness of TestStand that matches the drivers. If a 64-bit version of a driver you need will be available in a reasonable amount of time, consider using 64-bit TestStand and remote sequence calls as a temporary workaround to communicate with the 32-bit drivers until the 64-bit version of the driver becomes available.