In message <00d801d15170$f91c6630$eb553290$@miles.io>, "John Miles" writes:
>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
If you have RS232 connections, won't you have one for each device ? Whereas
with GPIB, you'll (probably) only have one bus. The GPIB bus will arbitrate
and avoid both instruments talking at the same time (this might not be true
in talk-only mode since there's no target address involved) but it does
In message <569bcebe.20...@erols.com>, Chuck Harris writes:
>Talk-only mode is by intention, an exclusive mode, where
>there is one talker, and one listener on the bus.
Wrong.
There can *always* be multiple listeners on GPIB, this is
why it has a three wire handshake.
The slowest liste
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 int
> 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, t
mag...@rubidium.dyndns.org said:
> OK, you where thinking about the flow-control.
> You can have RS-232 wired up to do flow-control (hardware-flow-control),
> where as flow-control is a standard property of GPIB. On the other hand,
> flow-control in itself only assures the data-transfer but not th
Talk-only mode is by intention, an exclusive mode, where
there is one talker, and one listener on the bus. There
can be exceptions where there are more than one listener,
but that tends to be unusual.
Addressed mode can have one or more instrument on the
bus. Although addressed mode is fully or
In message <569b8b2e.5070...@rubidium.dyndns.org>, Magnus Danielson writes:
>>> I think you should develop that line of thought, to detail why it helps
>>> on GPIB and why not on serial.
>>
>> It's really very simple: RS-232 sends blind, you don't even need to
>> know if there is a recei
Poul-Henning,
On 01/17/2016 01:45 PM, Poul-Henning Kamp wrote:
In message <569b8b2e.5070...@rubidium.dyndns.org>, Magnus Danielson writes:
I think you should develop that line of thought, to detail why it helps
on GPIB and why not on serial.
It's really very simple: RS-232 sends bl
Poul-Henning,
On 01/17/2016 12:52 PM, Poul-Henning Kamp wrote:
In message <569b61cf.3030...@rubidium.dyndns.org>, Magnus Danielson writes:
This is a common misunderstanding: Talk-only does *not* protecting you
against timing issues on GPIB.
On RS-232, yes, but not on GPIB.
Agree,
In message <569b61cf.3030...@rubidium.dyndns.org>, Magnus Danielson writes:
>> This is a common misunderstanding: Talk-only does *not* protecting you
>> against timing issues on GPIB.
>>
>> On RS-232, yes, but not on GPIB.
>
>Agree, to some degree. It's not a guarantee.
>
>I think you sh
Guete Morge!
On Sun, 17 Jan 2016 07:24:32 +0100
Magnus Danielson wrote:
> >> Have you tried swapping "role" of the SR620?
> >
> > Yes, I've done that. Both SR620's lose some samples, but only one of
> > them loses significantly more than the other.
>
> OK. So, the dropping follows the counter r
Moin John,
On Sat, 16 Jan 2016 13:33:54 -0800
"John Miles" wrote:
> Agreed with Magnus that there are a lot of possible variables in your setup
> that need to be ruled out.
Yes, too many. And it isn't really helping that I hardly understand what
I am doing.
> Are you using the SR620 driver
Dear Poul-Henning,
On 01/17/2016 10:08 AM, Poul-Henning Kamp wrote:
In message <569b3b7e.6090...@rubidium.dyndns.org>, Magnus Danielson writes:
It's always safest to use counters in talk-only mode when possible,
since that rules out any timing problems that might arise in a
two-way GP
In message <569b3b7e.6090...@rubidium.dyndns.org>, Magnus Danielson writes:
>> It's always safest to use counters in talk-only mode when possible,
>>since that rules out any timing problems that might arise in a
>>two-way GPIB [...]
This is a common misunderstanding: Talk-only does *not
John,
On 01/16/2016 10:33 PM, John Miles wrote:
Agreed with Magnus that there are a lot of possible variables in your setup
that need to be ruled out.
Are you using the SR620 driver in TimeLab, or did you find a way to get it to
emit data continuously via the RS232 port for use with the talk-
God morgon!
On 01/16/2016 08:48 PM, Attila Kinali wrote:
God kväll!
On Sat, 16 Jan 2016 06:00:54 +0100
Magnus Danielson wrote:
The two SR620s are both connected to an FS725 Rb frequency standard
(mostly because we have them around and nobody else uses them :-)
It's being used, by you! ;-)
God kväll!
On Sat, 16 Jan 2016 06:00:54 +0100
Magnus Danielson wrote:
> > The two SR620s are both connected to an FS725 Rb frequency standard
> > (mostly because we have them around and nobody else uses them :-)
>
> It's being used, by you! ;-)
There is another one lying around, nobody uses...
Agreed with Magnus that there are a lot of possible variables in your setup
that need to be ruled out.
Are you using the SR620 driver in TimeLab, or did you find a way to get it to
emit data continuously via the RS232 port for use with the talk-only driver?
I've seen occasional instances whe
Attila,
On 01/14/2016 03:38 PM, Attila Kinali wrote:
Moin,
I have here a setup with four (FPGA) nodes that produce synchronized pulses
with a 20kHz rate. I have two SR620s two measure those pulses.
Because the SR620s are not fast enought to capture all pulses, and because
i want them to be syn
Moin,
I have here a setup with four (FPGA) nodes that produce synchronized pulses
with a 20kHz rate. I have two SR620s two measure those pulses.
Because the SR620s are not fast enought to capture all pulses, and because
i want them to be synchronized, I set up one of the nodes to generate an
addi
21 matches
Mail list logo
