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"
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 が編集しています。