Prologix GPIB-NET, HP 5370A, HP5334A problem?
I just got one of the new networked GPIB controllers, and I've been
having some issues. I'm not sure if it's the Prologix or the
instruments, or both.
With the 5370A, I can get samples for some period of time ranging from
about 2 to 4 hours before the GPIB controller stops responding. I
suspect this one might be the 5370A -488 controller bug I've heard of.
However, there is no way to recover without power-cycling the Prologix.
Even if this is the 5370A, the Prologix should really have an
asynchronous reset capability.
With the 5334A, I can get samples for as long as I want, no problem.
However, if I set the 5334A to 'WA1' mode, which is supposed to wait
until the counter is addressed before taking each sample, what happens
is that I can read one value. Every successive read returns the same
value; the 5334A never triggers for a new sample. Either I don't
understand the behavior of WA1, although HP's sample program indicates
that what I've described is proper, or there is some incompatibility
between the Prologix and the 5334A.
Unfortunately, the documentation for the Prologix is scanty at best.
There is no description of the actual IEEE-488 handshake process that's
going on. For example, does the Prologix do an unlisten after a read?
The HP docs seem to indicate that in WA1 mode, a sample starts when the
5334A is addressed. So, if it's never unlistened, perhaps it never takes
a new sample?
Any thoughts or suggestions would be appreciated.
--
Bill Ezell
They said 'Windows or better'
so I used Linux.
Bill,
How are you reading from 5334A? Is the read-after-write mode OFF?
I recommend the following sequence:
++auto 0 -- turn off read-after-write
++read eoi -- read until EOI is asserted by the instrument
++read eoi
....
(If your instrument does not assert EOI, specify a character to terminate
++read command. See manual for details.)
Yes, ++read will address the instrument to talk, read any output, and then
address it to listen.
We are testing an update that resets the controller if it detects a hung
GPIB bus. I can send that to you offline.
Regards,
Abdul
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of wje
Sent: Wednesday, August 27, 2008 3:12 PM
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] Prologix GPIB-NET, HP 5370A, HP5334A problem?
I just got one of the new networked GPIB controllers, and I've been
having some issues. I'm not sure if it's the Prologix or the
instruments, or both.
With the 5370A, I can get samples for some period of time ranging from
about 2 to 4 hours before the GPIB controller stops responding. I
suspect this one might be the 5370A -488 controller bug I've heard of.
However, there is no way to recover without power-cycling the Prologix.
Even if this is the 5370A, the Prologix should really have an
asynchronous reset capability.
With the 5334A, I can get samples for as long as I want, no problem.
However, if I set the 5334A to 'WA1' mode, which is supposed to wait
until the counter is addressed before taking each sample, what happens
is that I can read one value. Every successive read returns the same
value; the 5334A never triggers for a new sample. Either I don't
understand the behavior of WA1, although HP's sample program indicates
that what I've described is proper, or there is some incompatibility
between the Prologix and the 5334A.
Unfortunately, the documentation for the Prologix is scanty at best.
There is no description of the actual IEEE-488 handshake process that's
going on. For example, does the Prologix do an unlisten after a read?
The HP docs seem to indicate that in WA1 mode, a sample starts when the
5334A is addressed. So, if it's never unlistened, perhaps it never takes
a new sample?
Any thoughts or suggestions would be appreciated.
--
Bill Ezell
They said 'Windows or better'
so I used Linux.
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.
I just got one of the new networked GPIB controllers, and I've been
having some issues. I'm not sure if it's the Prologix or the
instruments, or both.
With the 5370A, I can get samples for some period of time ranging from
about 2 to 4 hours before the GPIB controller stops responding. I
suspect this one might be the 5370A -488 controller bug I've heard of.
However, there is no way to recover without power-cycling the Prologix.
Even if this is the 5370A, the Prologix should really have an
asynchronous reset capability.
With the 5334A, I can get samples for as long as I want, no problem.
However, if I set the 5334A to 'WA1' mode, which is supposed to wait
until the counter is addressed before taking each sample, what happens
is that I can read one value. Every successive read returns the same
value; the 5334A never triggers for a new sample. Either I don't
understand the behavior of WA1, although HP's sample program indicates
that what I've described is proper, or there is some incompatibility
between the Prologix and the 5334A.
Unfortunately, the documentation for the Prologix is scanty at best.
There is no description of the actual IEEE-488 handshake process that's
going on. For example, does the Prologix do an unlisten after a read?
The HP docs seem to indicate that in WA1 mode, a sample starts when the
5334A is addressed. So, if it's never unlistened, perhaps it never takes
a new sample?
Any thoughts or suggestions would be appreciated.
Bill, what commands and queries are you using with the 5370A? I have a
couple of those new Prologix LAN dongles here and could try to repro it here
on my 5370B, if it turns out that Abdul needs to see it happen in person.
I don't have a 5334A, but it might help to send it a ++trg trigger command.
If not, you'd probably need to switch auto-read mode off for that one, and
use manual ++read commands.
-- john, KE5FX
If the 5370A problem is actually the 5370A gpib controller bug, then I
don't think it can be reproduced with the 5370B; I'm pretty sure that
was fixed in the B model.
However, if you want to give it a try, here's what I do (you'll have to
interpret, but it should be pretty clear):
<Prompt prompt='Enter file name' default='5370'/>
<Save name='name'/>
<Logger name='data' classname='FileLogger'>
<Param name='filename' value='%recall name%-%date%.txt' />
<Param name='append' value='false' />
</Logger>
<Source classname='PrologixTCPSource'>
<Param name='host' value='192.168.100.11'/>
</Source>
<SourceCmd cmd='device' param='6'/>
<SourceCmd cmd='++read_tmo_ms' param='4000'/>
<Send msg='SS2'/>
<Send msg='MD2'/>
<Send msg='AR1'/>
<Wait seconds='2'/>
<Send msg='MR'/>
<Wait seconds='1'/>
<Repeat count='24'>
<Repeat count='60'>
<Logmessage name='data' msg='#date %fulldate%'/>
<Repeat count='60'>
<Send msg='MR'/>
<Wait seconds='1'/>
<Read timeout='4'/>
<Log name='data'/>
</Repeat>
</Repeat>
</Repeat>
Sorry for the strange syntax, but that's for a Java control program I
originally wrote to talk to my Solartron 7081 meter.
The program is just sending out the literal string in the Sends,
terminated with a newline.
The Read command is sending '++read 10'. The timeout in the Read has
nothing to do with the Prologix timeout, that's a timeout handled by my
interpreter.
Bill Ezell
They said 'Windows or better'
so I used Linux.
John Miles wrote:
I just got one of the new networked GPIB controllers, and I've been
having some issues. I'm not sure if it's the Prologix or the
instruments, or both.
With the 5370A, I can get samples for some period of time ranging from
about 2 to 4 hours before the GPIB controller stops responding. I
suspect this one might be the 5370A -488 controller bug I've heard of.
However, there is no way to recover without power-cycling the Prologix.
Even if this is the 5370A, the Prologix should really have an
asynchronous reset capability.
With the 5334A, I can get samples for as long as I want, no problem.
However, if I set the 5334A to 'WA1' mode, which is supposed to wait
until the counter is addressed before taking each sample, what happens
is that I can read one value. Every successive read returns the same
value; the 5334A never triggers for a new sample. Either I don't
understand the behavior of WA1, although HP's sample program indicates
that what I've described is proper, or there is some incompatibility
between the Prologix and the 5334A.
Unfortunately, the documentation for the Prologix is scanty at best.
There is no description of the actual IEEE-488 handshake process that's
going on. For example, does the Prologix do an unlisten after a read?
The HP docs seem to indicate that in WA1 mode, a sample starts when the
5334A is addressed. So, if it's never unlistened, perhaps it never takes
a new sample?
Any thoughts or suggestions would be appreciated.
Bill, what commands and queries are you using with the 5370A? I have a
couple of those new Prologix LAN dongles here and could try to repro it here
on my 5370B, if it turns out that Abdul needs to see it happen in person.
I don't have a 5334A, but it might help to send it a ++trg trigger command.
If not, you'd probably need to switch auto-read mode off for that one, and
use manual ++read commands.
-- john, KE5FX
time-nuts mailing list -- [1]time-nuts@febo.com
To unsubscribe, go to [2]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
References
I'm not familiar with any GPIB bugs on the 5370A, but I moved your code over
to C and ran it on my 5370B via a GPIB-LAN adapter. The test app failed
after ~6 hours with a Winsock timeout error. I'm thinking that was caused
by a power glitch, though, because I actually had to power-cycle the counter
(rather than the Prologix dongle) to get the program running again. Was
that your experience?
Since then it's finished a 24-hour run without any sign of trouble.
-- john, KE5FX
If the 5370A problem is actually the 5370A gpib controller bug, then I
don't think it can be reproduced with the 5370B; I'm pretty sure that
was fixed in the B model.
However, if you want to give it a try, here's what I do (you'll have to
interpret, but it should be pretty clear)...
C version:
GPIB_connect(atoi(argv[1]),
GPIB_error,
0,
20000); // Set 20-second timeout
GPIB_set_EOS_mode(10);
GPIB_set_serial_read_dropout(20000); // 20-second dropout
GPIB_write("SS2"); // Sample size = 100
GPIB_write("MD2"); // Lock out rate control, hold until MR
GPIB_write("AR1"); // +T.I. arming only
Sleep(2000);
GPIB_write("MR"); // Manual read (discard first reading)
Sleep(1000);
for (S32 h=0; h < 24; h++)
{
for (S32 m=0; m < 60; m++)
{
for (S32 s=0; s < 60; s++)
{
GPIB_write("MR");
Sleep(1000);
printf("%d:%d:%d %s",
h,m,s,
GPIB_read_ASC());
}
}
}
Yes, that was essentially what I was seeing over a few runs. The
failure times I saw were on the order of 2-4 hours.
I've moved my 5370 over to a UPS, along with the Prologix and the
router, and I'll see what happens. I have to wait until my 3-day 5334
run finishes, though. I'm measuring long-term phase difference between
my 5061A and my Z3801A. The 5334 has been running solidly for 1.5 days,
so I can eliminate power problems at this point.
This brings up another question. I'm seeing cyclic phase variations of
about 10 ns with a pretty regular 1 hour cycle. The overall long-term
average is OK, 1e-13 ADEV at 6000 seconds. I'm guessing this has
something to do with satellite orbits, but I'd welcome any
explanations.
As for the 5370A bug, there was a thread a while back in time-nuts
describing a bug in the GPIB controllers for the 5370A's that would
occasionally and randomly cause a bus lockup. This problem was
supposedly fixed in the B series. That's all I've seen on the issue, so
it's possible that the bug doesn't actually exist. If I still get
failures, I'll swap in a controller from my spare 5370 and see if
there's any difference.
BTW, I've been doing precision AC and DC measurements for a long time,
but I have to say that high-resolution time/freq measurements are even
more fun!
Bill Ezell
They said 'Windows or better'
so I used Linux.
John Miles wrote:
I'm not familiar with any GPIB bugs on the 5370A, but I moved your code over
to C and ran it on my 5370B via a GPIB-LAN adapter. The test app failed
after ~6 hours with a Winsock timeout error. I'm thinking that was caused
by a power glitch, though, because I actually had to power-cycle the counter
(rather than the Prologix dongle) to get the program running again. Was
that your experience?
Since then it's finished a 24-hour run without any sign of trouble.
-- john, KE5FX
If the 5370A problem is actually the 5370A gpib controller bug, then I
don't think it can be reproduced with the 5370B; I'm pretty sure that
was fixed in the B model.
However, if you want to give it a try, here's what I do (you'll have to
interpret, but it should be pretty clear)...
C version:
GPIB_connect(atoi(argv[1]),
GPIB_error,
0,
20000); // Set 20-second timeout
GPIB_set_EOS_mode(10);
GPIB_set_serial_read_dropout(20000); // 20-second dropout
GPIB_write("SS2"); // Sample size = 100
GPIB_write("MD2"); // Lock out rate control, hold until MR
GPIB_write("AR1"); // +T.I. arming only
Sleep(2000);
GPIB_write("MR"); // Manual read (discard first reading)
Sleep(1000);
for (S32 h=0; h < 24; h++)
{
for (S32 m=0; m < 60; m++)
{
for (S32 s=0; s < 60; s++)
{
GPIB_write("MR");
Sleep(1000);
printf("%d:%d:%d %s",
h,m,s,
GPIB_read_ASC());
}
}
}
time-nuts mailing list -- [1]time-nuts@febo.com
To unsubscribe, go to [2]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
References