Issue converting Map to Array on sbRIO Target

[CAC10268]

I have been wanting make use of the new Maps datatype but I may have run into an apparent bug when running on a sbRIO 9637. 

I have a very basic Map with a String Key and a Double Value. When I try to convert my Map to an Array using a For Loop, the result is an incorrect value. When I inspect the flattened string, the bytes appear to be out of order and some missing.

This behavior does not exist when I use a Single instead of Double datatype.

I have also tested this on a 9033 cRIO and My Computer targets and they function as expected.

Can anyone else confirm this incorrect behavior on an sbRIO 9637 or any other target?

[altenbach]

The problem is that you are not converting it to an array, but to a scalar. Does it work better if you enable indexing at the output? Just curious.

(but yes, I agree there seems to be a bug because your code should work too)

Does the following workaround give the right value?

[CAC10268]

Your workaround is what I have already implemented as a temporary solution, I had disabled the indexing at the output of my for loop because I was just testing with one element. Turning indexing ON results in the same incorrect value.

[altenbach]

---

@CAC10268 wrote:

Turning indexing ON results in the same incorrect value.

---

Thanks. Good to know. I do have a sbRIO 9637, but I am working from home and it is in use, so I cannot test.

I assume that if the map contains multiple entries and you autoindex, all will be wrong, not just the first one(?)

I'll create an entry in the 2020 bug thread .

[CAC10268]

Correct, I was just trying to show the issue in its simplest form. Thanks for the help!

[ChrisStrykesAgain]

It also reproduces on a RaspberryPi 4; I'm guessing it's something unique to the arm architecture.

I'd be curious to see what happens if you try sending the result to the host via some other mechanism, such as a network published shared variable, network stream, etc. It's possible this is "just" a bug with how the interactive ui works and the target side code actually behaves as expected. (Neither of these are supported on a Pi, and I don't have any other arm targets handy,)

Edit: I just did a simple "equals" comparison (which should be valid in this case despite the fact it's a floating point), and the result comes back false. I think this is a legit case of incorrect code behavior.

[ChrisStrykesAgain]

One more observation... singles work fine but I64s are also wrong. I think it probably has to do with the fact it's a larger than 4 byte numeric datatype. 

Also, for some inexplicable reason, an array of doubles (even a single element) seems to work fine.

[cweeks12]

We've seen this conversation and have reported this as bug #1131063 here at NI. Thanks for helping us make our product better!