LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VIT References and missing queue commands

Hi Guys,

 

Im kinda new to VI Server and VITs and all.

 

Im using LV 8.5.  Ive got a VIT GUI that i want to be able to call several times.  Each instance needs to communicate with a "host" and the host needs to be able to direct the data back to the appropriate client VIT.  Right now, im using the open vi reference and invoke fp node to create multiple instances.  Inside each instance, i have a "vi server reference" constant that im trying to use as a unique identifier for that particular instance. Inside each vit instance, I queue the vi server reference with the command for data and send it over to the host.  The host strips the vit reference out and bundles it back with the data response. 

 

This works fine with just one vit reference running, but if i creat 2 or more vit's, then sometimes either one of the vits will miss a response from the host.  wont even see it in the queue.  It works flawlessly with just one vit open, but is sporatic with 2.

 

Any ideas on why its doing this?

 

thanks

jeff

0 Kudos
Message 1 of 11
(4,517 Views)
How many queues are you using for communication from the host VI to the client VI?  You should make sure you create a queue for communciation to each of the client VI's.  If the client VI's are sharing a queue for communication to them, then the wrong client VI may be stripping an item off the queue that is intended for another.
0 Kudos
Message 2 of 11
(4,512 Views)

Well, the number of clients is arbitrary 

 

In probing the queue data on 2 vits, i see that sometimes both vit's get the queue data.  Is that a fluke? 

 

So queues are an "exclusive" means of transfer?  I was hoping that the host could send the response out to all clients and then let the client determine if it needs to process.  Will this not work?  Is it a fight between the clients to see which one gets the message?

 

thanks!

0 Kudos
Message 3 of 11
(4,510 Views)

Queues are a many to one type of relationship.  Whichever Dequeue functions executes first will be the one to strip if off the queue.  They would be basically fighting over the messages.  You have a couple options.

 

If a VI instance gets a message off the queue that doesn't belong to it, it will need to Enqueue that message back in.  Now if the order of messages in the queue is meaningful, your run the risk that the messages intended for the other VI instance get out of order.

 

The better method would be for each VI instance to obtain a queue reference dedicated to it when it first runs.  Then when it sends a message, it could pass the queue reference into the message going to the host.  Then the host will put any messages going back to the client in that dedicated queue reference.  Think of it as the client sending a self addressed stamped envelope to the host with any messages it sends to it.Smiley Wink

Message 4 of 11
(4,507 Views)

How can i get each client to get a dedicated queue reference?  Is that a primative/vi somewhere or are you talking about using the vi reference type casted into a string (or some way of creating a unique idea) and generating a queue right at vit instantiation and passing that name back to the host?

 

thanks!

0 Kudos
Message 5 of 11
(4,505 Views)

Obtain Queue.  Let each instance of the client VI execute that the first time it is called and store the reference in a shift register.

 

The main VI will also have an obtain queue.  It will pass this queue reference to the client VI when its called so that the client VI has a means to pass messages from the clients to the main.  This queue will be based on a cluster.  One element of the queue will be a queue reference of the same type as defined in first paragraph.

 

1.  Main VI obtains a queue for incoming messages intended for it.

2.  Main VI calls an instance of a client VI.  Passes the queue reference obtained in number 1 to it.

3.  Client VI runs and obtains a queue for messages it wants to receive.

4.  Client VI sends a message in queue #1,  passes whatever the message is as well as its queue reference as obtained in #3.

5.  Main VI dequeues the message, does what it needs to.  Enqueues a message in the queue based on the reference it unbundled from the message it got along with the result.

6.  Whenever the instance of the client VI ends, it will destroy the queue it obtained in #3.

Message Edited by Ravens Fan on 12-08-2008 11:53 PM
Message 6 of 11
(4,501 Views)

So in my case, the main VI has a named queue and so that will always be the same.  So for me, every instance of the client will just start up a queue and pass the unique reference to the known host queue.  sorta the same thing, i presume....  right?

 

thanks!!!!!

0 Kudos
Message 7 of 11
(4,496 Views)

This is a variation on what Ravens Fan was describing (with some small twists).

 

 

In this code I create the queues that will provide the data paths for commands and updates, pack them into a cluster (class data) and thenuse the "Ctrl.Val.Set" method on a control on the FP of the VIT. The VIT, when it starts gets the queues references from that control.

 

I hope this helps,

 

Ben

 

PS Ravens Fan, Remember, after Sunday we are back the same LV Team. Smiley Happy

Message Edited by Ben on 12-09-2008 08:24 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 11
(4,463 Views)

Ben wrote:

 

PS Ravens Fan, Remember, after Sunday we are back the same LV Team. Smiley Happy


Of course.  Until then watch out!Smiley MadSmiley Wink

 

I'll be going to the game Sunday.  You know, when the Ravens win, it will make the playoff race that much more interesting.  They'll be in a virtual tie that might come down to the 4th or 5th tiebreaker depending on how the last couple weeks go.

0 Kudos
Message 9 of 11
(4,457 Views)

Now there is some pretty code.

 

I was thinking of one other possibility and would link to your action engine nugget.  Let the main VI be responsible for obtaining the queue for communication to each instance.  (And also disposing of it)  It would store the queue references in an array in the action engine.  Then each instance of the client VI would just get the queue reference from the action engine when needed.  Likewise for the main VI.  All that would be needed would be for each client VI to know which index of the array stores its dedicated queue reference.

Message 10 of 11
(4,456 Views)