12-13-2016 07:22 AM
ok, I see.
so first loop: 500ms, and everything what is going to be logged will be queued here.
second loop: not timed.
Question: where are my events handled: when I want to communicate with my devices (say I wanna update my perssure set point on my injection pump)?
Flo
12-13-2016 07:44 AM
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):
12-13-2016 07:50 AM
Ok, It does make more and more sense. However there is a bit of thecnical issue I am struggling to resolve: I am playing with two VISA, How do I play with the ressources names/ error wires between the two first loops? (cf attached)
12-13-2016 08:21 AM
@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...
12-13-2016 08:24 AM
12-13-2016 08:47 AM
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.
12-13-2016 08:57 AM
@crossrulz wrote:
...
1. I have never found a good reason to use the Queue Status. Let the timeout of the Dequeue do the job for you.
...
A Kudo to you with an exception regarding "Queue Status".
I will use it when I have a loop that is accepting updaes from more than one queue. This could typically take the form of;
1) One queues provides commands that may take a lot of time.
2) Second queue is expected to contain more than one update that have piled up when doing the thing that "take a lot of time".
In a recent project I had commands coming into a VI that required reconfiguring HSDIO operation and when not changing the mode of operation, was responsilbe for keeping a 400MBytye/sec acquistion from filling up memory.
The number of elements in the queue waitin to be processed was used to set the number of iterations of a For loop that dequeued the waiting data.
So there are situation were a Queue Status are very helpful.
Ben
12-13-2016 10:08 AM
So, I've found this piece of code which doesn't belong to me, and I can't find where I;ve found it from. So if the owner sees it, and want me to remove it, no problem.
Does that snippet represent how I should orientate my work?
If yes,, should I work on a third loop ?
12-13-2016 11:01 AM
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.
12-13-2016 11:09 AM
Ok, but what do I use instead of the timeout event? I still need to send a command that says " hey there, if nothing is being clicked, please do get those information and display them", right ?