topic Re: Precision loss for float in cluster in LabVIEW

Precision loss for float in cluster

ThomHell — Fri, 14 Nov 2025 14:21:52 GMT

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.

Re: Precision loss for float in cluster

rolfk — Fri, 14 Nov 2025 14:41:42 GMT

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.

Re: Precision loss for float in cluster

altenbach — Fri, 14 Nov 2025 15:23:15 GMT

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.

Re: Precision loss for float in cluster

ThomHell — Fri, 14 Nov 2025 19:14:33 GMT

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".

Re: Precision loss for float in cluster

ThomHell — Fri, 14 Nov 2025 19:22:15 GMT

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).

Re: Precision loss for float in cluster

JÞB — Fri, 14 Nov 2025 19:39:52 GMT

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...

Re: Precision loss for float in cluster

BertMcMahan — Fri, 14 Nov 2025 19:48:11 GMT

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.)

Re: Precision loss for float in cluster

dsb@NI — Fri, 14 Nov 2025 19:57:05 GMT

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.

Re: Precision loss for float in cluster

ThomHell — Fri, 14 Nov 2025 20:13:36 GMT

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.

Re: Precision loss for float in cluster

altenbach — Fri, 14 Nov 2025 20:41:14 GMT

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)

Re: Precision loss for float in cluster

ThomHell — Mon, 17 Nov 2025 10:12:15 GMT

The data in question is not actually a measurement of sorts at all. It is two 16-bit integers stuffed into a 32 bit float, that is then unpacked again in labview into two 16-bit integers. So that the values look very suspicious is not that wierd.

I finally managed to find the root cause of my problem in a completely different part of the whole program. When converting the float to two integers, someone had decided to do a numeric conversion instead of a type cast. I was just led astray by the front panel resolution on the float-values, and ended up in the completely wrong place.

Re: Precision loss for float in cluster

altenbach — Mon, 17 Nov 2025 20:15:28 GMT

@ThomHell wrote:

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 guarantee that bundling will not touch the data. If you don't believe me, just unbundle it again and compare, e.g. as follows:

Depending on what kind of typedef the cluster is, you might have to use the controls editor