08-20-2024 11:33 PM
Hi!
I am working on a project based off of the Queued Message Handler architecture of the Continuous Measurement and Logging (DAQx) sample project.
I made a boolean that triggers an event in the event handler loop.
I would like to start a "stopwatch" that counts upwards when this button is pressed, and this time value can be shared across the different queues. Pressing the button would start the stopwatch, pressing it again would stop it and reset it, then pressing it again would re-start it, etc...
I was able to make this work outside of my main program as a stand alone loop, but -
I'm having some trouble doing it in the QMH architecture, because when I run the case in the Message Handler Loop, it obviously only runs when triggered. How can I keep this stopwatch running and share the value across the different consumer loops?
I guess I could trigger the stopwatch to run asynchronously as a stand alone VI, but that doesn't seem to be the right way to do it.
Thanks as always for all the help.
08-21-2024 12:50 AM
Hi GOB,
@GOB34 wrote:
I was able to make this work outside of my main program as a stand alone loop, but -
I'm having some trouble doing it in the QMH architecture, because when I run the case in the Message Handler Loop, it obviously only runs when triggered. How can I keep this stopwatch running and share the value across the different consumer loops?
You missed to attach your project, including both the "working stand alone" and the "troubled QMH" code…
08-21-2024 08:08 AM
Hi Gerd,
Thanks for the reply - I didn't have access to my machine at the time of posting and I was hoping to get my thought process started.
I attached the Start Timer vi, and my thoughts on some ways to approach the construction of the main VI.
Method 1 - run VI method - when the "on condition" button is pressed it triggers an event, and the message handler loop starts the StartTimer.vi.
Method 2 - send current time method - when the "on condition" button is pressed it triggers an event, and the message handler loop gets the current time and sends that in a queue to another loop. Not totally sure what I would do with it there in that loop though.
Thanks so much.
08-21-2024 08:46 AM
Hi GOB,
@GOB34 wrote:
Method 1 - run VI method - when the "on condition" button is pressed it triggers an event, and the message handler loop starts the StartTimer.vi.
You don't want to call your Timer.vi as subVI when that VI blocks the caller because of its loop waiting for user input (aka stop button)!
@GOB34 wrote:
Method 2 - send current time method - when the "on condition" button is pressed it triggers an event, and the message handler loop gets the current time and sends that in a queue to another loop. Not totally sure what I would do with it there in that loop though.
That "another loop" can subtract timestamps to determine elapsed time.
Seems easier to me than calling your Timer.vi…
08-21-2024 12:41 PM
Thank you @GerdW-
do you think this has to be a loop of its own?
I was looking to integrate it into another loop (like the acquire loop) but it is tough because that has a case structure of its own so I’m struggling to make the stopwatch run continuously in that loop.
if I make a new loop then I have to create a whole new queue and also figure out how to integrate it with the existing data notifier.
really appreciate the help!
08-21-2024 05:49 PM
As I do this work, I realize there is something fundamental in my understanding of the architecture in the Continuous Measurement and logging (DAQmx) that I am missing. I would really appreciate help understanding something that I think will help with this challenge!
In the structure of the template code (QMH) - see attached images -- why does it seem to me that the aquisition loop is not constantly running and only executes when something gets sent to it in the queue?
For example, if I put a "Get current time" in that while in the acquisition loop - outside the case structure that gets messages in from the queue - and I wire an indicator to the get current time so I can see it locally on the front panel -- it only updates the time when I send a message to the acquisition loop in the queue.
I understand this is fundamental, so I am missing something, and really appreciate the help!
08-21-2024 06:30 PM - edited 08-21-2024 06:42 PM
I realize I can edit the dequeue message vi that was included in this template to access the timeout terminal on the "normal" dequeue element that is normally used.
EDIT: Hmm… but now I see the downside of that approach with the timeout because the loop keeps getting blank messages and throws an error. I guess I can put in a case for “ “ and take care of that - but seems clunky!