NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Teststand python adapter type casting

Solved!
Go to solution

Hi all,

 

I'm migrating old .net framework code to python code which needs te be called from teststand. I noticed some differences in type casting between both teststand adapters (python and .net). For example with the .net adapter I was able to pass a teststand numeric constant (1000) to .net code which expects an uint32 without having to cast it specifically in teststand.

Now with the python adapter I need to cast the default teststand datatype (which is a 64-bit float) to an uint (1000ui64) to pass it as an integer to python. If I don't do this I get a float in python and the function errors.

 

In the past we never used any other numeric representation in teststand but the default one. The teststand documentation also recommends to use the default numeric representation for both int32 and uint32 values as they can represent all possible 32-bit integer values. It also states that teststand module adapters can automatically do the type conversion. 

( Link to Teststand docu source)

 

So is there a reason why this automatic conversion is not done for the python steps? Or am i missing something?

 

Thanks!

 

 

0 Kudos
Message 1 of 3
(237 Views)
Solution
Accepted by topic author Nick1991

There are several reasons for this behavior, but most of them boil down to one key factor: differences between programming languages.

 

Python is inherently flexible — it uses dynamic typing, so you don’t need to declare variable types explicitly. In contrast, .NET, while more forgiving than C or C++, still relies on strong typing and requires clear type definitions for variables and function parameters.

 

In our setup (TS2021 & Python 3.10), we follow a simple rule of thumb:
After every function declaration, explicitly typecast incoming values within the Python module. This is because TestStand passes numeric values as doubles by default, which can lead to type mismatches if not handled properly in Python.

0 Kudos
Message 2 of 3
(206 Views)

Hi luklem,

 

Thanks for the clear response. I think we need to follow youre rule of thumb too 🙂

 

0 Kudos
Message 3 of 3
(187 Views)