LV for ARM cluster array compile error

[w0utje]

Hi people,

regarding to a post that I've posted a long time ago (but not in the Embedded board).

http://forums.ni.com/t5/LabVIEW/LV-for-ARM-cluster-array-compile-error/m-p/2097708#M684034

I am putting the question/bug/workaround here.

I may have found a (little) bug in the C code generation of LabVIEW for ARM 2010.

I have a project in LabVIEW for ARM with a target and build specification.

My Application information is:

disable parallel execution

Use stack variables

generate C function calls

I have deselected Optimize heap size.

when I select use stack variables I get an error on my code:

declaration may not appear after executable statement in block.

when I view at the code I see the following:

MemSet( &c_Index_Array_element, sizeof(cl_A0000), 0 ); /* c: Index Array: element */
MemSet( &c_Index_Array_element_CT, sizeof(cl_A0000), 0 ); /* c: Index Array: element: CT */
extern Array Global_2_Array_3_2;

an global array I use is declared after the MemSet functions.

If I place the extern before the MemSet's. the code is OK

this LabVIEW code creates this error:

  paste this snippet in a vi.

the global array (Array 3) is the following:

   paste this snippet in a vi.

this is an array of a cluster with an U32 and an U8

these array's are creating the error also:

   paste this snippet in a vi.

+ use stack variables makes that any globals will be used as extern.

+ because of it's a cluster like these and there is an IF case after, makes that the MemSet is needed.

+ C code Gen places the MemSet before the extern

= Error

The problem is generated by an index array vi with an Global cluster array as array input.

I've tried the following and the bug introduced by CcodeGen is now gone.

I think It's because the array doesn't have to be initialized in the beginning of the Run funtion of the Vi.

My workaround:

Instead of the index array function, I'm using Array Subset vi, with a length of one.

because the output is an array, I'm indexing is it by a For loop.

Because it's an array of one element, you can assume that the for loop does one run, and so you can disable auto indexing if you are using outputs from this for loop.

Hope this can help others, It works for me.

I hope that someone of NI can reproduce it and can report it to his team.

It's not a big bug, but it's very annoying!

[w0utje]

Can anyone of NI confirm this bug?

[b1]

I have confirmed a similar error that is essentially the same thing and also other configurations.  It appears that anytime a cluster is wired to a dead end tunnel big problems arise, at least in Arm 2011 and 2012.  This happens with global clusters and un-initialized shift registers functional global clusters that go to a dead end tunnel in a case structure. 

Other errors I have found include NotRefnum not working for DVR refs, Global Clusters updating via in place elements having intermittent and un-predictable performance, Wire branching from loop iteration to indicator and going into in place bundle to update cluster simply not updating the indicator at all during debug, Global or FGV clusters going to comparison select instead of dead end tunnel still not working causing runtime error and crash of the embedded deployment, Global TCP Refnum inside of  while or timed loop not updating, No results for probing a TCP refnum during debug whether a break point is there are not, uninitialized TCP refnum shift registers not updating from from 1 loop iteration to the next (I think this another issue but I am still working on it),  Global Cluster to in place element does not update if the output wire is not wired but updates the original global input intermittently IF the output wire of the from the in place element output is wired to any tunnel (this almost acts like a FGV without a shift register but is intermittent in its operation to write back to the orginal Global cluster).

I have found many issues with LV ARM 2011 and 2012 that are very diffcult to track down.  I also have successfully deployed code from LV ARM 2009/2010 that will simply not work at all on 2011/2012.  Sorry that I don't have time post any code examples.  These problems have caused me serious delays and I am neck deep in trying to unscramble this whole issue and get my deployment off.  I just wanted to let you know that the original post is confirmed in more ways than original post.         

[b1]

One other VERY important issue I found.  DO NOT put a disable diagram structure into ARM and select Microlib.  I have File I/O in my app and I wanted to see the difference in code size if I used microlib which does not allow file I/O functionality so I just put a disable diagram structure around my File I/O and selected microlib then compiled and BOOM!  Labview didn't crash but the entire build got corrupted to the point where it was completely dead and I had to copy the code, without the disable diagram structure out of the VI into a new vi and delete the build and original VIs out of the project.  I am not sure whether it was microlib, disable diagram or both together but the build and VIs were totally and permanently corrupted and had to be completely removed from the project.