Type casting in TestStand 2012

[dotNet_to_LabW]

Hello,

I really do not understand why my TestStand 4.2.1 sequences are not working in 2012. Here is a simple example.

SequenceCall: GetTime

Sequence: GetTime

Everything worked perfect till I installed new Version of TesStand.

Now in GetTime Sequence writing aTestDuration gives error because it says aTestDuration is not of type UInt64, so I used Typecase i.e.

in TestStand2012 I use:

But no use because result is always 0.

I have already tried formatting aTestDuration as %ui64 etc. etc. Nothing helps.

After giving up, I tried using object with Number as attribute. It works but:

- How will I convert this object to UInt64?

- Secondly, I do not want to use object because then I have to change 1000s of sequence calls in my source code and then let the program run which is weeks long unnecessary task for me.

I am sure that am missing something. I hope you people can help.

Regards

Ricky

[Al.B]

To clarify your statement "I have already tried formatting aTestDuration as %ui64 etc. etc. Nothing helps.": did you set the representation of the parameter to uint64 in the context menu?

Once you do this, you should be able to pass the parameter without the need for the UInt64() typecast function.  

If this doesn't fix the issue, would it be possible for you to send the simple assembly you are using?

[dug9000]

 I'm not entirely clear about what you are trying to do, but I recommend one of the following (if these options aren't good for your use case, please explain why):

1) Change the representation of aTestDuration to UInt64

or

2) Change the prototype of your .NET method to UInt32

-Doug

[dotNet_to_LabW]

Thanks for replying AI.B.It worked!!

Dug, yes I can choose any of the above 2 suggestions you made. But earlier (in 4.2.1) I never needed to tell TestStand explicitly that I was accessing a UInt64 in my library. I chose a variable (Number) of default type and it worked.

Ciao

Tony

[dug9000]

The .NET adapter in TestStand 4.2.1 was storing the UInt64 in a double precision floating point number. This was somewhat of a bug in that numbers at the higher end of the values a UInt64 stores cannot be accurrately represented in a double precision floating point number. Thus, in order to avoid unintended loss of precision with 64-bit integer values, we now no longer allow you to directly store a 64-bit integer in a double precision floating point number. Perhaps in your use case you will never use the higher values of the 64-bit integer, but if you had, you would have run into problems when storing such values in a double precision floating point number.

(NOTE: The .NET adapter was the only adapter in 4.2.1 doing this, no other adapters supported 64-bit integers at all until we added the 64-bit integer types in TestStand 2010)

Hope this helps explain things. Let me know if this explanation is unclear or if you have additional questions related to this.

-Doug