12-12-2012 07:30 PM - edited 12-12-2012 07:32 PM
Hi RavensFan,
Thanks for the reply... This makes sense... I will go back to queues.
The vi I am working on will likely have up to 5-6 parallel while loops... So that will mean a total of 4-5 queues just to send a STOP command to the consumder loops (one queue between the UE Loop and each consumer loop)? Is that correct? Surely there is a more efficient (less wiring) approach? Hence the idea to use a notifer; but I get the point re: CPU usuage.
Can I cluster the queues or something? Attached is a vi that I previous developed that works well... What I am doing now is trying to improve this VI by using a more standard design pattern, include a UE loop for commands, and reduce all the uncessary wires... Ignore the missing subvis; they only do basic calculations on the data obtained (e.g. max, mean, get data array subset from between graph cursors, etc).
Regards,
Jack
12-12-2012 07:32 PM - edited 12-12-2012 07:33 PM
Thanks BillMe!
That will be an easy fix.... Unfortunatley, I don't think my other problems as stated in my reply to RavensFan will be so easily rectified!
Regards,
Jack
12-12-2012 07:50 PM
I'm thinking that queuing a cluster that includes a variant might be the way to go?
12-12-2012 07:53 PM
Yes. You can definitely cluster the queue references together if that eases wiring. I would recommend using Bundle by Name so that you can more easily identify each of the queues from each other. One queue for each consumer loop is the right way to go. Think of a queue as a mail slot, you want each loop that will receive messages to have its own slot to receive messages no matter where they came from.
There is no need to bundle the error wires into the cluster. You can just wire the Obtain queues in sequence by the error wire then split them to the respective loops. I don't recommend using shift registers on error wires within loops. Suppose you have a random error in a loop such as a timeout error on the DAQ loop. That error will get passed into the shift register. Next iteration of the loop the VI's will get that error and not execute any code because most functions won't execute code on an incoming error, they'll just pass out default data and pass the error through. Then it goes back into the shift register to happen all over again on the next iteration. So one random error will effectively disable that loop from now until you end your VI. Of course just wiring the error to a normal tunnel means nothing will happen to that error unless the loop ends while an error is at the tunnel, in which case that gets passed out to code executing after the loop. So depending on the kinds of errors you might expect, you may need to add code to handle errors and do something else to correct the situation that caused an error.
12-12-2012 09:15 PM - edited 12-12-2012 09:25 PM
Sorry... but where do I find the queue reference? Can't locate it/them anywhere..?
Is this is the general design you suggest?
Thanks,
Jack
12-12-2012 09:25 PM - edited 12-12-2012 09:29 PM
I always just drop an obtain queue, right click the queue reference out and choose create control. If you need to change the data type of references, you can actually just drag the datatype into the reference. For example, right click the reference node that comes out from obtain queue, create control. This control will now be on your panel. Lets say you want your queue reference to be for a queue that holds your cluster of data, well just drop a cluster control on your front panel then drag that control on top of the reference. In the attached example, I am dragging a string control onto the queue reference which will change the type of the reference.
You can also hold control, click an existing reference on your block diagram (i.e. one of the references in the cluster) and drag. This will copy the reference constant. Then you can right click the constant, change to control, and drag a control of a proper type into the reference.
Furthermore, you can right click the queue reference and choose "show control" which shows the control that is "in" the reference.
12-12-2012 09:31 PM
Ahhhh!
I have been right clicking and searching for "Create reference" all over the place..
Many thanks...
Jack
12-12-2012 09:38 PM
with regards to your original post (and people have probalby touched on this, I haven't read all responses) what I generally do in this situation is use the error clusters to create data dependency upon shutdown. I do this by putting a merge errors outside the loops. You then wire 6 error clusters (one from each loop) into the merge errors node. Then after the merge errors, you release all your queues, wiring the error cluster through them. This way all queue releasing will not be done until all loops have completed. This ensures no queue references are released before all loops that may be using them are done.
12-12-2012 10:51 PM
@jcannon wrote:
Sorry... but where do I find the queue reference? Can't locate it/them anywhere..?
Is this is the general design you suggest?
Thanks,
Jack
The queue reference is the wire that is coming out of the Obtain Queue.
Yes. That design looks somewhat like what I had in mind. I wouldn't use the Flush Queue function. If you wound up with different amount of elements in each queue, your For Loop where you flush the queue will only run as many times as the # of elements in the shortest queue. The elements left over in the longer queue will be lost.
I still wouldn't use the notifier. Since you have a time queue and a data notifier that have the same number of elements, you should bundle them together into a cluster and make a single queue of that cluster. The problem with the notifier is it is essentially a queue of 1 element. So if your upper loop runs twice before your lowest loop gets a chance to check the queues, you'll get both elements out of the time queue, but only the last element out of the notifier.
I recommend looking over the help files and examples for queues and notifiers closer to get a better idea of the differences between them.
12-17-2012 09:19 PM
Hi everyone,
Attached is my latest version, which includes 5 (dummy) queued loops... I have tried to stop each loop on the queue error and swalled the 1 and 1122 errors..
Does this look ok? Or is there a better methods... This looks a bit messy to me?
Thanks for your comments.
Regards,
Jack