build application based on queue message handler template

[David1980]

I programmed an application, using QMH template in LV and made a build out of it. The build has the "main.vi" and it is always included. But, after build is complete, the application starts by clicking on my apllication.exe and immediately terminate itself !!!! any idea about why? (I have one global function ("exit" which set to false at initialize state of the application" and shared variables, but both seem not the items to be blamed !!

[dkfire]

Unless you have some code or we are able to see your settings for the build spec, then it is impossible to say anything.

Your main vi should not be in "Alway Included", but in the "Startup VIs".

[David1980]

The "main vi" is in the start up but still the same behaviour after the build. I pretty much used the defaults when it comes to making builds, only added "deploy shared variable at start". What should be in the "always included", i tried with "nothing", "the sub vi" (which using qmh also), and "subvi + shared variable but stil no difference.

[Bob_Schor]

Asking "Why doesn't my program work?" without showing us your program is an impossible task, even for real Experts (we're mostly Talented Amateurs).  Your code is (probably) doing exactly what you are telling/asking it to do, which you can see but we cannot.  If you want help, give us something to examine.

BS

[PBP]

It's very hard to debug your words then your VI. 🙂 So upload your VI or screenshot of VI.

[Sam_Sharp]

Like the others have said it would help if you had some code to show us. The fact you're using a QMH is not the 'cause' of your application shutting down immediately.

At a complete stab in the dark I would say that in your built application you have an error that's occurring and causing it to shut down... checking things like if you have any static paths etc. will probably point to the issue (if you're using file IO or calling things dynamically).

[David1980]

@Bob_Schor, @PBP, and @Sam_Sharp, I have to admit that I was not so clear with explaning the probelm, part it is due to the fact about "discolsure, etc.". Thank you all for the comments, in the attachment you can see a snapshot of my "main.vi" after a bit of clean up ( "internal codes deleted ). The build from this "main.vi" still fails when the executable is double clicked.

[JarleEkanger]

What is the default case in the state machine/event structure? The running state does not appear to provide a "next state", and you are dequeueing so you will be executing the default state sooner or later (unless your subVI handles this issue).

[Bob_Schor]

I recently (about two years ago) started using the QMH fairly heavily, "re-inventing" my usage of it several times (that means taking a LabVIEW Real-Time project of several hundred VIs and almost "starting over").  I've attached a Demo Snippet to illustrate some Lessons Learned.

     First, an admission -- see all of those Queue wires?  I've gotten rid of most of them by using a Queue Action Engine that handles all of the Queue actions except Dequeue.  In place of the Obtain Queue, Enqueue, and Release Queue calls, I have a Message Queue VI that takes an Enum (Obtain, Enqueue, or Release) and (optional) inputs (such as the Element to Enqueue).  The only Queue wire in my diagram is the one from the call to Enqueue Initialize to the (necessary) Dequeue Element (but I don't need the Queue wire coming out of Dequeue Element as I use my VI instead of Release Queue).  Not only don't I need a Queue wire going into the parallel Event Handling loop, but I don't need a wire going into a sub-VI that needs to "send a Message", which makes spawning asynchronous parallel loops easy.

     You'll notice my Messages are Strings, not an Enum.  I'm a little conflicted here -- I like the "error-checking" feature of Enums, but especially when designing, it is so much easier to say "Hey, I need another State here to do this" and simply name it and add it.

     The Event Handling Loop, for the most part, should do nothing except generate a message, passing the Event New Value (if needed) as the Data part of the message.  In particular, the Exit message is just another Message -- it doesn't need to be "filtered out" for special handling.

     To stop all of the loops, I use a Local Shared Variable (you could use a Global or FGV/VIG as well) -- the TimeOut case in the Event Handling Loop wires this variable to the loop Stop, and as you can see, the Exit message sets it;

     You may notice the 500 msec timeout on the Dequeue -- this allows you to catch cases where no messages come in.  Here I "do nothing".  But you'll notice that this makes my Stop code work.  The User pushes Stop, generates an Event, calls the Stop Message, sets the Stop Shared Variable to True, but that (probably) does not stop the lower loop, as the earlier False value was probably read and "connected" to the Stop indicator when the loop was entered.  200 msec later, the Event Timeout fires, sees the Stop Shared Variable = True, and stops the Event loop.  After another 300 msec, the Dequeue times out, enters the True Case and does nothing, but now the Shared Variable is True and the lower loop stops.

     You are correct that if you want to do repetitive things with this model, you need to repeatedly call the State you want to run.  It depends how much of your code you want to put into a single QMH -- it might be just as simple to have yet another parallel loop do the same thing every 100 msec, and use the State Machine to handle the User Interface (I've done it both ways, depending on circumstances).

     Have fun!

BS

[Bob_Schor]

Oops -- ignore those VIs "hanging" off on the right -- they were part of the Huge Monster Program from which I exerpted the snippet.  

BS