LabVIEW Embedded/ARM with password = Crash to Desktop

[tonykcrane]

Hi,

I just installed the LabVIEW Embedded for ARM evaluation kit with the LM3S8962.

A basic project will compile and download perfectly.  (Amazing how well this works!)

However, as I'm primarily a SW dev, I am a firm believer in GOOP and other OO technologies.  I can create the class and call it in the main VI, but when I go to compile the project, the compiler asks me for the password to a deeply embedded VI (which I do not have) and, after failing to validate or canceling, LabVIEW will just disappear.

If I create and use a native LVOOP class, it'll compile and run, however pass-by-value is simply not an option.

Test Cases:

1) Naked Main VI: compiles, runs OK

2) Main VI calling protected VI: will not compile if VI remains locked ('cancel' button or invalid password entered) and will sometimes CTD

3) Main VI calling LVOOP class: comples, runs OK

4) Main VI calling GOOP class: CTD after OK/Cancel in password dialog

Versions:

Windows XP 32bit Professional SP3

LabVIEW 2009 9.0f1 Evaluation

Endevo GDS 3.51

This really looks like an issue with password-protected VIs.
Has anyone seen this sort of problem before?

Thanks,

Tony

P.S. Will try to attach to another post since the forums keeps giving me an error when posting with attachment...

[tonykcrane]

The attachment was a bit too large, so I trimmed out the intermediate build files..

P.S. Requires GOOP3 runtime from Endevo, a free download.

Message Edited by tonykcrane on 10-16-2009 06:59 PM

[Claire_Reid]

Please post a link for the GOOP3 runtime from Endevo download. I will run a test.

Thanks

[tonykcrane]

http://goop.endevo.net/GDS/GDS_v3.5.1_LV2009_installer.zip

[Claire_Reid]

Thanks. I will download this and give it a try.

[Claire_Reid]

Hi,

I am a bit confused. In the build you sent me the PW protected VI's password is just asdf....is this just an example and not actually the VI that is causing the problem?

[Claire_Reid]

Sorry about that, I just realized that the Calls Goop has the other PW protected VI. I will speak with R&D and let you know what they say.

[tonykcrane]

Thanks for your time and attention.

The reason I included both a Calls-GOOP and a Calls-Protected Build Spec. was to demonstrate how the behavior is not tied to GOOP, but to any old password protected VI.  (And the problem is probably exacerbated by increasing the number of VIs in the Build Spec, possibly demonstrated by the occasional ability to get a compiler error dialog from the Calls-Protected variant.)

Thanks again!

Tony

[Claire_Reid]

Hi Tony,

So the builder asking for the password for a password protected VI is infact expected behavior. The point of password protecting the VIs was so that the source would not be visible. Generating C code from them would amount to exposing the functionality of the VI. It looks like the VI that is causing the problem is a GOOP3 VI, which means we will not be able to override this.

Let me know if you have any questions.

Claire

[tonykcrane]

Claire,

I understand why the builder asks for the password.

I also understand that the LabVIEW Application Builder does not ask for the password, it instead compiles the VI into the Runtime bytecode whether password protected or not.

If this is indeed the case, then the LabVIEW Application Builder generated bytecode could then be used to "expose the functionality of the VI."

However, that's just not the case. 

If you've ever looked at the C code generated from a single VI, then you might understand that the C code is in no way understandable or recognizable as to what is really happening in the VI.

I guess if you personally worked on or made great contributions to the LabVIEW runtime engine you might possibly - with no small amount of time and effort - be able to gain some small understanding of what's going on in the generated C code.  However, for the average (or even advanced) C programmer, it's obfuscated to the point of incomprehensibility.

I've attached the C code generated from the Naked VI for reference.  It's 45Kb of structures, lookup tables, and functions that - while they do perform what the VI does - are in no way recognizable as a while loop, a couple shift registers, addition nodes, split/join number nodes, and VI calls.

While, on the surface, that answer seems plausible, I'm afraid it is indeed nonsensical.  Perhaps I could have a chat with the person making this decision?

Thanks for your time,

Tony