instrument driver slows down when communicating with two lock ins

[Denis34]

Thanks for your reply but I do not quite understand.

I can try what you propose i.e. having a main vi that controls sequential write and read commands, but I thought that this control was anyway done by the GPIB controler, and that I do not have to worry about it. By the way in my application there are several other instruments controled this way, with independent vis running in parallel, and it works well. I do not see what is specific with the two vis in question?

Concerning labview programming (style) I am far from being an expert.

I found sequence frames convenient to organize the vi and also to avoid very large diagrams by using stacked sequence.

Which is the reason why sequence locals should never been used? Is it just because the program becomes more difficult to read, or is there any other fundamental reason?

[Albert.Geven]

Readability of a program is a major concern because it makes it easier to find bugs or maybe better, "unexpected results".

And using subvi's eliminates the need for sequence locals completely.

The problem with several mainvi's that do something on the bus is that you are completely depending on the order in which a user clicks on buttons.

If you have a structured main program that executes in a specific order you can guarantee what happens.

In your case: the program works but is only slower than when you executeit in the way I suggested. 

So yes it works and you only see this effect with slow machines, so the other instruments are probably a bit newer.

Programming style makes programs readable and maintainable and you can choose to do newer work and concentrate on real problems.

good luck

[Denis34]

You are perfectly right. I have tested the solution you suggested and it works quite fine at high speed.

I have now to clean my vis...

Thanks again for your help and relevant advices!