HP 3852A GPIB timeouts

[davorin]

Evnin' (o;

Just testing a HP 3852A with the TC 44708A muxer and logging data with Cacti...

Experiencing after few GPIB readings a long timeout of around 10 seconds....then it goes back to normal...
Set now a higher timeout value in gpib.conf....seems better now when logging the data....

But what's the point in having such a device with amuxer capable of switching 450 channels/sec and then wait 10 seconds for the data? (o;

[bingo600]

Evnin' (o;

Just testing a HP 3852A with the TC 44708A muxer and logging data with Cacti...

Experiencing after few GPIB readings a long timeout of around 10 seconds....then it goes back to normal...
Set now a higher timeout value in gpib.conf....seems better now when logging the data....

But what's the point in having such a device with amuxer capable of switching 450 channels/sec and then wait 10 seconds for the data? (o;

Suggestions:
Do you have EOI / EOT / EOS trouble ?
What is the settings of the HP for (termination ?) , EOI or ??
If EOT , does it trig on CR or LF ?

/Bingo

[davorin]

Here we are again (o;

Guess I have to do some deeper reading into the GPIB bus ;-)

What I have in gpib.conf:

Code: [Select]

gpib.conf:

interface {
minor = 1
board_type = "agilent_82357a"
name = "agilent2"
pad = 0
sad = 0
timeout = T3s

eos = 0x0a
set-bin = no
set-eot = yes /* Assert EOI with last byte on writes */

master = yes
}

device {
minor = 1
name = "3852A"
pad = 9
sad = 0
timeout = T30s
eos = 0x0a
}

What puzzles me is the fact that this simple snippet reads it out just fine within few milliseconds for lets say 10 times...then it takes around 10 seconds....and goes back to normal again...

Code: [Select]

#!/usr/bin/python

import Gpib
import sys

# command = sys.argv[1]

a = Gpib.Gpib('3852A')
a.write('CONFMEAS TEMPK,500')
temp = float(a.read(60))
temp = int(100000 * temp)
print temp

Maybe something with the commands I am doing wrong (o;

Though the graph looks fine now with timeout set to 30 seconds:

[bingo600]

He..He  , yes we have been here before 


Example:
On my HP 3458A i have to send : END ALWAYS , as the first command in order to get the meter to set EOI along with the last byte sent.

If i don't, the linux gpib always times out before returning any data , and some data are lost.

Try to see what it says in the manual.

On some older HP's, EOI was selected on the "gpib addr" dipswitch on the back.

If you can get your instrumnt to set the EOI line when sending last byte , that's the 99.9% easiest way to signal "End of Data" to linux-gpib.

/Bingo

[bingo600]

In manual have a look @pg 5.14 , END command (though it seems to set EOI default by pwr on)

The unit seems to have an advances buffering system , make sure you don't overrun it.

I'd run a few manual measurements via ibterm

/Bingo