Double arrays in ext. code garbage when viewed in labview.

[olsonse]

For some reason I don't understand, I cannot seem to correctly set double values in a labview array.

The synopsis:
    I pass a labview array into some external code and then loop through array, setting values appropriately.

The test case just does

for i = 0, len
  element[i] = (double)i;
end

The problem:
    When the array is examined in labview, almost all the numbers are Xe-315, or so.
If instead of setting
   element[i] = (double)i;
I set
    element[i] = 0.0;
the array in labview is indeed an array of zeros.

Therefore, I expect that the problem could be one of either mixing mantissa/exponent sizes, or byte order mismatch.  The only problem with these guesses, is that a simple external function like
double runme(double * arg) {...}
deals correctly with the doubles and doesn't return garbage.

One further confusing point is that this test code works fine if the data type is a single precision float, or even an int32.

I am including a very simple test case with this post (~10 lines of c code and a VI to call it).
If the array sent in is empty, the test function silently returns.  To test, make sure input array is not empty. 
(I actually intend to use NumericArrayResize, but I need to fix this problem first.)

Environment:
   external code compiled with gcc-3.4.4
   LabVIEW 7.0
   windows xp, SP2

Message Edited by olsonse on 09-13-2005 09:51 PM

[altenbach]

Almost looks like your problem is with byte order, but it seems you already looked into that.

Windows programs are typically little endian, while LabVIEW is always big-endian. Reverse the bytes in each DBL and see if things improve ;).

Message Edited by altenbach on 09-13-2005 09:26 PM

[olsonse]

I tried the simple way of swapping the byte order:

typedef union {
    unsigned char bytes[8];
    double value;
} float64_t;

double swapFloat64(double input) {
    float64_t in;
    float64_t retval;
    in.value = input;
    retval.bytes[0] = in.bytes[7];
    retval.bytes[1] = in.bytes[6];
    retval.bytes[2] = in.bytes[5];
    retval.bytes[3] = in.bytes[4];
    retval.bytes[4] = in.bytes[3];
    retval.bytes[5] = in.bytes[2];
    retval.bytes[6] = in.bytes[1];
    retval.bytes[7] = in.bytes[0];
    return retval.value;
}

This didn't seem to help much, except that instead of Xe-315 numbers, I get 1..5e-305.

Also, by byte swapping value of 1.0 through 10.0, the new exponent is around -320 and not -315, so this can't simply be a byte swapping issue.

So, for a simple example like:
double func(double *) {...}
there is no problem with byte-order or the like.  Shouldn't labview automatically swap the order for an array of doubles too?

[chrisger]

hi there

you have to configure the arg1 parameter as a 1D double array (see attachment).

best regards

chris

[olsonse]

Yes, I can see how that would work, but I like to use NumericArrayResize to allow for my code to allocate memory in arrays without the need to keep track of deallocation. 

I've done this for some time on linux with no problems and even on windows things work just find as long as I'm not using (8byte) doubles.

So, the only problem comes because labview is not looking at the bytes the same way that I am in my code.  As I've already tried changing the byte order (see earlier reply), could this also be a problem of an offset?

The reason why I ask this is that I've noticed that while the returned values are always some type of garbage, the first element (index 0) seems to always show up as zero in labview, regardless of what I set it to in my code.  I've even tried to write to only specific bytes of the double so as to see this, but still this first element is always zero.

[chrisger]

hi there

please take a look to the attachment. the problem is not the c-code, its the LV - interpretation of the double array.

i don't see whats the problem with deallocation and NumericArrayResize. do you plan to do some memory managment inside the c-code? can you please give me some more information?

best regards

chris

[olsonse]

Could you possibly downgrade your VI to 7.0 please?

Thanks

[olsonse]

Yes, I often use NumericArrayResize in my c-code to avoid having to do memory management myself.  Rather, if I use NumericArrayResize to allocate the arrays that I return back to labview, labview will manage all of the memory deallocation for me.

[chrisger]

hi there

here it is...

well, i prefer to do allocatation and deallocatation of memory in the same environment (both inside the c-code or LV) because of possible memory leaks or access errors.

best regards

chris