J_C wrote:
The command works most of the time, just goes wrong at random.
Thanks.
JC, Its a shame you got stuck with someone else's code. OK Agilent VISA drivers assume several things any of them could be your new headache.
1) The instruments on the bus are all compliant to the same standard (HPIB, IEE 488 or IEEE 488.2 [there is no 488.1 whatever Keithley instruments likes to say] or HS-488) are there other instruments on the bus?
2) ALL instruments are assigned an address corresponding to their importance. The service requests of lower addressed instruments mask the service requests above them. This means that latency in GBIP is dependant on service request polling and address.
3) Are you using VISA? if you use IVI or VISA you use VISA. If you are are you using synchronous or asynchronus calls to ibread and ibwrt? Remember the timing changes dependant on system overhead and the size of the GPIB buffer. For example- you have two functions that write a value VIA GBIP using the synchronus call and read responses from those instruments. Write (L) is a multiline message that takes about 1 second to pass through the bus ending in a query, Write (S) is a query for a measurement and passes through the bus in 1mS. TMO for Instr(L) is 30000mS and 1000mS for Instr(S). synchronous writes return when the data is delivered to the GBIP buffer so it takes almost no time for either of the write functions to do their job and return. Yet, when will the Write(S) data make it to Inst(S)? in 1mS if the buffer is empty but, in about 1001mS if the Write(L) data just beat it to the buffer! Assume the Instuments process commands instantly. When will you TMO on the read from Inst(s)? never if the buffer latency is zero. 1 time in 1001 if a random 1second buffer load is possible and 28999 times out of 30000 if there is a problem with instr(L) failing to respond to an ibread that occured with random time relation.
Number three sounds like your issue doesn't it. Agilent drivers like to use synchronous reads and writes. The best work-around is to revise the drivers to use asynchronous calls to ibwrt functions. Asyncronous calls do not return untill the buffer is clear so you can assume the data is at the instrument not hanging around idleing in a buffer.
So you've hit a basic program language model issue - Data-flow / Event / Data flow from what perspective? / which event?
"Should be" isn't "Is" -Jay
