passing a structure from Teststand to CVI

[R1M]

Hello,

I've a few structures in Teststand 3.1 sequence I passed in parameters of functions to CVI 8.1.

Now I migrate to Teststand 2013 and CVI 2013 but face some issues.

One structure has been modified and now is OK.

A second one is bigger (about 10 containers, with subcontainers, 17kbytes) and I can't see my data in CVI at the right place with an error when going back to Teststand -17308

===

Expected Number {64-bit Floating Point}, found Number {Signed 64-bit Integer}.

NOTE: Numeric representations must match exactly.

Use the following to specify a numeric constant in an expression:
64-bit Floating Point: 1234
Signed 64-bit Integer: 1234i64
Unsigned 64-bit Integer: 1234ui64

Use the following expression functions to convert between representations:
Convert to 64-bit Floating Point: Float64()
Convert to signed 64-bit Integer: Int64()
Convert to unsigned 64-bit Integer: UInt64()

Use the following API functions to get or set values of the various representations:
(NOTE: You can use PropOption_CoerceFromNumber and PropOption_CoerceToNumber to coerce between representations.)
64-bit Floating Point: Get\SetValNumber or Get\SetValNumberByOffset
Signed 64-bit Integer: Get\SetValInteger64 or Get\SetValInteger64ByOffset
Unsigned 64-bit Integer: Get\SetValUnsignedInteger64 or Get\SetValUnsignedInteger64ByOffset. Error in parameter 4, 'Param_Product'.

===

How can I identify which member of the container creates this error?

I thought I can move out some sub-containers but as when moved a container looses some of its properties, it is very difficult.

Regards

[R1M]

In fact my question is how can I identify which member of the container generates the error when woming back fro CVI?

In addition, I see, in debug in CVI, that some values are transfered to C struct but some not...

[R1M]

problem seems to be related to passing structure with some 32 bits elements.

If I place all elements in Signed 64bits, there is less problems BUT 1) my functions are all calibrated for Signed 32-bits and 2) my struture is so big that CVI can't reach memory for its last items.

[dug9000]

I'm not sure I understand, but consider the following:

1) If your struct in C does not have 64-bit integers in it then you shouldn't be using 64-bit integer representations in your corresponding teststand data type. You should use the float64 representation for 32-bit integers.

2) If you do have 64-bit integers in your C struct then you do need the 64-bit integer representations.

Is there any more info in the error message you are getting? I'm surprised it's not telling you which parameter and field at least. It should be. Or perhaps the error is caused by something else other than the struct passing.

-Doug

[R1M]

I don't have 64 bit integer in my C code. As far I understood the definition of variable in teststand (but I was wrong), I had to switch to Signed 64 bits Integer and place property for C language to Signed 32-bit integer. This is not OK.

Now I've crashed the structure and make it up again from begining, not changing the default representation, just adapting the C passing mode.

See second message about an issue with an array that is shown as [1...empty] in watch window 😞

Working day finishes in France, I go home.

[dug9000]

---

@R1M wrote:

I don't have 64 bit integer in my C code. As far I understood the definition of variable in teststand (but I was wrong), I had to switch to Signed 64 bits Integer and place property for C language to Signed 32-bit integer. This is not OK.

Now I've crashed the structure and make it up again from begining, not changing the default representation, just adapting the C passing mode.

See second message about an issue with an array that is shown as [1...empty] in watch window 😞

Working day finishes in France, I go home.

---

Yes, teststand expects 32-bit integers to be stored in the default number representation of float64.

So the issue with the empty array is from an output parameter? If so, that was not clear in the other forum post. What does the function prototype look like? Are you passing in and/or out an array of structs? How are you specifying the location to store the array of structs in the module specification panel? An example sequence file showing what you are doing as well as example C code of what's happening in the dll would help us to better understand your use case.

-Doug

[R1M]

Sorry if I'm not precise in the description but I'm not a teststand specialist: I "just" have to port an existing and operating application from CVI8.1 / Teststand3.5 / WindowsXPe to CVI2013 / Teststand2013 / WES7, that is not so easy.

Prototype of C function is

====

FONCT_DLL LoadTestParam_Product_DLL
    (
    tTestData       *testData,          ///< infos sur les données du test
    tTestError      *testError,         ///< infos sur les erreurs du test
    I32             ProductNum,         ///< indice du produit
    tParam_Product  *Param_Product)     ///< structure contenant les paramètres du produit
====

Contents of the function is a list of affectations like this one

====

Param_Product->Not_Needed_Parts.Pyro_1 = 0x00;

(...)
====

In C, structures starts with

====

typedef struct
{
    I8                        Driver_seat[MAX_SIZE_BUF];          ///< condition dans code barre pour siège conducteur
    I8                        Passenger_seat[MAX_SIZE_BUF];       ///< condition dans code barre pour siège passager
    I8                        Left_seat [MAX_SIZE_BUF];           ///< condition dans code barre pour siège gauche
    I8                        Right_seat [MAX_SIZE_BUF];          ///< condition dans code barre pour siège droit
       tParamNot_Needed_Parts  Not_Needed_Parts;                   ///< paramètres de test surgammage
    tParamPyro_Test            Pyro_Test[4];                        ///< paramètres de test Airbag
    tParamEBuckle_Test      EBuckle_Test[2];                    ///< paramètres de test TNB
    tParamHeating_Test      Heating_Test[2];                    ///< paramètres de test Nappe Chauffante
    tParamSbr_Test             Sbr_Test[2];                        ///< paramètres de test SBR
(...)
====

and in Teststand, see attachment

For me it is the same. After each sub type is also checked manually but I've not identified yet the error.

The first elements of the structure are OK and at a location I look for there is probably a shift between alignement of data and what I have in teststand is not longer visible in C and reverse what I write in C is no longer visible back in Teststand. 😞

Thank you for your help

[dug9000]

Ideally the sequence from TestStand 3.5 should work in TestStand 2013 without any changes. Did the typedef not transfer over to 2013 in some way?

After fixing the issue with the number representations, what problem is happening now? The array dimensions? Try changing the bounds in the typedef to something else and then changing them back with the "Apply Bounds to All Loaded Instances of the Type" checkbox checked while your sequence files are all loaded. Does that fix the bounds in your files?

Hope this helps,

-Doug

[R1M]

This morning, I reopened the application and found that most of my arrays wehre [1...empty].

Checking the size of the array, "empty" box is seleect for them: I've never selected it.

For me there is a bug somewhere in parsing the file, confusing the empty box and other data (such as array bounds?)

[dug9000]

If you can explain how to reproduce the problem or give us a file which reproduces it, I'd be happy to look into it. Also, take a look at 4) below since that does somewhat fit the symptoms of what you are reporting.

Some ideas to check:

1) Do you have multiple versions of the custom data type and are perhaps getting a different one based on which files you are opening?

2) Do you have code in your sequences that is setting the number of elements in the array or the array bounds? If so, perhaps such code is not setting the size to what you are expecting?

3) Are you using any flags on the properties in your custom data types, such as Shared, Unstructured, etc.

4) Did you use the "Apply to all loaded instances" checkbox at any point while modifying your custom data type? There was a known issue related to that checkbox used along with arrays of objects that was fixed in the 2013 f1 patch.

-Doug