Using Replace Array Subset function with fixed point array

[ZoltanMTS]

Hi,

I am not sure if this is a known issue, so I thought I raise it.

I developed a small VI to fill up an array, starting at different location, depending on a condition.

I used the Replace Array Subset function to do it. Its Help does not say any restrictions (it supposed to work with any type of arrays).

Once I saw it works, I decided to relocate it from the RT part of a cRIO to the FPGA.

To fit it in the FPGA, I had to change data type / representation to fixed point values – and it stopped working,

Could anyone let me know if I do something wrongly or the Replace Array Subset function has restrictions? Thanks.

Regards,

Zoltan

[altenbach · Accepted solution]

Your two arrays have very different FXP type (notice the coercion dot?) Once you make the types the same, it seems to work just fine (at least on the PC. Haven't tried FPGA).

[ZoltanMTS]

Thanks, that was the problem. It works on PC, I will try it on FPGA and come back in a cuople of days.

I saw the red dot, but I read in the forum, in many cases that is fine and in some cases actually speed up execution.

When there is red dot, it would be useful to have a information tip, like Labview has when there is an error,

Thanks again,

Zoltan

[altenbach]

---

@ZoltanMTS wrote:

When there is red dot, it would be useful to have a information tip, like Labview has when there is an error,

---

Get the context help window (ctrl+h) and hover over/near the terminal. It will tell you what's wired and what's expected.

[Yamaeda]

---

@ZoltanMTS wrote:

Thanks, that was the problem. It works on PC, I will try it on FPGA and come back in a cuople of days.

I saw the red dot, but I read in the forum, in many cases that is fine and in some cases actually speed up execution.

When there is red dot, it would be useful to have a information tip, like Labview has when there is an error,

Thanks again,

Zoltan

---

In many cases it works fine, but not in all. The red dot is the information you need, it automatically casts to a more general form, in this case i assume all FXP's will use the highest Int-version.

/Y

[altenbach · Accepted solution]

Yes, it actually does a coercion and that's why the code is not broken. It is just that it coerces to a FXP type with a single byte, so the coerced value is always 0.5.

The main problem is twofold:

1. The scalar FXP diagram constant was set to "adapt to entered data:. (your problem)
2. You entered 0.5 and it adapted to a single-bit FXP type, which is, (according to the dialog!) either 0.5 and nothing else (min, max, delta are all 0.5!). (LabVIEW problem)

I don't know the algorithm LabVIEW uses to adapt a FXP type to the entered data, but the current behavior seems completely useless! IMHO, "adapt to entered data" should be disabled and grayed out if the type is FXP.

Note that the ranges shown are incorrect until we uncheck "adapt to entered data". The min is zero, not 0.5!

(More generally, if "adapt to entered data" is enabled, the min and max shows the value of the entered data instead of the correct ranges for the adapted FXP type.)

[ikaiser]

Hey altenbach,

Thank you for your precise answers on this thread!

I might be able to give some insight about the unintuitive single-bit FXP range values shown on LabVIEW's properties for a constant. As far as I understand (there might be another reason) this is due to a feature called "tight range propagation". The idea is that LabVIEW keeps track of the minimum and maximum values that a calculation can yield and sets the FXP range correspondingly. This is a bit "tigher" than the general adaption rules which consider just the number of bits an FXP in configured to use.

See the difference here:

In the top path LabVIEW "knows" the result has to be either 0.5, 1, or 1.5.

In the bottom path is postulates a result of -0.5, 0, 0.5, 1, or 1.5.

However, the Data Type tab is confusing when one supposes that the Range values on the right are just illustrating the Encoding values on the left. For constants, this is not true. I rather see this as a feature than a bug, because if it was the other way (Range shown derived from Encoding) someone would ask "Hey, it's a constant. How does LabVIEW show it could have a different value as well?"

[altenbach]

Yes, if you do operations on in FXP,  things typically work out.

The problem is that "replace array subset" in this case does not do any reasonable coercion or adaption based on what is wired to the lower input. The initialized array FXP type always wins and if it is too tight, the results are not as expected as in this case.