Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
34970A data logger loss of serial port com
352 views
Skip to first unread message
legg
Feb 2, 2014, 2:26:35 PM2/2/14
to
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
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
mrob...@att.net
Feb 2, 2014, 3:26:20 PM2/2/14
to
legg <le...@nospam.magma.ca> wrote:
> 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'.
If there really is a non-volatile memory error, maybe it is reverting
> 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'.
to its lowest, highest, or default bit rate on the serial port? Have
you tried different bit rates in the connected equipment? If the HP
puts something out on the serial port when turned on (banner, "I am
here" info), maybe scope that while turning the HP on to see what the
timing looks like?
Arguing against this is that it seems weird to keep the bit rate - a
parameter for the logger itself - in the NVM on an input module.
> 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.
of the "output" signals (TXD, RTS, DTR) to ground at the external RS-232
connector?
The 16550 has its own crystal; is that operating at close to the right
frequency? There appear to be handy test points on the XIN and BAUDOUT
pins.
This is probably not related, but: a few years ago I tried to roll my
own program to talk to an Agilent RF power meter over its RS-232 port.
I found the protocol documentation to be extremely lacking, and I also
found that incorrect commands on the RS-232 port would cause the meter
to just lock up, requiring an AC power cycle to correct. I gave up on
it after wasting half a day or so. My point is, don't totally discount
the possibility that the firmware is doing something weird.
Matt Roberds
legg
Feb 2, 2014, 6:41:20 PM2/2/14
to
On Sun, 2 Feb 2014 20:26:20 +0000 (UTC), mrob...@att.net wrote:
>legg <le...@nospam.magma.ca> wrote:
>> 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'.
>
>If there really is a non-volatile memory error, maybe it is reverting
>to its lowest, highest, or default bit rate on the serial port? Have
>you tried different bit rates in the connected equipment? If the HP
>puts something out on the serial port when turned on (banner, "I am
>here" info), maybe scope that while turning the HP on to see what the
>timing looks like?
Nothing from the tx at power on.
>legg <le...@nospam.magma.ca> wrote:
>> 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'.
>
>If there really is a non-volatile memory error, maybe it is reverting
>to its lowest, highest, or default bit rate on the serial port? Have
>you tried different bit rates in the connected equipment? If the HP
>puts something out on the serial port when turned on (banner, "I am
>here" info), maybe scope that while turning the HP on to see what the
>timing looks like?
>
>Arguing against this is that it seems weird to keep the bit rate - a
>parameter for the logger itself - in the NVM on an input module.
>
>> 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.
>
>What happens to the voltages if you put a 1K or so resistor from each
>of the "output" signals (TXD, RTS, DTR) to ground at the external RS-232
>connector?
Carrier detect is also high and load similarly. The rest are the lines
that are visibly functional - these are inputs floating around ground.
>
>The 16550 has its own crystal; is that operating at close to the right
>frequency? There appear to be handy test points on the XIN and BAUDOUT
>pins.
scope.
What bothers me is that the serial port section is completely isolated
from the logging input hardware, where any kind of fault would be
expected. A lot of other hardware isn't though. If the problem is in
the logging input live section (includes the 'main' controller), then
I could be looking at corrupted memory that isn't on a module.
>
>This is probably not related, but: a few years ago I tried to roll my
>own program to talk to an Agilent RF power meter over its RS-232 port.
>I found the protocol documentation to be extremely lacking, and I also
>found that incorrect commands on the RS-232 port would cause the meter
>to just lock up, requiring an AC power cycle to correct. I gave up on
>it after wasting half a day or so. My point is, don't totally discount
>the possibility that the firmware is doing something weird.
>
>Matt Roberds
RL
mrob...@att.net
Feb 2, 2014, 11:18:29 PM2/2/14
to
legg <le...@nospam.magma.ca> wrote:
> The Tx terminal is static high, loaded down to below 3V by 2K.
1K was from memory; Googling the spec indicates a range of 3K to 7K is
> The Tx terminal is static high, loaded down to below 3V by 2K.
popular. If 3K or more also loads it down below 3 V, I'd start to
suspect the MC145407 or the charge pump caps connected to it.
> Carrier detect is also high and load similarly.
to TXD, there is RTS and DTR. It is possible that one of these doesn't
raise until the logger thinks it is "ready", or maybe it is affected by
the flow control options in the Interface menu.
> I'll check oscillators and clocks the next time it's open near a
> scope.
resonator (U301). Was the unit banged around, dropped, etc?
> What bothers me is that the serial port section is completely isolated
> from the logging input hardware, where any kind of fault would be
> expected. A lot of other hardware isn't though.
then a lot of other things would be dead. Maybe the supply is noisy?
Matt Roberds
RL
Feb 3, 2014, 10:23:20 AM2/3/14
to
On Sunday, 2 February 2014 23:18:29 UTC-5, mrob...@att.net wrote:
> legg <le...@nospam.magma.ca> wrote:
>
> > The Tx terminal is static high, loaded down to below 3V by 2K.
>
>
>
> 1K was from memory; Googling the spec indicates a range of 3K to 7K is
>
> popular. If 3K or more also loads it down below 3 V, I'd start to
>
> suspect the MC145407 or the charge pump caps connected to it.
>
>
>
> > Carrier detect is also high and load similarly.
>
>
>
> The schematic shows that there isn't a "carrier detect". In addition
>
> to TXD, there is RTS and DTR. It is possible that one of these doesn't
>
> raise until the logger thinks it is "ready", or maybe it is affected by
>
> the flow control options in the Interface menu.
There is no flow control on all of the default RS232 settings used.
> legg <le...@nospam.magma.ca> wrote:
>
> > The Tx terminal is static high, loaded down to below 3V by 2K.
>
>
>
> 1K was from memory; Googling the spec indicates a range of 3K to 7K is
>
> popular. If 3K or more also loads it down below 3 V, I'd start to
>
> suspect the MC145407 or the charge pump caps connected to it.
>
>
>
> > Carrier detect is also high and load similarly.
>
>
>
> The schematic shows that there isn't a "carrier detect". In addition
>
> to TXD, there is RTS and DTR. It is possible that one of these doesn't
>
> raise until the logger thinks it is "ready", or maybe it is affected by
>
> the flow control options in the Interface menu.
>
>
>
> > I'll check oscillators and clocks the next time it's open near a
>
> > scope.
>
>
>
> Looking at it again, the I/O controller (U305A) runs on a 12 MHz ceramic
>
> resonator (U301). Was the unit banged around, dropped, etc?
>
All oscillators are banging away at their labeled frequencies.
>
>
> > I'll check oscillators and clocks the next time it's open near a
>
> > scope.
>
>
>
> Looking at it again, the I/O controller (U305A) runs on a 12 MHz ceramic
>
> resonator (U301). Was the unit banged around, dropped, etc?
>
>
>
> > What bothers me is that the serial port section is completely isolated
>
> > from the logging input hardware, where any kind of fault would be
>
> > expected. A lot of other hardware isn't though.
>
>
>
> The schematic says it "uses backplane supply", but if that was gone,
>
> then a lot of other things would be dead. Maybe the supply is noisy?
>
>
>
> Matt Roberds
An awful lot of stuff is common to the ADC and it's floating hot measurement terminals, including the main controller, memory and even the front panel display.......
>
> > What bothers me is that the serial port section is completely isolated
>
> > from the logging input hardware, where any kind of fault would be
>
> > expected. A lot of other hardware isn't though.
>
>
>
> The schematic says it "uses backplane supply", but if that was gone,
>
> then a lot of other things would be dead. Maybe the supply is noisy?
>
>
>
> Matt Roberds
The backplane carries grounded digital com RST/SRQ and data lines as well as the signals of floating analog circuitry.
The multifunction module used at the time of the fault employed the grounded digital bus only. There were no connections to the floating DAC outputs common to the ADC and main controller. I think this means that I can rule out damage in the floating circuitry....which would be nice.
The I/O controller (U307 - PC16550) isn't socketed, but the microcontroller running the show (U305)is.
RL
legg
Feb 3, 2014, 7:14:58 PM2/3/14
to
On Mon, 3 Feb 2014 07:23:20 -0800 (PST), RL <legg...@gmail.com>
wrote:
One of the Agilent guys suggested that I try to recalibrate the 34907
module. After some curious, repeated rejections, the 34970 finally
accepted a calibration change on the previously un-used and
unconnected DAC output, channel 4. This was outputing 10.6 when asked
for 10.0. (Wouldn't accept a zero offset change though, no matter what
was done.)
This change retired the turn-on error associated with the card and
suggests that it doesn't matter WHAT was connected at the time of the
failure - ANYTHING is fair game.
I'm going to dust off an old usb-gpib adapter (if I can find the damn
thing) to see if the logger still speaks gpibish. If twiddling
registers can regain distantly-associated functionality, it would be a
cheap fix, but I'm clutching at straws here.
Repair and/or replace is two weeks.....(I'm not completely dense - a
replacement/back-up is already en route)
RL
wrote:
module. After some curious, repeated rejections, the 34970 finally
accepted a calibration change on the previously un-used and
unconnected DAC output, channel 4. This was outputing 10.6 when asked
for 10.0. (Wouldn't accept a zero offset change though, no matter what
was done.)
This change retired the turn-on error associated with the card and
suggests that it doesn't matter WHAT was connected at the time of the
failure - ANYTHING is fair game.
I'm going to dust off an old usb-gpib adapter (if I can find the damn
thing) to see if the logger still speaks gpibish. If twiddling
registers can regain distantly-associated functionality, it would be a
cheap fix, but I'm clutching at straws here.
Repair and/or replace is two weeks.....(I'm not completely dense - a
replacement/back-up is already en route)
RL
legg
Feb 6, 2014, 6:55:15 PM2/6/14
to
up to the flashing front panel and beeping. It's a constant power-
on-reset.
This module was responsible solely for monitoring LV ground-referenced
signals ported by a 3ph wattmeter.
Will repeat the symptom any time, by itself. Without visible damage,
it's shelved till...
RL
mrob...@att.net
Feb 9, 2014, 3:13:25 AM2/9/14
to
legg <le...@nospam.magma.ca> wrote:
> The 34901A module present in slot one during the 'event' has owned
> up to the flashing front panel and beeping. It's a constant power-
> on-reset.
Does removing that module also fix the serial port?
> The 34901A module present in slot one during the 'event' has owned
> up to the flashing front panel and beeping. It's a constant power-
> on-reset.
> This module was responsible solely for monitoring LV ground-referenced
> signals ported by a 3ph wattmeter.
your average circa-1995 PC parallel port doesn't really like having
6.3 V AC fed into it. By experiment. :)
> Will repeat the symptom any time, by itself. Without visible damage,
> it's shelved till...
that will solve my problem in the back of a cabinet, only to later
discover that it was back there because it was broken...
Matt Roberds
legg...@gmail.com
Feb 10, 2014, 8:01:21 AM2/10/14
to
On Sunday, 9 February 2014 03:13:25 UTC-5, mrob...@att.net wrote:
The measurement(s) it was making involved reading the monitoring pins of another instrument - LV outputs of current/voltage transformers and RMS-DC converters.
There is NO issue with the cheap commodity serial port interface on the connecting PC; just the interface sitting in the high-tech, application-specific marvel of modern automated measurement and instrumentation.
You wear these things around your 'interneck' till they rot off, to teach you some kind of a lesson. I have a strong immunity to bad smells, so it's no real hardship.
There are no discrete parts damaged or misbehaving. No basic digital parts outputting what they shouldn't. Power application shows no abnormal supply loading as various sections are enabled/disabled manually. Compares to known working good units favorably in most respects. There's only that great un-socketed 40 pin PIC left. All it's supposed to do is count, remember it's name and do what it's told.
But it's the serial port in the main unit that needs reviving. When the replacement shows up, I guess this will go off to whatever sub-contracted back room they send these things, to get their PICS de-scrambled.
RL
> legg wrote:
>
> > The 34901A module present in slot one during the 'event' has owned
> > up to the flashing front panel and beeping. It's a constant power-
> > on-reset.
>
> Does removing that module also fix the serial port?
>
No. Serial port is unresponsive regardless of interface modules present.
>
> > The 34901A module present in slot one during the 'event' has owned
> > up to the flashing front panel and beeping. It's a constant power-
> > on-reset.
>
> Does removing that module also fix the serial port?
>
>
> > This module was responsible solely for monitoring LV ground-referenced
> > signals ported by a 3ph wattmeter.
>
> Maybe it got a little more AC than it wanted. I once discovered that
> your average circa-1995 PC parallel port doesn't really like having
> 6.3 V AC fed into it. By experiment. :)
>
This module is a relay switch matrix that directs two contacts to inputs of a 6.5digit multimeter, isolated from ground and the serial port to some hundreds of volts (CAT1-300V spec).
> > This module was responsible solely for monitoring LV ground-referenced
> > signals ported by a 3ph wattmeter.
>
> Maybe it got a little more AC than it wanted. I once discovered that
> your average circa-1995 PC parallel port doesn't really like having
> 6.3 V AC fed into it. By experiment. :)
>
The measurement(s) it was making involved reading the monitoring pins of another instrument - LV outputs of current/voltage transformers and RMS-DC converters.
There is NO issue with the cheap commodity serial port interface on the connecting PC; just the interface sitting in the high-tech, application-specific marvel of modern automated measurement and instrumentation.
> > Will repeat the symptom any time, by itself. Without visible damage,
> > it's shelved till...
>
> Put a note on it. I've been bitten more than once by finding an item
> that will solve my problem in the back of a cabinet, only to later
> discover that it was back there because it was broken...
>
Cabinets? Luxury! The reference to shelves here was only speaking figuratively.
> > it's shelved till...
>
> Put a note on it. I've been bitten more than once by finding an item
> that will solve my problem in the back of a cabinet, only to later
> discover that it was back there because it was broken...
>
You wear these things around your 'interneck' till they rot off, to teach you some kind of a lesson. I have a strong immunity to bad smells, so it's no real hardship.
There are no discrete parts damaged or misbehaving. No basic digital parts outputting what they shouldn't. Power application shows no abnormal supply loading as various sections are enabled/disabled manually. Compares to known working good units favorably in most respects. There's only that great un-socketed 40 pin PIC left. All it's supposed to do is count, remember it's name and do what it's told.
But it's the serial port in the main unit that needs reviving. When the replacement shows up, I guess this will go off to whatever sub-contracted back room they send these things, to get their PICS de-scrambled.
RL
0 new messages