[time-nuts] Wavecrest DTS 2070 GPIB access

[Ulrich Bangert]

John,

I do not have any experience with the Wavecrest but my experience with
devices that do not seem to answer on bus requests is that they often DO
ANSWER the request but after the answer they do not serve the bus's EOI line
correct. Checking the EOI line is the standard way that the controller
checks the presence of an answer with. For me this was the case at least
with a HP3457 multimeter as well as a R&S URV 5 rf power meter. 

If you use a NI compatible plugin card with the accompanying DLL you should
make yourself a debugging aid that enables you to display the contents of
the input buffer (the one you give the pointer to the dll for a read call)
in case of timeout. For me usually the correct answer  was to be found in
the input buffer despite the timeout. That was the reason why I switched my
EZGPIB communication completely from EOI to EOS. Even the instruments that
do not serve the EOI line correct seem to send a correct string termination
as <CR> or <LF>.

73s de Ulrich, DF6JB

> -----Ursprungliche Nachricht-----
> Von: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] Im Auftrag von John Miles
> Gesendet: Dienstag, 23. November 2010 11:27
> An: time-nuts at febo.com
> Betreff: [time-nuts] Wavecrest DTS 2070 GPIB access
> 
> 
> I'm looking at writing some code to drive the DTS 2070, but 
> have been running into timeout errors performing any GPIB 
> query (even *IDN?) while the instrument is taking 
> measurements, even in sizes/sets of 1/1 at a 1-pps rate.  Has 
> anyone else run into this before?
> 
> This happens equally with either a Prologix GPIB-USB adapter, 
> or an NI PCI-GPIB board, both of which are otherwise reliable.
> 
> -- john, KE5FX
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to 
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.