Queued Message Handler: how to get a Subvi to continuously run while the queue goes on.

[MccGarthur]

Hello,

I am still somewhat new to Labview and currently writing a program that utilizes the Queued Message Handler for automation. When the user presses the "start test" button on the main VI, a message is sent that closes some relays. Once the relays are closed, a message is sent calling a subVI that, when called, opens its front panel and steadly increases the RPM of a DC motor until it reaches synchronous speed.

Once it's at synchronous speed, a true value is sent to the stop condition in subVI's loop and the front panel closes, and the next message is sent, which calls a second subVI.  In order for my program to function correctly, when this second subVI executes, the DC motor must still be running at synchronous speed.

The issue I am having is that once the first subVI finishes executing and a message is sent to the second subVI, the speed of the motor does not stay constant and starts to decrease.  I would like for the first subVI to continue running so the motor will stay at synchronous speed.  How can this be accomplished? Any help or input is greatly appreciated. 

[Stuart.Parkinson]

You could try the 'Start Asynchronous Call' vi from the Application Control palette. The help text gives details and links to a couple of examples.

However, you might also want to consider modifiying the architecture so that an async call is not necessary - for example an extra 'motor control' loop that you can send messages to (on another queue or via an FG) to spin up and control the motor and later spin it down. The code that does this can still be contained in a sub-vi to keep your diagram neat.

[Bob_Schor]

Sorry, I meant to push Quote, and pushed Post, by mistake.  Let's start over...

Suppose you had a message "Start Test" that started your test.  At the end of the code that starts the test, you send a Message "Increase Speed" that increases the speed one "notch".  At the end of Increase Speed, if the speed is not the desired Synchronous Speed, it sends an "Increase Speed" message and exits, otherwise it sends the "Do Next Test" message and exits.

Your single Message Handler will now Start Test, repeatedly loop through Increase Speed until the speed is correct, then Do Next Test.  Note that Do Next Test should, itself, send a Message to End Test (perhaps by turning off the motor).

Bob Schor

P.S. -- do you really have two "c"s in MccGarthur?  That's (in my experience) a unique spelling ...

[MccGarthur]

Thank you for your input! I will look over the 'Start Asynchronous Call' help and examples and see if I can use it in my program.  Do you have any reading suggestions for how I could modify my current program to include an extra 'motor control' loop using another queue? I am currently using the Queued Message Handler template that Labview provides and just modifying it to fit my needs.

[MccGarthur]

I seem to be unable to edit my last post, but I will upload my VIs when I get the chance so you can see my current logic.

[MccGarthur]

I have attached a Queued Message Handler that we have been using to test our logic before adding into the main program.  It starts off by sending a message to turn on the first relay when the "DC Motor Test" button is pushed.

 When the relay is turned on, it sends the next message to turn on the Control relay.

Once this relay is on, it sends the next message for RPM.

Here the front panel of the subVI will open up and the RPM of the DC motor will be increased.  

We are using the DAQ Assistant to count the edges from an optical encoder, then steadly increasing the RPM of the DC motor by applying an output voltage.  Once the RPM is within a certain range, it will stop the subVI then move onto the next message (in this case, turn off the relays).  The probem we encounter is that after the subVI closes, the motor starts to decrease since we are not applying a voltage anymore. For the purpose of our experiment, we need the RPM subVI to continue to run and for the motor to stay within the specified RPM, while still being able to continue on to the next subVI and the remainder of the program.

[RavensFan]

Well then.  Don't turn off the DC control.  In the same RPM event, you are running a subVI that shows the speed and also enqueing a message to turn off the DC control.  So when the subVI ends, that allows the case structure to end, and the turn off DC control case that has been enqueued to be dequeued and execute.

That seems to be pretty easy to see in your VI and not a mystery.

[MccGarthur]

Thanks for taking the time to post.  The "DC control" is simply a name we have given to the relay that connects or disconnects the DC motor to the system.  As our main program finishes executing, we must ensure that it is disconnected, as well as making sure the relay connecting the system to the power line is off. 

In our actual tests, we created a simple test subVI, called "Add", with two numeric controls that added whatever two numbers were entered and would send a true value to the loop stop condtion if the sum was above a certain number.  We placed this subVI inbetween the "RPM" event case and "turnoffDCcontrol" event case, just to test if the DC motor stay at synchronous speed.  

When the "RPM" subVI finished and the "Add" message was sent, we let the "Add" subVI run without inputting any values and used an optical tachometer to measure the RPM of the DC motor and noticed a steady decrease in speed. We would like for the DC motor to stay at synchonous speed even when "RPM" subVI is finished executing and the "Add" subVI is running.

[RavensFan]

Then don't turn off the DC system.  When the RPM subVI finishes running, then go to a state where the next set of speed codes to run.

Only turn off the DC system when you are really ready to.

Analog or digital outputs don't change just because a subVI stops running.  They change only when you tell them to change.

[MccGarthur]

---

@RavensFan wrote:

When the RPM subVI finishes running, then go to a state where the next set of speed codes to run.

---

Could you please elaborate on what you mean by this?  

During our tests, when the "Add" subVI was running and we measured the RPM of the motor, the DC relay was not turned off, but the motor was not running at synchronous speed.