11-02-2012 04:52 AM
Hello,
I am using an instrument driver for a lock in amplifier (SR72XXLV8). As long as I use it with only one lock in (model 7225 from signal recovery) it works perfectly well. But when I am using two instances of the driver to communicate with two (identical) lock ins (with two different GPIB addresses) the vi executions becomes much lower (data from the lock ins are read at a rate of about 1 per second).
I have tried tu put a wait time in the loop of the vi to allow processor time for other applications. I have also tried to change the priority (normal to high) for execution of these vis, but it does not change anything.
Do you have any idea how to solve this problem?
Thanks,
Denis34
11-03-2012 07:40 AM
11-05-2012 05:21 AM
By driver I mean the vi that communicates with the instrument. I am not sure if this answers your question?
11-05-2012 07:45 AM
11-05-2012 08:08 AM
Here is the VI. Sorry!
11-05-2012 08:12 AM
How are you using 2 instances of this driver? The VIs are not reentrant, so only 1 can run at a time.
11-05-2012 08:48 AM
No I have a copy of this VI with a different name, and the two VIs are executed with the two GPIB addresses of the instruments.
11-05-2012 09:11 AM
I would expect twice as long for two VIs as for one since obviously, you cannot communicate in parallel over GPIB.
11-05-2012 09:54 AM
Yes I agree, but communication is not twice as long, but much much longer...
11-05-2012 12:39 PM
this driver is not suited for the way you are using it.
in the driver data is stored for each instrument.
You should call them not via settings in a settingfile but as part of a main vi and then you can send a command to one instrument, send a command to the other instrument and then read the first and after that read the second one.
The example program you are using is a very bad example regarding labview programming style.
Never use sequence frames except when you are forced by vi's that don't have sequencing by wiring like the simple wait vi.
Especially never use sequence locals, they are never needed and should be forbidden.
But all these bad example problems are not the reason why it takes so long in your case. It is the misuse of an example program and having two of them concurrently trying to get on the same wire to send out commands and reading data.