LabVIEW
producer -consumer code with several variables (types)
You could start your design based on the Producer/Consumer (Events) template. You can have a top GUI loop with an Event structure. Here you use a Queue for commands, like start/stop DAQ, change setpoints, etc. This Queue dequeued in the second While loop, which is the consumer of your GUI loop, but a producer of your DAQ part (this DAQ loop can managed in a way that is "self-Enqueue" a DAQ command during measurements). So use here a second Queue to send data to the 3rd loop (display and logging).
Have a look at this skeleton, a posible solution I often use (of course this is just for the idea, lots of things are missing/need to be changed):
@Flo-w wrote:
I am playing with two VISA, How do I play with the ressources names/ error wires between the two first loops?
Most situations I have ran into work best if you have each instrument in its own loop. What you are setting up here with the Events and the first consumer is what is commonly called a Queued Message Handler. So you dequeue the message type and do whatever is needed with the data there. Inside of that case structure is where the actual instrument commands are handled. So the first loop does not care about the VISA resource or what equipment is connected. It just sends a message to somebody who promises it can get the needed data and/or do the needed task. This results is low coupling (meaning A does not really matter about how B works) and allows for more reuse.
As far as the constant reading, I typically use the queue timeout (set to whatever loop rate I want) and in the empty string case is where the read is performed.
I really wish I had a ready example that I could share...
The concept is there, but the implementation is junk.
1. I have never found a good reason to use the Queue Status. Let the timeout of the Dequeue do the job for you.
2. You should never have a loop inside of a Queued Message Handler. You perform your 1 action and then loop around to the Dequeue. If you have another timeout, you read again. If you get another message, process it and loop back.
Flo-w wrote:
Does that snippet represent how I should orientate my work?
It is a lot closer. Two things I am seeing is 1) you should not be using the Timeout of the Event Structure and 2) you should be using the timeout on the dequeue.
Flo-w wrote:
If yes,, should I work on a third loop ?
Yes, the third loop will be somewhat similar to your current consumer loop. You will not need the timeout functionality in this one since you only log when you get data.
