09-04-2020 10:50 AM
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?
09-04-2020 12:00 PM
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?
09-04-2020 12:04 PM
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.
09-04-2020 12:15 PM - edited 09-04-2020 12:17 PM
@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 .
09-04-2020 12:19 PM
Correct, I was just trying to show the issue in its simplest form. Thanks for the help!
09-08-2020 12:42 PM - edited 09-08-2020 12:46 PM
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.
09-08-2020 01:04 PM
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.
09-10-2020 01:18 PM
We've seen this conversation and have reported this as bug #1131063 here at NI. Thanks for helping us make our product better!