> Therefore, talk-only mode is a big advantage in terms of decoupling > on RS-232 and makes almost no difference on GPIB.
That's not the case when it comes to counters. By timing issues, I wasn't referring to layer-1 handshaking, but rather the interplay between the GPIB software application, the network or bus connectivity between the app and GPIB controller, the controller itself and its firmware, and an addressable counter that returns each measurement only in response to a command from the app. The difference in performance between a talk-only connection and a two-way conversation can be substantial. Yes, everything runs in lockstep, but the sum of the delays and latencies in each of those stages can easily exceed 0.1 second. In Attila's case there are also VM crossings in both directions to worry about. The counter, unlike any of the other participants in the conversation, is working on a deadline. Everything in a counter tends to happen in the "foreground," so to speak. If the counter takes too long to interpret and execute a GPIB command, it may fail to rearm itself in time for the next trigger. That's never a problem in talk-only mode, at least not at rates we're concerned with here, because the counter never has to do anything but send out data. -- john, KE5FX Miles Design LLC _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
