[time-nuts] Prologix GPIB-NET, HP 5370A, HP5334A problem?

wje wje at quackers.net
Wed Aug 27 19:20:52 EDT 2008

   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' />
       <Source classname='PrologixTCPSource'>
           <Param name='host' value=''/>
    <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'/>
   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
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 at febo.com
To unsubscribe, go to [2]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


   1. mailto:time-nuts at febo.com
   2. https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

More information about the time-nuts mailing list