LabVIEW Embedded

cancel
Showing results for 
Search instead for 
Did you mean: 

unflatten from string bug

Hi there (again),

 

I'm developing a new project where I need to communicate between two ARM's, both with LabVIEW for ARM.

We know the limitations of LV for ARM, since we've found many bugs (and reported it, with no response).

 

This time I've found a bug with the unflatten from string vi.

If you search for "(un)flatten string labview for ARM", you'll find an old NI post (LV 8.6) that it's not supported.

But flatten to string and unflatten from string are working in LabVIEW (for ARM) 2010.

The bug is in the unflatten from string vi.

When I've multiple messages that are flattened, concatenated in one string, the vi founds the first data, but flushes the other (rest) data.

normally you'll use the rest data to remember for the next iteration (in combination with reading the UART).

Also the error cluster is incorrect. error codes are wrong and the error cluster will give an "OK" when there's only one byte (not empty) string.

 

So in some way I have to split the flattened strings myself, so that the unflatten string vi can recreate the data.

The data I use to flatten are clusters. 

 

I don't expect any respons from NI with an solution since LV for ARM is not supported anymore.

my earlier corrective action requests (CAR number) from two years ago are still open, I guess.

 

Wouter.
"LabVIEW for ARM guru and bug destroyer"
0 Kudos
Message 1 of 8
(6,842 Views)

Hi Wouter,

Do you have the CAR-numbers or their specific topic for me so I can look them up for you?

 

Regarding the new bug you report, since I am not a ARM user I will contact my colleagues in Austin to see if hey want to do anything with this.

 

Thanks for posting, sorry for the late reply!

 

Best,

Jos

 

 

 

0 Kudos
Message 2 of 8
(6,732 Views)

Hi Jos,

 

CCodegen Crash: 361597

forums.ni.com/t5/LabVIEW-Embedded/CCodegen-Crash-LV-for-ARM/td-p/2019756

 

55 ms UDP read wait:

forums.ni.com/t5/LabVIEW/LV-for-ARM-UDP-read-55-ms-wait/m-p/1855637

I don't have received a CAR for this one but it's confirmed as a bug.

 

read lines from text file bug:

forums.ni.com/t5/LabVIEW/LabVIEW-for-ARM-2009-Read-from-text-file-bug/m-p/1306752

also no CAR.

 

Illegal C code generation, causes compile failure:

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

 

I couldn't find more for now.

Wouter.
"LabVIEW for ARM guru and bug destroyer"
0 Kudos
Message 3 of 8
(6,726 Views)

Hallo Wouter,

This is what I found:

 

- CCodegen crash: "Given that disabling Expression Folding fixed the issue, and that 2012 will be the EOL version of LV ARM, we won't fix this CAR (patch LV ARM)."

 

- 55 ms UDP read wait: "The 55ms delay is there to basically avoid pegging your CPU while waiting on data from UDP Read.  The wait is executed when we detect that the UDP Read is the only thing that currently needs to execute, which is always the case in serial mode and sometimes the case in parallel mode."

 

- read lines from text file bug: No CAR filed

 

- Illegal C code generation: I did not find a CAR here either. The only CAR that comes close:

"In LabVIEW, it is possible to wire an error cluster and boolean into a compound OR (such as using an error as one condition to stop a while loop). When performing this action on a touch panel VI, it will fail during build/compile. The build error log file reports: "error C2088: '|' : illegal for struct" This makes sense, as the illegal character is a bitwise OR operator, and we're trying to feed a cluster (struct) into a compound OR operator." The solution that is posted for this CAR: "In 2012 release we added support in the C Generator for wiring Error Clusters into Boolean inputs (of for example the OR primitive)." 

 

I'll let you know as soon as there is any response from the States.

 

Best,

Jos

 

 

 

 

 

 

 

0 Kudos
Message 4 of 8
(6,724 Views)

Hi Jos, 

 

I know that LV for ARM is EOL, even since 2010..

I've did many project with LV for ARM and so I know the best settings for using LV for ARM for our purposes. 

I always use expression folding, so "disabling expression folding" is not a fix. It's clearly generated by CCodeGen if some code is made in some way, I have attached code to reproduce the bug, and I've tested it with multiple settings so that someone can search the bug in the right direction.

 

For the 55 ms UDP wait, no one wants this one, it adds an unwanted and unnecessary delay. If a programmer wants to avoid pegging the CPU, he uses an wait vi. (I've changed this in my target folder of the LabVIEW installation dir)

 

read lines from text file bug: this one is reproducable, even with an example project that was given from someone of NI USA.

 

The illegal C code generation is reproducable (also in the topic). It places an global cluster definition (extern) after executing memset code (and uVision gives an error about it). I still get this annoying error with every build. (so I have to copy/paste the extern definition before the memset)

 

I hope that you can (re)trigger some people.

I once had a face to face talk with the person who knew anything of LV for ARM, which I shouldn't name here. 

I explained every bug and "want to haves" that I could find for LV for ARM, I prepared it for him because he came to our company.

Unfortunately I've never heard anything from him after that day.

 

 

Wouter.
"LabVIEW for ARM guru and bug destroyer"
0 Kudos
Message 5 of 8
(6,719 Views)

Hi Wouter,

I am not an ARM user either. When it comes to the bug you originally reported in this thread: you are right, due to EOL there will not be a bug fix. This is the info I got from the States, coming from two CARS. They are not directly referring to your issue but might give some ideas for a workaround:

 

1) If a String is within a Cluster and that Cluster is Flatten to XML on a ARM Target, then Unflatten from XML, the String is returned as Empty. Numeric and Boolean items within the Cluster are returned correctly.

 

Workaround: The string information was properly being flattened/unflattened to XML, but the string indicator was not updated during the JTAG debug session. This is due to JTAG debugging limitations WRT string indicators. The can be fixed by either changing to instrumented debugging or setting the indicator's default value to a string equal to or longer to the expected display string.

 

2)

Creating a VI for an ARM target that uses the Flatten to XML String or Unflatten from XML String VIs will give the following errors:

[11:58:27 AM] Status: Error
linking...
.\Obj\LabVIEW.axf: Error: L6218E: Undefined symbol FXPLoad32 (referred from ccgxmlsupport.o).
.\Obj\LabVIEW.axf: Error: L6218E: Undefined symbol FXPStore32 (referred from ccgxmlsupport.o).
Target not created

Status: Build failed.

The FXPLoad32 error comes from the Flatten to XML String VI. The FXPStore32 error comes from the Unflatten from XML String VI.

This was tested on both LM3S8962 and MCB2300 targets.

 

Workaround: Add code that uses fixed point math, such as adding two fixed point numbers together. This workaround can be seen in the True case of the Workaround case structure found in xmlflatten.vi attached below.

 

I will have a look at the old issues later.

 

Best,

Jos

 

 

0 Kudos
Message 6 of 8
(6,692 Views)

Hi Wouter,

I am sorry to tell you that we cannot provide you with more info, due to the support that has ended...

 

Best,

Jos

0 Kudos
Message 7 of 8
(6,519 Views)

Yeah I already mentioned that in my opening post, but thanks anyway.

 

"I don't expect any respons from NI with an solution since LV for ARM is not supported anymore.

my earlier corrective action requests (CAR number) from two years ago are still open, I guess."

 

It's still a shame that the ARM project was stopped after only 2 or 3 years. While NI was recommending for using it. 

In the mean time I've found multiple bugs (and made some workarounds). I've made a template for an other microcontroller to use LV for ARM.

 

We are still using it for some projects, since it's usefull for some applications.

If I find more bugs in the future, I will keep posting them on the forum.

 

Wouter.
"LabVIEW for ARM guru and bug destroyer"
0 Kudos
Message 8 of 8
(6,517 Views)