VISA communication and subsequence execution in new thread

[MimiKLM]

Hi,

TS2010SP1 with LV2011. Sequential Model used.

I'm observing not expected situation which I cannot explain. Maybe someone from the forum know the answer or hint.

I call the subsequence with the option 'New Thread'. This subsequence consists with one LV step only which send teh autoalign command to the SpecAn. Usualy it takes up to 30 second to complete this operation, so to save some time it is good to trigger this in separate thread as I do.

In the thext step I do another communication session to some other stuff on different operation on the other device connected to the same GPIB bus. It looks more or less like that:

Somewhere else I have a Wait for the thread step to wait when the aligment is finish to proceed further tests. Nevertheless...

When I have the LV code which is aligning the SpecAn like that:

the new thread is started, and the execution is taken to the "Set Switch" step. That is an expected behavoiur. The "Set Switch" module is like that:

Execution gets strange if I do a handshaking in the LV code which aligns the SpecAn. When I replace the code presented on the first picture from the picture above with the code below:

the new thread "seems" to be not started as before as:

--the pointer of the execution is really moved to the step Set Switch

--but the execution stopped at the Set Switch step awaiting for the Align SpecAn step to finish.

So why is OK with constans delay, but is locked if I wait the SpecAn to finish aligment?

Many thanks in advance.

[Norbert_B]

Are you sure that your device supports "handshake alignment" in parallel to "other communication"?

Do you receive any errors (e.g. in the Align SpecAn)?

You dont call the same VIs in the two threads?

Norbert

[MimiKLM]

---

@Norbert_B wrote:

Are you sure that your device supports "handshake alignment" in parallel to "other communication"?

---

I don't understand.

---

@Norbert_B wrote:

Do you receive any errors (e.g. in the Align SpecAn)?

---

No errors.

---

@Norbert_B wrote:

You dont call the same VIs in the two threads?

---

I'm calling obly VIs from the VISA palette plus the delay as presented above

[Norbert_B]

Instead of sending a command and then waiting, you try immediatly to read data from the interface. This can lock up the bus interface or the instrument.

Either way, you can try to insert a wait before reading data back from your calibration command. Maybe this already solves the issue for you.

Norbert

[MimiKLM]

Frankly speaking I'm not interested in the output af the aligment (calibration) part of code. I do read just because the SpecAn blocks itself until it finish calibration. So having this read command I have the handshaking I'm after.

But why it prevents next step in different thread from being executed?

When I had wait instead read everything went smothly.

[MimiKLM]

Is it possible that the STAT:OPER:COND? caused all GPIB bus to lock?

If you see the execution cursor is set to execute Set Switch whils doing Aliging SpecAn operation.

The aligning SpecAn module is waiting for STAT:OPER:COND? to complete (stopped on read VISA block), but in the same time Set Switch VI is waiting on Open conection operation.

What is more surprising it waits longer than timeout value (10000) without throwing the error.

I still don't understand why it works with ordinary delay instead read command.

[MimiKLM]

Hi,

After speaking with my colleague, he suggested that I wait because I'm still waiting for the response from the the Spence, having the long time out at the same time as well.

For me this statement could be valid but in range of the connection (session) to the device but not in context of the whole bus.

In other words I do understand the explanation, but I still don't think so is it valid in this place.

Is it because the GPIB controller is in Listen mode?

Is it because whole GPIB controller is locked?

[Norbert_B]

First of all, most debugging tools force sequential execution within the application. So there is limited or no concurrent execution of threads anymore.

Putting a VI into highlight mode can lead to this behavior, so i am not surprised that this does not work concurrently.

On the other hand, your question is valid why waiting on one instrument seems to block communication with other instruments.

Did you use NI Spy to trace the communication on your GPIB controller?

Norbert

[MimiKLM]

After a while mayby I found out an explanation.

Is the behaviour I'm experiencing not caused by the fact that GPIB controler is in listen mode waiting for the device (talker) to finish the last command?

The talker - listener tandem is something what is valid for connection or is it something which is valid for the session (VISA session?)

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?

[MimiKLM]

---

@Norbert_B wrote:

First of all, most debugging tools force sequential execution within the application. So there is limited or no concurrent execution of threads anymore.

---

Yes I've seen this.

---

@Norbert_B wrote:

Putting a VI into highlight mode can lead to this behavior, so i am not surprised that this does not work concurrently.

---

I'm observing this in not highlight mode.

---

Norbert_B wrote:

Did you use NI Spy to trace the communication on your GPIB controller?

---

No, not yet at this ocassion.