Problem "Daemon Launching" a VI with a Timed Loop in a compiled .EXE

[Timmar]

I have written an application that uses a Daemon to software poll Digital Inputs (uncorrelated).

The software runs fine in the development environment but gives an "Invoke Node" Error when compiled to a .exe.

The error goes away when I put the timed loop in a conditional disable case box. My .exe runs with no problems (apart from the missing Acquisition Functionality)

 I have 4 other Daemons (AI, DI, AO,DO) that launch OK and for all intents and purposes have the same connection functionality. They even share the launch VI.

Does anyone know what might be causing this?

Daemon LAunches OK without the Timed loop.....

[andre.buurman@carya]

Could you post a screenshot of the error dialog?

[Timmar]

Here are some screen captures.

I am trying to figure out how to get the detailed Error dialogue

[Timmar]

And the workaround

[andre.buurman@carya]

Your problem is in the NI-DAQ VI in the timed loop. It seems that the NI-DAQ VI can't handle being in the timed loop.

Is it possible to have look at the code of the first mentioned VI in the error message. It might be password protected by NI. That VI is using an invoke node that seems to have a problem when used in a timed loop.

Isn't it possible to use DAQmx with your device?

Message Edited by andre.buurman@carya on 12-02-2008 07:13 AM

[Timmar]

WOW! such confidence with the cause of the problem.

Unfortunately it doesn't explain why it does work in the development envioronment and not in the compiled .exe.

The contents of the VI is a series of DAQmx calls (see attachment) , so yes, it is already using DAQ mx.

The subvi is a high priority clone sharing re-entrant VI, the same as the calling VI.

To me it smells like a LV Bug. A work collegue of mine has already identified a memory leak in it (8.5.1 only), it wouldn't surprise me if this is another bug.

I am going to have to blacklist timed loop functionality until I can get a decent resolution.

[andre.buurman@carya]

I have posted this as a potential bug to the breakpoint forum bug list

It seems something is missing in executable that is present in development.

Is the path to the VI that you try to invoke correct?

Is the dynamically called VI part of the build specification? Either added as dynamic VI or statically linked (either in a case structure that is never executed or static VI reference)?

Is the error already occurring at the Open VI reference or at a later stage, add error dialogs on the error clusters between the different invoke nodes and open VI reference to see where it happens first.

Message Edited by andre.buurman@carya on 12-02-2008 08:01 AM

[Timmar]

---

andre.buurman@carya wrote:

I have posted this as a potential bug to the breakpoint forum bug list

It seems something is missing in executable that is present in development.

Is the path to the VI that you try to invoke correct?

Is the dynamically called VI part of the build specification? Either added as dynamic VI or statically linked (either in a case structure that is never executed or static VI reference)?

Is the error already occurring at the Open VI reference or at a later stage, add error dialogs on the error clusters between the different invoke nodes and open VI reference to see where it happens first.

Message Edited by andre.buurman@carya on 12-02-2008 08:01 AM

---

Yeh, all is well.

As per my attachments, if I replace the timed loop with a while loop it functions correctly (some timing degredation). It compiles and Runs O.K.

I have a workaround now and given the time to compile an .exe and the fact that it is late (6:13p here) I am unmotivated to do this sort of investigation right now.

I may look into it later.

[Adam_H]

Hi Timmar,

I know you have a workaround but if you post a simple example that shows the problem I can take a look at it.  If I can verify that it is an issue in LabVIEW then I can take the proper actions to try and have it corrected.