Communicating between separate VI's

[pureindo]

Sorry, I'm a novice when it comes to LabVIEW, so bare with me.

I have one computer reading from a datalogger for two separate experiments. The datalogger receives information from each experiment on different channels. This data is then sent via GPIB-USB connection to the computer. I need two separate vi's running on that single computer so that the experiments can be accessed at different times. I am trying to figure out if it is possible to have a third VI running continuously to read from that USB port, while the other two vi's read/write to the third vi for the data with some sort of priority level setup.

-If this is possible, how do I read/write to separately running vi's?

-Also, how do I setup priority levels just in case the two vi's try to access the third vi at the same time?

Sorry if I was not clear enough with my explanation.

[didierj]

-If this is possible, how do I read/write to separately running vi's?

-Also, how do I setup priority levels just in case the two vi's try to access the third vi at the same time?

4227[/snapback]

As long as the separate vi's run in the same development env you can use queues/notifiers to communicate. use a separate queue for each separate vi (don't forget to give each queue a name, otherwise you end up with one single queue). Either just read from the GPIB and put the results on the according queue or wait that the separate vi asks for data, read from GPIB and send it.

You will have to set up the priority by coding accordingly.

Also have a look to the examples with serach-key "client-server", "queue",...

Didier

[JackHamilton]

If I read correctly, You want more than one program on the computer to access the same resource? i.e. the GPIB port?

If that is so, what you really need is a single VI that controls the GPIB port, It would work like a train conductor. Other programs would send data and read responses via queues to the program.

I've done this with RS-232 and had as many as 200 different VI's accessing the same serial port. I sat down and wrote that about 5 years ago - now I plop it on the diagram and voila! I have instant RS-232, I've likely saved myself 100's hours of programming time, by doing this once - and correctly.

This may seem overwhelming difficult, but if you deconstruct it mentally, it's quite simple:

Q1: What is the necessary data needed to send a data over GPIB?

A1: The 'GPIB Address', the data in string format, A flag that this/if command gets a response, the response timeout in msec.

Okay with those answers: It does not matter what data is actually being sent to where - the data types are the same and nearly any scenario can be covered.

So in our GPIB Communication State Machine: we would need the following functions/states

INIT, CONFIG,SEND, RECEIVE, SPOLL,QUIT

INIT = runs at startup, creates the GPIB message queue acquires the GPIB card resource

CONFIG = configures the GPIB device, termination, Dev number etc.

SEND = Sends data to the GPIB port

RECEIVE = performs a GPIB read

SPOLL = performs a manuall GPIB Serial Poll

QUIT = terminates the module

We have a incoming Queue message that is a cluster that contains the following controls:

0. GPIB Command: INIT, CONFIG,SEND, RECEIVE, SPOLL,QUIT

1. GPIB Address string

2. GPIB Message (Data or command)

3. 0/1 response returned by instrument

4. Response timeout wait in msec (ignored if 3=0)

5. GPIB Termination (device specific)

Now we have to add some more logic to this - so step mentally back....

The GPIB conductor - needs to know 'who' send the message so the response can be sent back. This can be done by adding a numeric value to the Queue message - you can assign each calling program a unique number. The conductor - will simply take the number and rebroadcast it with any response it receives. The receivers will know their own ID and process its own message.

There are some complexities, for instance some GPIB instruments require checking stats registers after a command is sent, that easily handled - if you employ the concept of 'Public and Private Data'. To our GPIB conductor - he does not care what the command is, checking an instrument status register still involves sending a command string and reading a response, so our conductor does not really have to change the way he works to handle this. So how do you handle sending a instrument command, than then requires a second status check? Answer: You send two consecutive messages to the conductor. Your code that's written to handle that specific GPIB device - should have the logic and smarts coded in it to deal with that specific device. Don't contanimate the GPIB conductor code to handle odd exceptions - it will make it too complex.

Also, you'll be able to use this code in other projects. One big advantage of code reuse - is you can perfect that code over time and have a very reliable library in your pocket.

Regards

Jack Hamilton

[pureindo]

didierj,

I guess I'm not understanding what you're saying. Let me try to be clear what I'm doing first.

I have three separate VI's running within the same environment. One VI will act like a server to retrieve information from a datalogger while the other two act like a client. The two clients will be telling the server when to retrieve data and to get back that information. So, I'm trying to figure out whether I can use notifiers to send data back and forth between the server and two clients. If so, then how do I wire the "obtain notifier" icon to the "wait on notification" icon to the "send notification" where the "wait on notification" and the "send notification" will be on separate VI's to pass information back and forth. If this can work, would you/anyone happen to have sample code that I can look at? If not, is there another way to pass information back and forth between separately running VI's within the same environment (same computer).

Sorry if I wasn't clear.

Thanks in advance

Matt

[pureindo]

Sorry, one more thing, if this can be done using queues, would you/anyone happen to have an example? I'm the type that has to look at a program to understand it. Thanks

Matt

[pureindo]

I have three separate VI's running within the same environment. One VI will act like a server to retrieve information from a datalogger while the other two act like a client. The two clients will be telling the server when to retrieve data and to get back that information. I am trying to figure out how to use queues to do this. Let me try to give an example:

Client 1 tells the Server to retrieve information from the datalogger (Channels 1-10) at the same time Client 2 tells the server to go retrieve information from the datalogger (Channels 11-20). The server takes about 10-20 seconds to retrieve data from channels 1-10, sends that back to Client 1 then looks at the queue and retrieves information from channels 11-20 for Client 2. I know notifiers have an icon "Wait on Notification from Multiple" which allows it to receive info from two separate "obtain notifiers" each with their own unique name (Client1/Client2). I can't find anything for Queues that allow me to receive info from two uniquely named "Obtain Queues" (Client1/Client2), so that the server can receive info for Client 1(Channels 1-10) and send that info back only to Client 1, then look in the queue and receive info for Client 2(Channels 11-20) and send that info back only to Client 2, so forth and so on. Any suggestions?

Sorry if I wasn't clear enough.

[todd]

How about using one queue to get requests from all clients to the server. Then in each client obtain a queue whose name is the client's name. Send the client's name as part of the request cluster. Have the server parse the client's name, obtain that queue, and send the data.

Edit: added image.

[Michael Aivaliotis]

Sorry, one more thing, if this can be done using queues, would you/anyone happen to have an example?  I'm the type that has to look at a program to understand it.  Thanks

Matt

4378[/snapback]

Ok, here it is is. I built a LV6.1 example that shows how to have a server that sends data to whomever requests it. This one shows 2 clients and is done with parallel loops for simplicity. Of course these can be put into Sub-VI's. The datatype used is string but you can use anything really. I know some people use variants.

Enjoy.

Download File:post-2-1112239412.vi

[Eric Griwicki]

Hello Everyone,

This is my first post, but this topic applies directly to the project that I am developing and I would like a second opinion on the method that I came up with. I had a very similar problem where I wanted to communicate between parallel running VI's and transfer data between them in a queue but more event driven. The solution I came up with used the event structure and user events that sort of act like queues. I know events are queued up and with a user event you can send data to another loop without polling. The only drawback is that you can't have priority queues because you can't insert an event at the beginning of the queue. To illustrate what I'm talking about I reworked the "queue_comm.vi" that Michael Aivaliotis posted (I hope that is OK). It works the same but if you turn execution highlighting on you'll see that the loops really are dormant until you generate an event with one of the buttons.

Eric

Download File:post-1576-1114810073.vi