Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

How can i clear the GPIB BUS( the buffer) ?

Hello,
 
I'm actually developping an application in LabWindows a GPIB interface, and a lot of GPIB command in my program, and now when i play my application, after (i think) 100 command GPIB there are a problem of buffer, or of saturation of the bus, and the application is down.
SO,  what is the command who permit to clear the GPIB buffer, or to initiate the BUS ?
 
Thanks a lot.
 
yohann
0 Kudos
Message 1 of 2
(4,891 Views)
Probably you have an "overrun" problem on the GPIB bus.  Unlike serial interfaces (RS232 or 485), GPIB uses a three-line handshake architecture at BYTE level communication basis therefore physical over-run problem is implicitly avoided.  However, some instruments implement buffered command IO operation with much delay for actual command execution.  Your case seems like this buffered command problem.
 
Most of GPIB instruments implement Device Clear feature, which initializes command IO buffered and abandons all the unprocessed commands without execution.  You can use ibclr() function for NI-488.2M library or viClear() function for VISA.  Mind that not all the instruments implement Device Clear, and some instruments may Device Clear for different purpose.  Better to check the instrument manual.
 
Alternative way to avoid buffer overrun problem is keep "synchronisation".  By inserting a query command between array of command sending, which will give the instrument a chance to "talk", that buffer overrun problem can be avoided. 
 
For example, instead of just sending:
"VOLT 10"
"VOLT 11"
"VOLT 12"
"VOLT 13"
"VOLT 14"
"VOLT 15"
"VOLT 16"
...
 
Following way can avoid buffer overrun:
"VOLT 10"
"VOLT 11"
"*STB?"  <<<-------- instrument has a chance to talk thereby synchronisation can be kept
(The host app reads the response)
"VOLT 13"
"VOLT 14"
"*STB?" <<<-------- instrument has a chance to talk thereby synchronisation can be kept
(The host app reads the response)
...
 
The key point is, a "machine-gun" talk from the talker ocationally leaves the listener away from the talker, and there is no guallantee about if the listener is really listening to the talks without loss. Instead, inserting acknowledgement confirmation such as "Are you listening? - Yes I am" pair between machine-gun talks will avoid that problem.  This approach is often used for serial interfaces that do not provide any flow controls.
 

このメッセージは 01-27-2006 09:37 AMに Makoto が編集しています。

Message 2 of 2
(4,877 Views)