6624a repair - Page 1
Forum section: electronics / repair

author: drforbin
author_rank: Regular Contributor
timestamp: February 20, 2017, 03:43:42 pm
content: Hi. I am in the middle of repairing a 6624a and was wondering if you all could give me a few pointers?One of the channels were bad and I was getting a dac cc error. I tracked this down to the cc DAC 314 which I replaced.This fixed the problem. But a bigger problem is I cannot get the thing to calibrate the over voltage constants.The over voltage setting can be set to 23 volts for example and OV will trip at 1 volts.This is on another channel. The funny thing is the OV condition follows the serial lines when they are switched.Also it appears that the gpib board is NOT programming the OV dac linearly. All this to me sounds like a bad gpib board.What do you think.Any ideas would help...thank you.

author: pelule
author_rank: Frequent Contributor
timestamp: February 20, 2017, 07:51:20 pm
content: Hi drforbin,it seems you have a mixed problem, but it is not clear to me, your descriptions of problem is confusing.Thus you may follow a more structures troubleshooting process (as it is described in the 6624A SM). Or you risk to get lost (thats my personal experiance).The 6624A has 2 sets of 2 channels - 2x HighVolt channels and 2 LowVolt channels.(see for details:https://www.eevblog.com/forum/repair/(fixed)-hpagilent-6624a-psu-(the-tank)-hw-error-ch3/msg989667/#msg989667FIRST STEPfind a working channel of each type (as your reference), this may need some measurements and testing (see performance test).SECOND STEPAt the GPIB board you can toggle the both similar channels with each other (LV with LV or HV with HV) to check if an error moves (problem @ GPIB) or remains at the same channel (problem @ channel).DO NOT change a HV with a LV channel - you will get wrong results as the programming values do not match.THIRD STEP (depend on moving/not moving) error.If the error remains (@ channel) ==> follow step by step the troubleshooting process (by comparing the good and the bad channel (that's easier over the several board revisions).If the error moves (@GPIB) ==> first check the most simples potential causes for the error:bad cable, bad connectors, bad soldering at the connectors, than start to check the electronics.For example toggle the two serial cables to check if the error changes with the cables or remains at the same channel..... and so on.BRPeLuLe

author: drforbin
author_rank: Regular Contributor
timestamp: February 20, 2017, 08:19:41 pm
content: Ok, first thanxs for your reply.That just what I did.The OV dac sets the level for trip by creating a 0 to -10 volt from U314. Firstly I checked that this was roughly linear for the falling board. it was not! it was roughly linear from 0 to about 20 volts, but at some point from 20 to 23 it dips to -2 volts.This obviously is the cause of the OV tripping when it should not. I next toggled the serial cables to see if the nonlinearity followed the cable. It did, Which suggests that either the board itself is doing something strange during (OVCAL) and causing the gpib to create bad constant maps or gpib itself is bad. What do you think?Anyone else?

author: pelule
author_rank: Frequent Contributor
timestamp: February 20, 2017, 09:15:07 pm
content: Missing some more information to judge and to make further recommendations:which channel # is defekt (ch1, ch2, ch3, ch4) ?which channel(s) are ok?

author: drforbin
author_rank: Regular Contributor
timestamp: February 20, 2017, 09:29:03 pm
content: channel 1 is the problem. I have a gpib interface fyi

author: pelule
author_rank: Frequent Contributor
timestamp: February 20, 2017, 10:09:43 pm
content: Sorry for asking many (maybe stupid) questions.But I need to understand your problem, your so far testings & results and the available equipment for a sufficiant remote support.Do you have- a multimeter?(I bet you have just want to be sure about)- an oscilloscope (2 ch)?(I bet you have just want to be sure about)- an electronic DC load?(would help verify some points like the limtit settings)- the 6624A S&M manual?(would help as a reference for further guidance)If ch1 (40W LowVolt) is the problem- so ch2 (40W LowVolt) works correct (including OVP, OCP and current limits)?(you have acces to a working reference)- if you changing the serial connection to the GPIB between ch1 and ch2 the problem remains at ch1 (ch2 still operates as specified)?(so no issue with the GPIB board, just to concentrate on the ch1 board)- supply voltages at ch1 are all within the specified limits and don't have high ripply?(no site effect of a supply issue)- all test points and refence voltages at ch1 are all within the specified limits and don't have high ripply?(no site effect of a reference issue)QuoteIs my understaning correct: you have the equipment to remote control the 6624A via the GPIB interface(all testings can & should be done using the front panel controls, except the final GPIB command processing tests)BRPeLuLe

author: drforbin
author_rank: Regular Contributor
timestamp: February 20, 2017, 11:29:32 pm
content: Hi..thanks again.I'm sorry if I am not too clear I'll try better.I have an Agilent U1272a dmm,a tds540 4 channel 500Mhz scope and a tds520 500Mhz 2 channel scope, both I repaired.I donot have a DC load.I have the manual.I have gone threw all the flow charts. It's a very strange problem.The fault DOES follow the switching of serial lines.I have tried to calibrate it several times using gpib interface and procedure in operating manual and the OV problem persists.NOTE...It passes all self tests.

author: pelule
author_rank: Frequent Contributor
timestamp: February 20, 2017, 11:59:48 pm
content: It may a stupid question: did you connec the sense lines?QuoteI am afraid, I have still not understand correct (sorry, but may a language issue, I am not natural english speaking).Say, the problem is as at CH1 normally (if CH1 is connected to GPIB board CH1) and you connect CH1 to GPIB board CH2 - then the error is at CH2 (error has moved)?This would mean the issue is at the GPIB board, not at the CH1 board.QuoteThat just tells, the CH board detetcs no problem with the selftest. Does not mean their is no issue.

author: drforbin
author_rank: Regular Contributor
timestamp: February 21, 2017, 12:11:53 am
content: Yes. Sense lines are connected.Exactly. The problem moves with the change of serial lines indicating to me a problem with gpib board.

author: drforbin
author_rank: Regular Contributor
timestamp: February 21, 2017, 05:02:46 pm
content: Ok, I have more information for you.I ran a few more tests and these are the results.This is a most interesting problem.Firstly I connected a DMM to pin 19 U314 (the OV dac) and yes at a setting of 0 OV the dav output is close to zero,but at max of ~23 the dac is set to -.30 (it should be -10). If I switch the serial line to channel 2,channel 2's dac exhibits the same behavior. Sounds like the GPIB right? wrong.Firstly, If I send the instrument a model command (resetting all constants to default) the problem goes away,but the device is uncalibrated.So this is the interesting point.If I calibrate channel 1 on board 1 I get this erroneous behavior. If calibrate channel 1 on board 2 it calibrates fine,then channel 2 which is own connected to board 1 does not calibrate properly.So it's board ONE.Also, I placed a DMM with a min/max logging function on the V+V- outputs during calibration and board two maxes at 18.4v(I think the DMM is too slow to catch the real max which is about 19.45) but on channel 1 the max is about .88 Volts.Note, I cannot set volts on board 1 and it works except for the OV problem, so it is putting out power.So it seems the OVCAL function runs the board thew some kind of cycle which board one is not performing.But as I said it does produce voltage and is pretty accurate but the problem is OV.ANY IDEAS?

author: pelule
author_rank: Frequent Contributor
timestamp: February 21, 2017, 08:34:55 pm
content: PLEASE keep in mind, you have 2 EQUAL channels, one operates with GPIB correctly (your reference) one dooesn't (your DUT).You may measure each test point at both boards to compare GOOD AND BAD (the fastes way to find an error).But let us do the testing a bit more structured to prevent confusions or searching in wrong directions.First (to have same doc to reference to), I have the "HP 6621A/22A/23A/24A/27A Service Manual (5957-6379) 2001-09 Ed2.Please confirm, you have the same DOC.Please also confirm, you have set the conditions using the front panel (and not via the GPIB interface).Second - yes I also target to the GPIB board error, but we need some final test to confirm that.The cross-cable test.connect ch1 and ch2 (so the error is let say, at ch1). Next toggle the serial cables at the gpib board AND toggle the cable at the output boards (im principle same connection, but with the cables exchanged).Has the error moved?YES, has moved - it seems to be a cable problem (measure the cable)NO, not moved - it may a connector problem or a GPIB board problem. So now again toggle the cable at the output boards)(the boards a changed out of the view of the GPIB board now).Has the error moved?YES - most probably a GPIB board problemNO - it seems to be a connector problem problem (look in detail).If confirmed, its a GPIB board problem - you may now follow the "Troubleshooting procedures for the GPIB board", given in the flow chart of Figure 4-7 (page 4-17.../ PDF page 63).Report me your findings (at which CHECk at the flow chart you stopped, please also the page of the PDF).

author: drforbin
author_rank: Regular Contributor
timestamp: February 21, 2017, 08:54:02 pm
content: Hi.. Here are tests I ran using tds540 scope.These are traces taken during the execution of the 'OVCAL' command.notice ch 3 & 4 are Identical. ch 2 which works it's trace is about 2 secs in duration.Notice channel 1 (faulting channel.) the duration is about 1 ms.It as if the tries to ramp up the volts and faults back down to 0.But the supply works when not in calibration.https://drive.google.com/open?id=0B1c_4f0VAtfULTFxYXpiS0lSS1khttps://drive.google.com/open?id=0B1c_4f0VAtfUTjBaVVFETDdDWUkhttps://drive.google.com/open?id=0B1c_4f0VAtfUSnZHUkRWa2VPb28https://drive.google.com/open?id=0B1c_4f0VAtfUNEtTdnBfV0NBazQ

author: drforbin
author_rank: Regular Contributor
timestamp: March 27, 2017, 04:32:38 am
content: I fixed it. should anyone need any help on a related power supply please let me know.

author: alm
author_rank: Super Contributor
timestamp: March 27, 2017, 11:47:20 am
content: How about just posting how you fixed it? Then anyone finding this thread searching for information about the Agilent 6624A two years from now can read it, even if you have already forgotten the details or left the forum by then.In the past I have found it very frustrating to search for a problem, find someone describing the exact problem I was having, but the only response was 'Never mind, I have found a solution.' without describing said solution.

author: drforbin
author_rank: Regular Contributor
timestamp: March 27, 2017, 02:59:21 pm
content: I've ran across the same thing. Your right! I will post the solution.I'll do it tonight.

author: drforbin
author_rank: Regular Contributor
timestamp: March 28, 2017, 03:30:03 am
content: Basically it turned out to be U314. Which was the same chip as on the other. So it seems both boards had the same failure mode.What was happening is this. During calibration (OVCAL) overvoltage calibration the dac ramps the voltage to max.Please see the traces from the scope on previous posts. But the faulty DAC u314 was putting out about .5 volts to low.This control voltage sets the OV (over voltage) threshold. So rather then the voltage ramping to max and staying there while OVCAL was taking place. The voltage collapsed and caused a miss calibration.The original fault was easy to pick up on the other board because it (U314)was dead and the diagnostic routines picked it up. This one was just off. So the diagnostics did not find it. But it was off enough to really mess with the calibration OV constants .OK...any addition comments welcome and requested.Drforbin