Multiple viWrite and viRead

[Micho]

Hello, I have a processes that runs on a timer ... check the temperature of the equipment every two seconds.

I have another process that check the status of the equipment.

Can I not issue multiple viWrites and viReads like this?

NiSpy would show something like the following:

viWrite(get temp)

viRead(75)

viWrite(get status)

viRead(Ok)

viWrite(get temp)

viWrite(get status)

viRead(Ok)     <-- Opps, I was expecting a temperature here

viRead(Ok)

What is the best method to handle sending messages at "random" times and getting the proper reply?

[Dennis_Knutson]

I think you can do what you want with VISA locks. You would create a lock before your write and do an unlock after the read. I'm not familar enough with the C code programming though. I do all my programming with LabVIEW and I've done locking there for similar situations.

[Micho]

I took at look at viLock but not sure it that will work for me .... I'm using JNI, the java class creates a vi session and handles all the communication. I then pass that java object to the other methods that needs to make a gpib call.

So the lock is for the session, but the problem is that I only use one session ... I have multiple threads that access the same vi session so the lock would be worthless. I'm sure there has to be another way to do this.

[LaurenLL]

Hi,

If I am understanding it correctly, you are reading the temperature on a time cycle, and the status on a separate 'random' pattern.  It sounds like every once in a while you call the vi session at virtually the same time, thus overwriting the data. How often does this occur?  Is it completely necessary for the status measurements to run on a different cycle than the temperature measurements?

Also, what type of communication are you using and how are you handling the data?

The easiest solution would be to time the calls so that they are never simultaneous.  Of course, it sounds like you want the status calls to be random, so this may not be optimal.  Instead of locking the session itself, it may be possible to create a queue so that the vi session cannot be called while the other one is running.

Lauren L.

[Micho]

The read temperature is done every 2 seconds to update a field in a GUI. The status of the equipment is checked when ever it's detected that the equipment is idle. It occurs often enough to cause me a problem. I'm using a custom built DLL that icludes the viWrite/viRead functions (others as well) then its i called by from a Java applicationt thru JNI. This particular equipment uses a GPIB interface.

I have considered using a queue ...

static ready=1

if new message insert to queue

while (queue not empty)

{

     while(ready)

     {

            viWrite

             ready=0 // set flag to indicate waiting on reply

             viRead

              ready=1 // set flag to indicate ready to send next message

     }

}

this looks more of a hack though ... i'm looking for a more elegant solution.

Thanks.

[Steven_T]

Hello Micho,

You should probably create your own method of thread synchronization for this problem.  Since viLock only locks a device to a particular session, you should use a mutex to lock a session to only be used by one thread at a time.  Each thread should check the mutex before doing any type of session communication (reads or writes). 

Check if Mutex is available (wait if its not available) and
Acquire Mutex.

Perform VISA operations

Release Mutex.

Since you will be using a mutex, make sure that dead-lock will not occur in your application.

Steven T.

[Micho]

Mr T and to all,

Thank you for the suggestions ... I think I will use a mutex to controll these threads ... I have found many Java examples of a Mutex that are in the public domain (gotta love Java!).