10-08-2018 10:14 PM
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!
Solved! Go to Solution.
10-08-2018 10:56 PM
@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 "
10-08-2018 11:47 PM - edited 10-09-2018 12:16 AM
I apologize for not giving the entire case. Attached are the snippets of the block diagram.
10-09-2018 12:12 AM - edited 10-09-2018 12:16 AM
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?
10-09-2018 12:17 AM
Thank you for correcting me. I've remove the jpeg files already.
Yes please, I would like some constructive feedback
10-09-2018 07:33 AM
@PJason1.) 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
10-10-2018 01:38 AM
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!!!
10-10-2018 04:38 AM
@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.
10-10-2018 05:59 PM
@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