Diagram Disable causes error in FPGA code

[Daklu]

I was working on some LV2012 FPGA code today for a cRIO 9074 and ran across an unusual situation.  Certain placement of the diagram disable structure causes the vi to break with an error staying, "Arrays must be fixed size in current target."  The snippet below shows some examples of different diagram disable positioning illustrating the issue.

I suspect there is a rational reason this is happening, I just don't know what it is.  Anyone have an explanation?

[crossrulz]

What do you have in the Disabled cases for the last two?  It disturbs me that the output wire of the structure is a float.

[Ben]

For the two examples that give the error, try wiring a fixed size array (like the build array with zeros wired) in the OTHER side of the structure.

Ben

[Daklu]

---

@crossrulz wrote:

What do you have in the Disabled cases for the last two?  It disturbs me that the output wire of the structure is a float.

---

Nothing.  It's just wired straight through.  One point of interest is if I enable the straight through case the error disappears.  The automatic float conversion is curious but I'm not sure it's related to the error.  It doesn't happen in my real code--only this example.

---

@Ben wrote:

For the two examples that give the error, try wiring a fixed size array (like the build array with zeros wired) in the OTHER side of the structure.

---

Good idea.  No change though.

I've attached a sample project with FPGA Main.vi implementing the example code.

[Ben]

I do not have 2012 to play with but am curious.

In both of the failing examples the source of the wire used for the "straight thru" disabled case is the Build array.

Wht about a "replace aray subset after the Build Array but before the diagram disable ? (to rule out the Build array as the source of the confusion).

Ben

[crossrulz]

It seems to be somehow the feedback node followed by anything from the numeric palette inside of the diagram disable.  Just for fun, I removed the FOR loop (left the increment) and it actually gave me a broken wire saying that the tunnel was of a different type.  Change the increment to any of the array functions and all is well.

[crossrulz]

For what it's worth, I'm getting this same bug with 2011 SP1.

I'm also noticing that if you remove the "Adapt to Source" of the numeric, the output type of the diagram disable will be whatever you specify.  So inside of the FOR loop, set the output type of the increment to the fixed point and it is happy.  So what is likely happening, the default data type of a numeric function is a double.  So the diagram disable thinks it should be of type double.  But this only happens if the numeric function is following a feedback node all inside of the diagram disable structure.  And having array functions between the two doesn't help.

I concider this a bug.

[Donovan_B]

This is a caveat of using fixed-point numbers.  If you look at the data type of the FXP number going into the increment function and the data type coming out, you'll notice they don't match.  The output wil have an extra bit.  This is to account for possible overflow of the fixed-point data type (see Fixed-Point Arithmetic here).  So, the data type at the output of the for loop (and really the increment) is different, meaning the data type of the output tunnel at the diagram disable structure is different than the data type in the wired through case.  Since LabVIEW does not know what all potential values could be as there could be multiple diagrams in the disable structure, it adapts to a data type that can represent all the values, in this case a double.

To prevent this, you can configure the output of the increment function by right-clicking and choosing the Properties item.  If you specify the encoding to match the data type at the input, LabVIEW knows exactly what data types are at each of the output tunnels and they match, so there is no coercion.

Edit: Actually, that wouldn't entirely explain the other behavior shown in your screenshots.  crossrulz posted before I got mine typed up.  I would tend to agree with what crossrulz posted.

[crossrulz]

This isn't limited to fixed point.  I changed the array constant to a U8 and I still get the same error.

[Ben]

---

@Donovan_B wrote:

This is a caveat of using fixed-point numbers. ... 

---

I'll buy that. Now for a Bonus Kudo...

Why is Daklu's forth example

OK ?

Ben