While running a fairly lengthy series of trials, the HP34970A logger
started to flash it's front panal display and issue beeps, much as it
does(but only once) when power is first applied. It wouldn't turn off
from the front panel. Recycling from the line cord got the same
behavior.

Disengaging the interconnecting cartridges/harness from the unit got
it behaving normally, so that's something to look at, but the big
problem is that the 34970A will no longer communicate over the serial
port with similar cartridges present, unconnected to the test harness.

One thing odd is an error message occurring at power on - error 913
'module reported nonvolatile memory fault'. This error is not reported
when the self-test sequence is run. It occurs only when a 34907
multi-function module, used during the initial testing fault, is
installed in any slot at turn on. I'm working on com issues without
this module installed. The health of that module is just one more
thing to look at.

The 34970A seems perfectly normal otherwise, programming and
functioning from the front panel. The issue is getting serial
communications re-established. I'm using fresh, known good USB-serial
adaptors on the PC, of the same type used during previous long and
successful communication history, and proven null modem harnessing
with the same provenance.

Lack of communication is evidenced by failure to respond to IDN query,
using Visa software interface from either Agilent (secondary) or
Tektronix (primary). Benchlink datalogger sofware generally links
through the secondary Visa without an issue, but the same IDN query
can be generated using other software.

I've scoped the MC145407 interface, and it seems completely healthy,
with all voltages normal and all input signals correctly processed,
but there's nothing coming back from the PC16550 for a response.

All internal supply voltages are present and accounted for, with no
physical signs of overloading or damage, so far. Agilent forums are
silent on the issue, so far, but I don't think many hardware guys
bother monitoring things there.

RL

In article ,
says...
All internal supply voltages are present and accounted for, with no
physical signs of overloading or damage, so far. Agilent forums are
silent on the issue, so far, but I don't think many hardware guys
bother monitoring things there.

RL



I don't know the inside of that unit but if it is any
thing like some equipment we have at work that uses
Intel based mother boards, many things do, the CMOS
battery could be bad and with that, your IRQ settings
are now incorrect and can't link with all the hardware
install.

One example here is, we had to configure INT 11, which
was talking to the custom PCI IO card to operate in legacy
mode, otherwise, it just didn't think any connected devices
was there and reported errors..

If this is the case, you may even have more custom data
being stored that was calibration data from HP that is now
out in left field.

It would be interesting to know if this does in fact have an
Intel board in it. If so, it could also have a video and keyboard
port.

jamie

On Sun, 02 Feb 2014 14:53:47 -0500 legg wrote in
Message id: :

While running a fairly lengthy series of trials, the HP34970A logger
started to flash it's front panal display and issue beeps, much as it
does(but only once) when power is first applied. It wouldn't turn off
from the front panel. Recycling from the line cord got the same
behavior.

Disengaging the interconnecting cartridges/harness from the unit got
it behaving normally, so that's something to look at, but the big
problem is that the 34970A will no longer communicate over the serial
port with similar cartridges present, unconnected to the test harness.

One thing odd is an error message occurring at power on - error 913
'module reported nonvolatile memory fault'. This error is not reported
when the self-test sequence is run. It occurs only when a 34907
multi-function module, used during the initial testing fault, is
installed in any slot at turn on. I'm working on com issues without
this module installed. The health of that module is just one more
thing to look at.

The 34970A seems perfectly normal otherwise, programming and
functioning from the front panel. The issue is getting serial
communications re-established. I'm using fresh, known good USB-serial
adaptors on the PC, of the same type used during previous long and
successful communication history, and proven null modem harnessing
with the same provenance.

Lack of communication is evidenced by failure to respond to IDN query,
using Visa software interface from either Agilent (secondary) or
Tektronix (primary). Benchlink datalogger sofware generally links
through the secondary Visa without an issue, but the same IDN query
can be generated using other software.

I've scoped the MC145407 interface, and it seems completely healthy,
with all voltages normal and all input signals correctly processed,
but there's nothing coming back from the PC16550 for a response.

All internal supply voltages are present and accounted for, with no
physical signs of overloading or damage, so far. Agilent forums are
silent on the issue, so far, but I don't think many hardware guys
bother monitoring things there.

RL

You may have a weak backup battery. If it's settings are lost it will
revert back to GPIB default instead of serial communication. Check the
communications options under the utility menu.

On Sun, 2 Feb 2014 18:42:51 -0500, "Maynard A. Philbrook Jr."
wrote:

In article ,
says...
All internal supply voltages are present and accounted for, with no
physical signs of overloading or damage, so far. Agilent forums are
silent on the issue, so far, but I don't think many hardware guys
bother monitoring things there.

RL



I don't know the inside of that unit but if it is any
thing like some equipment we have at work that uses
Intel based mother boards, many things do, the CMOS
battery could be bad and with that, your IRQ settings
are now incorrect and can't link with all the hardware
install.

One example here is, we had to configure INT 11, which
was talking to the custom PCI IO card to operate in legacy
mode, otherwise, it just didn't think any connected devices
was there and reported errors..

If this is the case, you may even have more custom data
being stored that was calibration data from HP that is now
out in left field.

It would be interesting to know if this does in fact have an
Intel board in it. If so, it could also have a video and keyboard
port.

jamie

No it's all PICs, and the lithium battery was replaced in '12.

I do suspect that there's been programming corruption in one of the
PICS, though.

I'm finding that parts unconnected at the time have suffered.

For example, recalibrating one of the DAC outputs on the 34907 module
retired the power-on error. These DACs weren't even connected at the
time of the fault.

RL

On Mon, 03 Feb 2014 05:42:38 -0500, JW wrote:

On Sun, 02 Feb 2014 14:53:47 -0500 legg wrote in
Message id: :

While running a fairly lengthy series of trials, the HP34970A logger
started to flash it's front panal display and issue beeps, much as it
does(but only once) when power is first applied. It wouldn't turn off
from the front panel. Recycling from the line cord got the same
behavior.

Disengaging the interconnecting cartridges/harness from the unit got
it behaving normally, so that's something to look at, but the big
problem is that the 34970A will no longer communicate over the serial
port with similar cartridges present, unconnected to the test harness.

One thing odd is an error message occurring at power on - error 913
'module reported nonvolatile memory fault'. This error is not reported
when the self-test sequence is run. It occurs only when a 34907
multi-function module, used during the initial testing fault, is
installed in any slot at turn on. I'm working on com issues without
this module installed. The health of that module is just one more
thing to look at.

The 34970A seems perfectly normal otherwise, programming and
functioning from the front panel. The issue is getting serial
communications re-established. I'm using fresh, known good USB-serial
adaptors on the PC, of the same type used during previous long and
successful communication history, and proven null modem harnessing
with the same provenance.

Lack of communication is evidenced by failure to respond to IDN query,
using Visa software interface from either Agilent (secondary) or
Tektronix (primary). Benchlink datalogger sofware generally links
through the secondary Visa without an issue, but the same IDN query
can be generated using other software.

I've scoped the MC145407 interface, and it seems completely healthy,
with all voltages normal and all input signals correctly processed,
but there's nothing coming back from the PC16550 for a response.

All internal supply voltages are present and accounted for, with no
physical signs of overloading or damage, so far. Agilent forums are
silent on the issue, so far, but I don't think many hardware guys
bother monitoring things there.

RL

You may have a weak backup battery. If it's settings are lost it will
revert back to GPIB default instead of serial communication. Check the
communications options under the utility menu.

All is copacetic as far as front panel communications and set-up are
concerned. As a last resort, I'm dusting off an old usb-gpib interface
to see if it's still reachable from the other port. Maybe twiddling a
few registers will do something.

Battery replaced in late '12.

RL