LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Array does not resolve to a fixed size

Solved!
Go to solution

Hi,

 

I am not sure if this is the correct place, but during working with arrays on FPGA, I find the error message 'Array does not resolve to a fixed size' not really helpful.

 

I have a case structure with a really big array for the True case and I have a null-array for the False case. When I added some new elements, it is not that straightforward to count the elements of the new array. Eventually, I copied out the case structure and tested the size in a separate VI.

 

I guess the compiler knows the sizes, as it can determine if they are not the same, so I would suggest to display these values, as it would same development time.

 

Regards,

 

Zoltan

 

0 Kudos
Message 1 of 9
(4,326 Views)

Hi Zoltan,

 

you already can read you wired two arrays of different size to an output tunnel of your case structure. What else do you need?

 

When you want to post an improvement idea you should post into the "FPGA Idea exchange" board!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 9
(4,323 Views)

Arrays on FPGA need to be of fixed size. Arguably a "really big" array has a different size compared to an "empty array" (if that's what you mean by "null array"). This also means that you cannot "add" elements, i.e. increase the size of the array. You can only replace values of existing elements.

 

Why would you need to "count" elements? Maybe you should e.g. keep the current index in a shift register and if you want to zero the array, just multiply it with zero, keeping the size constant.

 

Can you show us some code and explain what this exercise is all about?

0 Kudos
Message 3 of 9
(4,294 Views)

When you want to post an improvement idea you should post into the "FPGA Idea exchange" board!

That was my original plan, but 'Idea Labels' beat me - one more suggestion: either have auto-suggestion  or drop down menu.

 

The actual problem is that, I have one case structure, in which I can count the number of elements of the array, but I may be wrong. And I need this number to be able to add an array in the another case, so they match.After my guess / count, I start a build and next thing is a build error, regarding the size difference. So the problem is that, I cannot see the size of the array in the FPGA, unless I make a special build, which cost time.

Hence, I rather replicated the same structure in the RT part (which is much quicker for testing), and I run only one case, which showed the size.

 

Recommendation: the build error should show the two sizes, so I do not have to waste too much time to find the number Labview expect.

 

Zoltan

0 Kudos
Message 4 of 9
(4,264 Views)
Solution
Accepted by topic author ZoltanMTS

Hi Zoltan,

 

Recommendation: the build error should show the two sizes, so I do not have to waste too much time to find the number Labview expect.

LabVIEW doesn't "expect" anything here! And it will surely not decide which array size to take…

 

It already shows you the place where the compile error occurs. And it's your task as developer to set the very same array size in both cases…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 5 of 9
(4,258 Views)

I would expect something like when the type definitions are not the same: I can see the conflict and can fix it easier. It is true, this is not crucial and there are various workaround it, but I though the compiler has the numbers, so simply displaying them would not be a big issue.

0 Kudos
Message 6 of 9
(4,254 Views)

Hi Zoltan,

 

I would expect something like when the type definitions are not the same: I can see the conflict and can fix it easier.

I would expect to get a coercion dot…

BUT: In a quick test I did not get a coercion dot. And I guess the reason is exactly this compile error: as the compiler cannot compile such code it also doesn't generate any visual warning (aka coercion dot).

 

BUT2: The error is shown BEFORE the long compile starts, right at the first step of the code generation. So you don't lose a lot of time…

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 7 of 9
(4,248 Views)

OK, fair enough.

 

Zoltan

 

0 Kudos
Message 8 of 9
(4,240 Views)
Solution
Accepted by topic author ZoltanMTS

Quick tip, use context help and place your cursor over the wires in question.  If the array has a defined length, it will show up in the context help.  This is invaluable when debugging exactly this kind of problem.

 

One caveat is when switching cases with your mouse over a wire (using the mouse wheel for example), make sure to move your mose and re-position on the new wire, otherwise often the context help doesn't update at all....

Message 9 of 9
(4,203 Views)