LabVIEW executable not runnable when using asynchronous call

[Bublina]

Hello,

my project works fine from source, but fails to launch as an executable. I was able to track it down to the async call of an VI.

So far I was able to solve the problem by using a dummy queue and loop to be able to start the VI parallel to the rest of the code.

I tried:

1. mass recompile

2. build source distribution, remove existing build, create new one

3. allways include all callback VIs and all VIs called by reference through server

Still no success. I tried to lurk the forum for answers, but only found suggestion I already fail-tried. Please help 🙂

[Bublina · Accepted solution]

So problem solved...

Now it runs.

But I cannot figure out why and what was the problem.

[tst]

As far as I can tell, the only difference is that is that now you made the top reference strict. I'm not sure why that should make a difference, as I'm pretty sure that I wrote apps that work just fine both if you have only a strict ref and if you have both a strict and non-strict ref to the same VI.

Maybe this has to do with the async call or with 2012 specifically. Can you create a simple app which shows this? Also, can you explain in more detail what you mean by "fails to launch"?

[Bublina]

Fails to launch = The runtime loads the front panel but displays a dialog box saying, the VI is broken, you need a full LabVIEw to fix this (or something like that)

I am 100% sure it is just this causing the problem.

It is funny, because I use this way of calling VIs in other projects without problems. Even in this project, the same way to call a VI, no problems with it.

The thing with this VI is, that unlike the others it is full of .NET and has many (~10) .NET callbacks registered. It is a window with map so it operates quite a lot of user interaction.

Even if whole diagram disabled, I still get a broken executable.

The dialog runtime throws

The code that is in the called VI (still broken executable)

 p.s. If you create a reference to .NET container, the reference says it is a ActiveXContainer 🙂

[Bublina]

I removed all front panel objects from the called VI (empty VI) still get broken executable.

Tried to build a new executable only with the call to that VI, it runs. I have no clue now...

[ChazMasterFlash]

I have had the same problem for some time. I am not using any .NET containers, so doubt that is the problem...

Any resolution on this?

[ChazMasterFlash]

After a bunch of screwing around I was able to solve my problem: It was related to how I created the reference controls within my asynchronous called VI.

I tried everything, as I see lots of users have on these compiler error posts.  I did the whole mass compile, the .NET framework upgrade, etc, etc...

My "conjecture" is that LabView does not handle references as rigourously as most computer languages. You need to be very careful when compiling these, esp if you have local variables of reference controls. I know that htis technically is not correct programming, but you need to close references and the easiest way is to use local variables to references.

Gawd I wish NI gave more direct use of pointers (which is essentially what a reference is). if I had access to address of the data, I think troubleshooting would be made much easier.

Am I alone here?

[GregFreeman]

---

@ChazMasterFlash wrote:

 ... but you need to close references and the easiest way is to use local variables to references.

---

I can't speak to the issues with .NET specifically, but I read the above quote and I had to step in and strongly disagree. I can't think of a single time I have used a local variable of a reference, when using .NET or otherwise. Why not just wire the referenes directly into the close reference VI? If a local variable is needed to "easily" close a reference, I have to assume there are other issues with the code. As for your issue related to the original thread, can you possibly post some code? 

[tst]

---

@ChazMasterFlash wrote:

My "conjecture" is that LabView does not handle references as rigourously as most computer languages.

---

I'm not entirely sure what you mean by that, but if I understand your sentiment, that's quite untrue. If anything, it's the opposite, as LV is quite strict in what it allows and how it handles things.

Also, regardless of the use (or lack of use) of locals to pass references around, writing code like that should not cause the issue described in this thread. At most, it should generate run-time errors. If you have something reproducible which causes this (particularly if you already found out how to handle it), I would suggest contacting NI support and giving them the code, so that they can find it and fix what needs fixing. Since your description was a vague "how I created the reference controls", I can't really say more than that.

---

ChazMasterFlash wrote:

Gawd I wish NI gave more direct use of pointers (which is essentially what a reference is). if I had access to address of the data, I think troubleshooting would be made much easier.

Am I alone here?

---

LV doesn't have pointers and probably never will, as that goes against the basic direction NI has gone with LV, which is to abstract and automatically handle all memory access. I don't think pointers would help you either, as they wouldn't mesh well with the way the rest of the language works. What you do have are various types of references, but references are NOT pointers. A pointers is simply an address of data in memory, without any additional data. A LV reference (which is different from a reference in C) is simply a "pointer" to a specific resource (control, VI, queue, event, etc.) which you can use with a specific API, and that's the key difference - any LV reference can only be used with a specific API, as opposed to a pointer, which is nothing more than an address.

The only real use case for pointers which I can think of in LV is to minimize data copies, but LV already tries to minimize data copies in different kinds of ways, including DVRs, which are not dissimilar to pointers (although they are NOT pointers). My guess would be that if you have difficulty with troubleshooting, then your code looks like C code written in LV, which can indeed be difficult to debug (and the locals comments also hints toward that direction).

[Praveen_a09]

The reference must be a strict typedef refering the Actual VI. Right click on the reference input object and 'select VI', point to the actual VI you are trying to open. LabVIEW creates a strict typedef with a connector pane belonging to the VI you have pointed to. That how it works in LV2011. Best of Luck.