Precision loss for float in cluster

[ThomHell]

I'm having some issues with a program that I just can't comperehend.

I have some floating point single precision values coming in as hexadimal strings. These get rearranged and converted into single precision floats correctly in Labview. Everything looks nice. I then take an array of these and shove them into a cluster using BundleByName. This causes the values to be truncated(?) to zero. Somehow, the data changes when it gets added to the cluster. I can verify this with a probe right before and right after the insertion. Taking one of the float-values and setting it in a control, and trying to add that to the array in the cluster also leaves me with zero. I just don't understand how I can get this value to stay intact. I need to maintain the binary data 100% correctly. Of course, a different data format would be ideal, but that is not possible since it would involve to much architectural changes. I increased number of digits of precision in the strict type def of the cluster, but with no luck.

[rolfk]

We can't debug images! You even forgot to show the probe values in the screen shot, so it is utterly useless, although I would need to see other values too to even start to have a guess where things are going wrong.

That said, while I kind of can understand the Interleave Array at the left side, what you do in the loop to tear apart the individual string into two 2 char strings and then concatenate them back in exactly the same order makes no sense to me. My suspicion is actually that this could be simplified even more.

Attach the actual VIs (or at least the part you show in your picture) with some default data saved in the controls so we can play with that ourselves.

[altenbach]

No parts of you image shows any "precision loss". Things also happen in subVIs that we can't inspect.

Please define terms such as "truncated to zero". What kind if values do you expect instead (close to zero? Large?) How do you tell "precision"? Could it just be the formatting of your indicators?

Take the toplevel VI and do a "save for previous" (2020 or below), zip up the resulting folder and attach it here (it will contain all dependencies). Make sure that all controls have reasonable default values. Also include some typical "hexacedimal strings" (sic), e.g. as diagram constants.

[ThomHell]

Things ended up being a bit to hurried when I wrote the initial post, as I had to leave in a hurry.

For very unfortunate reasons, I am not able to share any code that would held clarify much. But the attached screenshot shows at least one problematic value (all values that are small enough seem to be an issue). As one can see, there is one value right before "BundleByName" and a different one right after, as shown by the probe values. I need the values to be exactly what they are before "BundleByName".

[ThomHell]

Unfortunately I'm quite limited in what I'm able to share, but I've attached another screenshot in a later post.

Yes, this is not particularly pretty, and I suspect that quite a lot of this could be done a lot simpler. Unfortunately, this is a case of "don't touch anything you don't need to, it is kinda working now". A rats nest of nasty things, made by a third party, who don't think we are a large enough of customer to prioritize us. Just the fact that floats are used to carry binary data is utterly horrendous, but nothing I can do anything about. (Custom network protocol between two different platforms, with no header in the message to define protocol version).

[JÞB]

I'll ask!  What is inside the (looks like To Zero) subvi?

Just guessing that,  that subvi might have something to do with your issue.

Hmmmm let's ask my 8-Ball....~~~~~Oh 8-Ball...

[BertMcMahan · Accepted solution]

Pretty sure it's your display format. One of your probes is set to "Floating point" and the other is "Automatic formatting" or "Scientific formatting". For example, the default Double control (what's shown for a Double array):

If you change that to "Floating point" you get:

Go to your typedef and change the display formatting for Data.InfoDataLowPri to "Automatic" or "Scientific" and you'll see the data again. Since you don't have any coercion dots, you're not losing any information.

(edit: just noticed you're using a Single not a Double, but the reasoning stands.)

[dsb@NI · Accepted solution]

Might it be that the default numeric indicator in the probe isn't wide enough to show you the number 1.92597E-32 as a standard float?

Since you were able to pinpoint the problem area in the code, create a subVI around that bundle by name, and spend your debugging efforts there. 

[ThomHell]

So I've found that the code in question here actually works. Although it is cumbersome and terrible, it is not wrong. I was fooled by the indicator formatting. Which means I have an issue in a completely different area of my code, but that is probably easier to pinpoint now that I know the data is correct. Thanks for all the suggestions.

[altenbach]

On a related note, measurement data (especially SGL) is typically not in a range of 1e-32 to 1e-37. This is really near the edge of the datatype. 

You don't describe how you are turning a hex string (ambiguous term that can mean many things!) into SGL, but could it be you are using the wrong byte order? (LabVIEW is always big endian, even on windows)