I've acquired a faulty 3458A to have fun with, here's what I have done so far, looking for advice on the next step.
On power up I was getting Error 202, Hardware failure, Slave Test AC board.
So, on the AC board 125mA fuse F701 was blown, so I replaced it and Q701 (2N4401) as a precaution, and confirmed the +15v and +14v are now working, as is +/-18v, +5v and -17v.
With that fixed there is now a new error, 202, Hardware failure, Slave Test: Convergence error.
So, I ran separate ACAL and got the following:
ACAL DCV = Ok
ACAL OHMS = Ok
ACAL AC = 209 Timeout Unable To Read A/D 198 & 101 Calibration Error.
I notice that under ACAL AC it seems to error immediately after TEST AC RATIO 1 is displayed.
So, looks like my AC board still has issues, any advice on where to look next before I drag out the scope etc......:-)
Usual suspect U404 EL2039CN maybe?
PS. I have a Part 1 YT video with my works so far, publishing next week.
More info:
Looking at the A2 board thinking it's an issue with the track/hold and multiplex into A/D section............I am getting a pulsing output from U404 EL2039 (JM402) when running ACAL AC, and I'm getting a signal right through to the output of U902 LF411 but I am getting nothing on TP902, the HOLD input (which comes from the A3 board).
Could be that my error is occuring before TP902 HOLD should toggle.......but not sure.
PS. The EL2039 & EL2018 parts appear to be working ok.
I would check and replace Q90X bipolar transistors, had this issue in Agilent 3458A HFL repair:
Even had video of my process and results: https://xdevs.com/fix/hp3458h…
Ok, I haven't had a chance to delve into this fault again.....but I did try to confirm if the U180 had an drift issues.
On power up I had to use TARM AUTO to enable the display (blank data due to the error I guess).
Ran for just under 8 hours from a voltage source (1Vdc) and a reasonably constant workshop temp.
Once warmed up and the aircon settled the Max-Min is less than 10uV............so at a guess at this stage the U180 would appear to be good.
You don't need anything connected to meter to verify U180 drift. Just follow xDevs X18 procedure: https://xdevs.com/guide/life_…
Should be pretty simple to implement this into next WinGPIB too ;). Measuring 1V range doesn't tell clear picture because this range using additional amplifiers and circuits on A1, unlike core 12V range which is simplest signalpath to ADC.
Also you'll need to monitor meter drift for multiple weeks at least, as meters known to "settle" over long time. Then running analysis on CAL? 72 constant and TEMP? data will tell you all you need to know about U180 stability.
Yep, I have a spreadsheet I use for CAL72?/TEMP etc that I used for my last 3458A, I just wanted to spot check it whilst the unit is still not working properly.
Great idea on modding WinGPIB though to include CAL72?/TEMP, including storing results etc!.........deffo added to the list!
Beta version on it's way.......sample data pulled from my last 3458A spreadsheet.
Data is stored in a CSV file.
User can read from 3458A via GPIB or enter CAL? 72 and TEMP data manually and add.
Nice! You can also add constants 2 and 1 into your sampler, since over long time meters can be readjusted with external 10kΩ and 10 V standards, making a shift in 72 constant that will need to be mathematically corrected.
I got my 3458A powering up with no errors.
I identified that the U180 -12Vref and +12Vref were not matched enough, so I biased the -12Vref using a PDVS2mini as a test, just by 20mV and the unit powers up with no errors.
Why it passes ACAL DCV, OHMS but not ACV I don't know!
So, probably the resistors inside the U180 have drifted.
For fun, I'm going to try and come up with a more permanent fix to bias the -12Vref by 20mV and see how the meter runs like that.
ACAL AC passes when I bias ZR_LO2 via +5v through a 1kohm resistor.
Could you do me a favour Illya?...........on a good 3458A, tell me the resistance you get between these two nodes on the A1 board as shown, power off.
0.0ohms, 0.5ohms........?
Might need to wait a bit, I don't have good 3458A that is not measuring something fully assembled :).
But I do need to replace A1 PCBA in the latest 3458FF unit to cure the worse than I like tempco and resistance drift, so maybe next weekend will do that.
I wrote little tool for 3458A today, to practice in my first GUI app: https://github.com/tin-/3458a…
Doesn't do anything special yet, just mostly to do quick checks on 3458A's and log results.
Ian, I played around with WinGPIB and it worked pretty good.
Few ideas and feedback from me:
Would be great to host .net 4.8 framework offline installer next to your tool, as I needed it to install, otherwise WinGPIB didn't work.
If you can add "run ACAL DCV" adjustment button with timer (ACAL takes 145 seconds) on drift tab page, that would be handy to use. Obviously add readout out of constants after adjustment done too, so new entry into history gets added upon completion.
As bonus feature , if you add period time field and checkbox "repeat ACAL DCV" for continuous monitoring 3458 drift, that would be great help for owners.
I've implemented this function in simple python script many years ago and it runs ACAL adjustments on my 3458 stack every hour with constants storage into history file, when I don't have them in active use (my meters never off unless power outage or lab service once in few years).
Also if there would be function to write back calibration data into 3458, that'd help, saving time messing with chip programmer. You can hide it under "expert mode" or "unlock password I_do_want_Write_calrom_and_accept_risks to avoid random newcomer erasing their calrom :-)
Illya, taking on board your comments.....will look into them.
I think the 3458A Cal Write will be the first, my CalRam/Settings ram are all backed up so no worries testing code right now. Will need to think about how to help newbies avoid a very expensive "click".
Make newbies to enter manually (with disabled copy-paste) "I-NeEd-to-oveRWritE-mY-CaLR0M" string in popup window when they click "Write CalROM" button. That should eliminate 99.99999% of possible mistakes. And yes, that 0 is zero. I have a running test 3458A if you want independent testing too. I needs readjustment after replaced A1 anyway.
Nice idea about manually entering text....I'll add something along those lines, but for now this is what I have. I should have a working version today...:-)
It works!
I wrote a couple of different .bin files to my 3458A and confirmed DCV readings changed.....then wrote my good .bin and all is good.
Download latest WinGPIB, just install WinGPIB over the top of itself, it will update fine and keep your existing settings. https://www.ianjohnston.com/W…
As we all know, the HP 3458A's protected CalRAM cannot be written directly using the normal MWRITE command.
Instead, WinGPIB uploads the complete calibration image into the meter's SETTINGS RAM and a small 68000 machine-code routine into working RAM. This routine uses a Level-7 Non-Maskable Interrupt (NMI) to safely copy the calibration data into the protected CalRAM. Before performing a full write, an unchanged test write verifies that the NMI write mechanism is working correctly, after which all 2048 bytes are read back and verified against the source file.
Level-7 is the highest priority interrupt and is non-maskable (NMI). It cannot be ignored or disabled by software and immediately interrupts whatever the CPU is doing.
The Level-7 NMI write mechanism differs slightly between HP 3458A firmware revisions because the firmware stores the required callback pointers and control variables at different memory addresses. WinGPIB automatically queries the instrument firmware using REV? and selects the correct address set for firmware revisions 2 through 9. If an unsupported firmware revision is detected, the write process is aborted to prevent any possibility of corrupting the CalRAM.
@bbs_tin said:
Awesome. One question tho, why have separate verify button, and not just run verify automatically after writing is done?
As it is the first version I wanted to keep the test write, full write and verify separated. Once I hear it is working for people then I can integrate better.
Added ACAL DCV button, user should wait till completed before doing a manual read.
Added AUTO LOG feature: checkbox to enable and duration textbox (0.2hrs min and up). This allows automated read's at specific intervals. ACAL DCV is performed before each read. All stats is updated. Status will indicated time of next read as well as indicating if ACAL DCV is running.
Tip:
If you want to run the AUTO LOG feature on several 3458A's at the same time just open multiple copies of WinGPIB.
I've acquired a faulty 3458A to have fun with, here's what I have done so far, looking for advice on the next step.
On power up I was getting Error 202, Hardware failure, Slave Test AC board.
So, on the AC board 125mA fuse F701 was blown, so I replaced it and Q701 (2N4401) as a precaution, and confirmed the +15v and +14v are now working, as is +/-18v, +5v and -17v.
With that fixed there is now a new error, 202, Hardware failure, Slave Test: Convergence error.
So, I ran separate ACAL and got the following:
ACAL DCV = Ok
ACAL OHMS = Ok
ACAL AC = 209 Timeout Unable To Read A/D 198 & 101 Calibration Error.
I notice that under ACAL AC it seems to error immediately after TEST AC RATIO 1 is displayed.
So, looks like my AC board still has issues, any advice on where to look next before I drag out the scope etc......:-)
Usual suspect U404 EL2039CN maybe?
PS. I have a Part 1 YT video with my works so far, publishing next week.
AC board thermal image:
Ian.
More info:
Looking at the A2 board thinking it's an issue with the track/hold and multiplex into A/D section............I am getting a pulsing output from U404 EL2039 (JM402) when running ACAL AC, and I'm getting a signal right through to the output of U902 LF411 but I am getting nothing on TP902, the HOLD input (which comes from the A3 board).
Could be that my error is occuring before TP902 HOLD should toggle.......but not sure.
PS. The EL2039 & EL2018 parts appear to be working ok.
I would check and replace Q90X bipolar transistors, had this issue in Agilent 3458A HFL repair:
Even had video of my process and results: https://xdevs.com/fix/hp3458h…
Ok, I haven't had a chance to delve into this fault again.....but I did try to confirm if the U180 had an drift issues.
On power up I had to use TARM AUTO to enable the display (blank data due to the error I guess).
Ran for just under 8 hours from a voltage source (1Vdc) and a reasonably constant workshop temp.
Once warmed up and the aircon settled the Max-Min is less than 10uV............so at a guess at this stage the U180 would appear to be good.
You don't need anything connected to meter to verify U180 drift. Just follow xDevs X18 procedure: https://xdevs.com/guide/life_…
Should be pretty simple to implement this into next WinGPIB too ;). Measuring 1V range doesn't tell clear picture because this range using additional amplifiers and circuits on A1, unlike core 12V range which is simplest signalpath to ADC.
Also you'll need to monitor meter drift for multiple weeks at least, as meters known to "settle" over long time. Then running analysis on CAL? 72 constant and TEMP? data will tell you all you need to know about U180 stability.
Yep, I have a spreadsheet I use for CAL72?/TEMP etc that I used for my last 3458A, I just wanted to spot check it whilst the unit is still not working properly.
Great idea on modding WinGPIB though to include CAL72?/TEMP, including storing results etc!.........deffo added to the list!
Beta version on it's way.......sample data pulled from my last 3458A spreadsheet.
Data is stored in a CSV file.
User can read from 3458A via GPIB or enter CAL? 72 and TEMP data manually and add.
Update: It's working.
Nice! You can also add constants 2 and 1 into your sampler, since over long time meters can be readjusted with external 10kΩ and 10 V standards, making a shift in 72 constant that will need to be mathematically corrected.
Done.
I got my 3458A powering up with no errors.
I identified that the U180 -12Vref and +12Vref were not matched enough, so I biased the -12Vref using a PDVS2mini as a test, just by 20mV and the unit powers up with no errors.
Why it passes ACAL DCV, OHMS but not ACV I don't know!
So, probably the resistors inside the U180 have drifted.
For fun, I'm going to try and come up with a more permanent fix to bias the -12Vref by 20mV and see how the meter runs like that.
Ian.
Most likely you got also A2 ACV faulty.
ACAL AC passes when I bias ZR_LO2 via +5v through a 1kohm resistor.
Could you do me a favour Illya?...........on a good 3458A, tell me the resistance you get between these two nodes on the A1 board as shown, power off.
0.0ohms, 0.5ohms........?
Might need to wait a bit, I don't have good 3458A that is not measuring something fully assembled :).
But I do need to replace A1 PCBA in the latest 3458FF unit to cure the worse than I like tempco and resistance drift, so maybe next weekend will do that.
No worries Illya, I got the info elsewhere.
Btw, here's my faulty 3458A, I've been recording drift, also making mods to WinGPIB adding more info in the wee stats panel.
Am just about to build up the latest NU180 U180 replacement, will be fun to try it.
Oh yea, that is drifter alright :-)
Let me know of your NU180 results, I might join the party in future with own pcb design for such.
I wrote little tool for 3458A today, to practice in my first GUI app: https://github.com/tin-/3458a…
Doesn't do anything special yet, just mostly to do quick checks on 3458A's and log results.
Ian, I played around with WinGPIB and it worked pretty good.
Few ideas and feedback from me:
I've implemented this function in simple python script many years ago and it runs ACAL adjustments on my 3458 stack every hour with constants storage into history file, when I don't have them in active use (my meters never off unless power outage or lab service once in few years).
Also if there would be function to write back calibration data into 3458, that'd help, saving time messing with chip programmer. You can hide it under "expert mode" or "unlock password I_do_want_Write_calrom_and_accept_risks to avoid random newcomer erasing their calrom :-)
Great videos Ian, following along your journey.
Thanks
Thanks guys.
Illya, taking on board your comments.....will look into them.
I think the 3458A Cal Write will be the first, my CalRam/Settings ram are all backed up so no worries testing code right now. Will need to think about how to help newbies avoid a very expensive "click".
Ian.
Make newbies to enter manually (with disabled copy-paste) "I-NeEd-to-oveRWritE-mY-CaLR0M" string in popup window when they click "Write CalROM" button. That should eliminate 99.99999% of possible mistakes. And yes, that 0 is zero. I have a running test 3458A if you want independent testing too. I needs readjustment after replaced A1 anyway.
Nice idea about manually entering text....I'll add something along those lines, but for now this is what I have. I should have a working version today...:-)
It works!
I wrote a couple of different .bin files to my 3458A and confirmed DCV readings changed.....then wrote my good .bin and all is good.
Download latest WinGPIB, just install WinGPIB over the top of itself, it will update fine and keep your existing settings.
https://www.ianjohnston.com/W…
As we all know, the HP 3458A's protected CalRAM cannot be written directly using the normal MWRITE command.
Instead, WinGPIB uploads the complete calibration image into the meter's SETTINGS RAM and a small 68000 machine-code routine into working RAM. This routine uses a Level-7 Non-Maskable Interrupt (NMI) to safely copy the calibration data into the protected CalRAM. Before performing a full write, an unchanged test write verifies that the NMI write mechanism is working correctly, after which all 2048 bytes are read back and verified against the source file.
Level-7 is the highest priority interrupt and is non-maskable (NMI). It cannot be ignored or disabled by software and immediately interrupts whatever the CPU is doing.
The Level-7 NMI write mechanism differs slightly between HP 3458A firmware revisions because the firmware stores the required callback pointers and control variables at different memory addresses. WinGPIB automatically queries the instrument firmware using REV? and selects the correct address set for firmware revisions 2 through 9. If an unsupported firmware revision is detected, the write process is aborted to prevent any possibility of corrupting the CalRAM.
Ian.
Awesome. One question tho, why have separate verify button, and not just run verify automatically after writing is done?
As it is the first version I wanted to keep the test write, full write and verify separated. Once I hear it is working for people then I can integrate better.
Did it work for you?
Ian.
Published V4.115.
3458A Drift tab:
Tip:
If you want to run the AUTO LOG feature on several 3458A's at the same time just open multiple copies of WinGPIB.
Ian.