01-17-2009 07:34 AM
Hello,
I have a problem with an application, built with the Application Builder. I have read some threads about the problem I have, but I still don't know a solution.
When I run my front panel from LabVIEW, everything is good. So, now I created an application (and an installer) to be able to run it on other PCs as well. This application does not work. Everytime I start it on my PC, I get the error "VI is not executable. ...". I read in several forums solutions for this error, but I cannot fix it! I've changed my properties for the builder, but with no success. Perhaps, anybody has more ideas, what's the problem.
To get a better idea from my project, here a little description of it:
In the block diagram there is a while loop which is continuously runned. In this loop I only set some properties for the layout of the front panel, such as decorations which will be hidden/shown and changes of colours of indicators... For the rest, it waits for a click on the button "Start" in the front panel. After that, a DLL is called to communicate with a USB device. Some measurements are carried out and the DLL is closed. I hope, you can get a global idea from my block diagram...
I use LabVIEW 8.5, the DLL is a third-party DLL, which we wrote on our own. But I think the DLL works properly, if it is called from a C# application it works and it works, too, by calling it from LabVIEW when I am in development mode.
It's a project for university and I'm just a beginner in LabVIEW, so I don't have so much experiences in it, but I think i improved my knowlegde about LabVIEW very well in the last weeks!
So, i hope to get an answer soon (the deadline for the project is not soooo far away
)
If you need more information, please let it know...
I would be very grateful if there is someone with a working solution...
Kind regards from the Netherlands,
Sebastian
01-17-2009 02:02 PM
01-17-2009 03:37 PM
Hi Sebastian,
Mass compiling will sometimes take care of issues where something will run in development but not with the Run-Time Engine (e.g. the TestStand user interfaces):
Open your top level VI.
Also open any VIs that are called by VI Server (i.e. launched dynamically by invoke node).
While holding down the Ctrl key and Shift key together, press the Run arrow of your top level VI.
(This will not run the VI but will instead mass compile all VIs in memory.)
Press Ctrl-Shift-S to "Save All".
Try rebuilding your application.
Also check the way you are setting the path to your DLL. If you are building the path dynamically, remember that VIs inside the EXE are referenced like this: C:\foo.exe\foo.vi
You could also have problems in your build specification, but those are hard to diagnose without seeing your project.
-Jason
01-18-2009 06:19 AM
01-18-2009 06:34 AM
Hi LabBEAN,
first of all, thanks a lot for your solution!
What do you mean by VI Server? How can I see, which VI's are opened? I opened every VI which can be found in the hierarchy and I followed your instructions, that does not work.
How can I check the path of my DLL?`Sorry, I'm no professional in LabVIEW, I'm just learning it at the moment...
If you need to have a look at my project, I can send the whole project per mail to you...
Sebastian
01-19-2009 07:59 AM - edited 01-19-2009 08:00 AM
Can you zip and post the project here? (Reply to this, and click "Add Attachments"...).
-Jason
01-20-2009 08:06 AM
01-20-2009 08:35 AM - edited 01-20-2009 08:36 AM
Sebastian,
Your architecture makes it very difficult to debug this and other problems. Does the error message mention which VI is causing the problem? It is very important to wire your error clusters everywhere. In LabVIEW, when a node throws an error (Error.Status = T), future nodes do not execute. At the end, place an error cluster indicator that you can see on your front panel. When an error posts, you can right click the indicator (even in a compiled application) and select "Explain Error".
This is a start, but you really need to push this into a queued-state machine before this gets any more complicated. As it were, if anything in your loop hangs, your whole application hangs. See attached for a queued-message handler (not advisable for actual applications, but you get the point. You would want to have a type defined enum in lieu of strings, and shared data between states differently, etc.)
-Jason
01-21-2009 04:18 AM
If you want to have us take a look at your application, you can also contact your local NI Branch office. In that case, you can send the program by to them by email. This could be helpful.
Regards,
Peter S
01-21-2009 03:55 PM