LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Why do I get a timeout from viReadSTB() after calling viWriteAsync() with VI_EVENT_IO_COMPLETION event enabled as queue and serial communication?

Hello!
 
Every time I am calling viReadSTB() after calling viWriteAsync() followed by viWaitOnEvent() (VI_EVENT_IO_COMPLETION enabled as queue), I get a timeout. When I run the program in debug mode and single step, everything works fine (maybe a timing problem?).
Also, if I add viReadAsync() followed by viWaitOnEvent(), everything works fine, too.
On the other hand, the same program works with GPIB.
Has someone an idea what this is all about?
Does it make sense to enable an I/O-completion event with viWriteAsync() function call?
(see attachment for source code)
 
Regards
 
M. Brosig
 
Configuration: latest Version of TestStand, LabWindows/CVI.
0 Kudos
Message 1 of 8
(5,713 Views)
hello,

basically it is recommended to use the I/O-completion event with the viWriteAsync()-function (see also the help on the function).
after some tests i could reproduce the behaviour only with the command "*RST\n".
with every other command the program ran through without problems.
does your instrument show the timeout with every used command?

regards,

robert h
national instruments
0 Kudos
Message 2 of 8
(5,693 Views)

Hello Robert,

I tried the program with other commands, and it behaves the same way like yours. I only get a timeout when I send "*RST\n".

I use following port settings (with Agilent E4419B EPM Series Power Meter):

Baud  rate: 9600

Data bits: 8

Parity: NONE

Stop bits: 1

Flow control: NONE

I tried the program with some other instruments, and I could not reproduce the timeout. So with the following instruments the program works fine:

  • Rhode & Schwarz Audio Analyzer DC ... 110kHz UPL
  • Hewlett-Packard 34970A Data Acquisition / Switch Unit
  • Rhode & Schwarz Signal Generator 5kHz ... 3.0GHz

With which instrument(s) did you work?

Maybe it's an instrument depending problem?

Regards,

 

Matthias Brosig

0 Kudos
Message 3 of 8
(5,680 Views)

hello matthias,

i had only an instrument simulator, which reacts on the common commands.
as i read from this tutorial, the "*RST" command doesn't clear the status register. so it might be different from instrument to intrument, how it reacts, if the status byte is not cleared.

regards,

robert h
national instruments

0 Kudos
Message 4 of 8
(5,670 Views)
Hello Robert!
 
 
I read the tutorial. I understand that some instruments may have different effects on sending "*RST".
But does this mean, that for my main problem (timeout) exists no resolution?
So in general with some instruments I can't use the "*RST" command with serial communication and my configuration?
 
Regards,
 
Matthias Brosig
0 Kudos
Message 5 of 8
(5,665 Views)
hello matthias,

it seems like the "*RST\n" command needs different time for each instrument. if you delay the program after the reset command, it works.
this is also the point, why it worked when you stepped the program through in debug mode.

regards,

robert h
0 Kudos
Message 6 of 8
(5,643 Views)
viReadSTB() function performs a true serial polling under GPIB.  But it performs an "*STB?" query then reads the response string under Serial.  A GPIB serial polling under SRQ deasserted can be processed immediately with GPIB chip (such as NAT, TNT, 9914, 7210) itself, but *STB? query requires instrument firmware processing.  I think the difference is caused by that reason.
0 Kudos
Message 7 of 8
(5,636 Views)

Hello!

That sounds plausible. So in theory, using a query with "*STB?\n" under GPIB and Serial should cause the same timeout. But performing this query under GPIB causes no timeout, it works fine. Does instrument firmware process commands under GPIB or serial in different ways?

Regards, M. Brosig 

0 Kudos
Message 8 of 8
(5,625 Views)