LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Queue

Solved!
Go to solution

Hello everyone.

 

I'm developing Queue State Machine program and I have a lot of questions and I need some insights.

 

1.) Is it possible to queue a cluster of enum constants which distinguishes the state of the consumer and a tab control?

2.) Can we queue VISA functions? I'm using  VISA functions because I am acquiring data in the serial port.

3.) The DB functions should also be queued?

4.)Where should the VISA functions be initialized? in the producer loop? or consumer loop?

5.) Should  all event triggered action, may it be user interface/value signaling, be in the producer loop?

 

Thanks a lot!

0 Kudos
Message 1 of 9
(4,034 Views)

@PJason wrote:

Hello everyone.

 

I'm developing Queue State Machine program and I have a lot of questions and I need some insights.

 

1.) Is it possible to queue a cluster of enum constants which distinguishes the state of the consumer and a tab control?

2.) Can we queue VISA functions? I'm using  VISA functions because I am acquiring data in the serial port.

3.) The DB functions should also be queued?

4.)Where should the VISA functions be initialized? in the producer loop? or consumer loop?

5.) Should  all event triggered action, may it be user interface/value signaling, be in the producer loop?

 

Thanks a lot!


Let's see what you think you have... but, just for a bit of background.   Look at Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801.  You probably need to define/align what you are calling a Qmh 

 

Of course you can enquire any type if data but, you might not want to....

 

Specific use cases with demo code get more helpful answers... not everyone has a well calibrated magic 8-Ball  and mine says "outcome uncertain "

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 9
(4,021 Views)

I apologize for not giving the entire case. Attached are the snippets of the block diagram.

Message 3 of 9
(4,010 Views)

First    those are not "snippets"...somebody else can explain in detail but snippets actually contain the source code under the hood of a png file

 Jpg files ......just avoid posting them unless you want to share a picture...

 

Advice,  constructive criticism!

 

 

Sharing real code can be challenging for new p posters

  But, we do need..more information to help you out...

 

Would you like some constructive feedback? Or are "Things (tm)" we can help you understand?


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 9
(4,000 Views)

Thank you for correcting me. I've remove the jpeg files already.

 

Yes please, I would like some constructive feedback

Message 5 of 9
(3,994 Views)
Solution
Accepted by topic author PJason

@PJason

1.) Is it possible to queue a cluster of enum constants which distinguishes the state of the consumer and a tab control?

2.) Can we queue VISA functions? I'm using  VISA functions because I am acquiring data in the serial port.

3.) The DB functions should also be queued?

4.)Where should the VISA functions be initialized? in the producer loop? or consumer loop?

5.) Should  all event triggered action, may it be user interface/value signaling, be in the producer loop?

 

Thanks a lot!


1. Queues will hold elements of any single known datatype.  So yes, it *could* be a cluster full of enums and suchlike.  It's less likely it *should* be.

   One common practice with QSM's (and QMH's) is to define a "universal data carrier" type, often a typedef'ed cluster of string and variant.  The string is the "state" or "message" being sent while the variant is available to carry any payload.  Note: the receiver *MUST* know the end datatype of the variant payload for every state/message string it receives.

 

2. I use the QMH pattern a lot and it structurally looks a lot like a QSM.  There isn't really a hard boundary between the two, many apps have some behaviors in both camps. 

    My approach is that each VISA instrument gets its own independent QMH loop.  These loop processes are given 2 queue ref's, 1 for incoming messages ("init", "set param", "exit", etc.) and 1 to send info or data back to the main brain loop.

   The main brain loop might message the instrument loop to "init".  This is a high-level macro-like functionality.  It's then the responsibility of the instrument loop to do all the *particular* instrument-specific things that constitute initialization.

    With multiple subservient loops like this, each has its own unique queue for incoming messages but all write to the same "main brain" queue to deliver info back.   Note: subservient loops must NEVER dequeue from that main brain queue, it's for enqueuing ONLY.

 

3.  Probably.  Again, DB code would live in a separate loop so the main app doesn't get bogged down by any possible slowdown from DB interactions.

 

4. In the "consumer" loop as you've called it.  Just realize that many of these loops are "consumers" with respect to their own message queues, but they act as "producers" with respect to the main brain queue.

 

5. I typically have a special loop for the GUI and its events.  Some events only affect the GUI and are handled locally in the event loop.  Others affect the main program, so these get turned into a message that I pass to the "main brain" queue.   For example, a GUI "start" button might lead me to send a "Start Data Acquisition" message to the main brain loop, possibly along with a variant that holds configuration related to the Data Acq.   The main brain then takes this generic message and does the more detailed work needed to make data acq start up properly.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 6 of 9
(3,956 Views)

woah! I wasn't expecting that but I really appreciate the constructive criticism you've made. With that, I somewhat grasp the idea of implementing QSM and QMH in LabVIEW. 

 

Thank you so much for the insights!!!

0 Kudos
Message 7 of 9
(3,916 Views)

@PJason wrote:

woah! I wasn't expecting that but I really appreciate the constructive criticism you've made. With that, I somewhat grasp the idea of implementing QSM and QMH in LabVIEW. 

 

Thank you so much for the insights!!!


Then consider marking the post as solution. Keep the forum clean, and avoid getting endless reminders from the forum as a bonus.

Message 8 of 9
(3,908 Views)

@PJason wrote:

woah! I wasn't expecting that but I really appreciate the constructive criticism you've made. With that, I somewhat grasp the idea of implementing QSM and QMH in LabVIEW. 

 

Thank you so much for the insights!!!


Kevin must have had a few moments to compose that.   We all thank him for that post! Exceptional  Kevin...even for your historicly high post content value


"Should be" isn't "Is" -Jay
Message 9 of 9
(3,877 Views)