VISA communication and subsequence execution in new thread

[Norbert_B]

---

@MimiKLM wrote:

[..]

In one case (case with the artifical delay) I got it working because I'm not interested in the answer.

In the second case (case with query) I don't have it working because I'm still waiting for the answer.

Is it the significat difference?

---

Yes, that's what i am thinking.

Query waits for the answer and obviously, this blocks the instrument for access from another thread (which somehow doesn't really surprise me, but i cannot tell you wether the instrument is causing this or the GPIB controller).

Norbert

[MimiKLM]

---

@Norbert_B wrote:

---

@MimiKLM wrote:

[..]

In one case (case with the artifical delay) I got it working because I'm not interested in the answer.

In the second case (case with query) I don't have it working because I'm still waiting for the answer.

Is it the significat difference?

---

Yes, that's what i am thinking.

Query waits for the answer and obviously, this blocks the instrument for access from another thread (which somehow doesn't really surprise me, but i cannot tell you wether the instrument is causing this or the GPIB controller).

---

I 100% positive that it locks the instrument. No surprise here.

But why it locks the controller? At least it looks like it locks.

I'll try to do som testing later on today.

[MimiKLM]

OK,

I think I do know what is going on here.

Have a look on the screenshot from the NI-Trace

VI from the main thread (position 10) is waiting for the talk opportunity which is (looks like) locked by the command sent in the new thread (position 6, red back at position 8, and connection close at position 9)

Is it not?

Does it mean that the GPIB controller can have only one connection open at a specified time??? Or is is a limitation of the VISA drivers?

Would it be different if instead of using GPIB controller I'd use the TCP/IP interface?

[Norbert_B]

I haven't reviewed your attached trace.

Just from the look on the screenshot: You read from the SpecAn and 24 seconds later, you close the connection. Directly after closing this connection, you write to the switch.

What happens within these 24 seconds?

As there are no errors (the 0x3FFF0006 is a warning), i am not sure if your expectations regarding "multiple threads access GPIB concurrently" is really correct.

What happens, if you DO NOT close the connection to the SpecAn inbetween (so close it if the execution is stopping)?

I know that multiple sessions in VISA can be handled concurrently.... even a single session can read/write concurrently (at least for RS232). So i wouldn't expect VISA to be a bottleneck here. I don't know, if GPIB has some exceptional rules which can explain this. What GPIB interface are you using?

Norbert