John,
On 01/17/2016 10:49 PM, John Miles wrote:
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.
It was time that we started to talk about this total picture.
Add that some GPIB interfaces uses USB-to-serial chips and then
serial-CPU-GPIB. Many instruments uses a GPIB chip having the low-level
logic to off-load the CPU. The SR620 for instance uses the TMS9914 GPIB
controller chip, which does much of the hand-shaking, but does not
offload the CPU much in regards to FIFO-buffering, which is typical of
its age. Still, much of the lower level stuff gets the boost it needs.
The SR620 has maybe not the powerhouse processor, so that should be a
limitation by itself. Interestingly the SR620 uses a Z80 as a IO
processor to draw on XY scopes.
There is more handshake in the GPIB than pure flow-control, but I've not
seen it used and honestly I haven't tried it myself. It seems like the
support is there and documented for many instruments. Shouldn't we try
to use that to aid the ping-pong between instruments?
Building up the system, we should think about how the system maintain
its properties, data flow, arm-trigger mechanisms.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
