EEVblog Electronics Community Forum
Electronics => Repair => Topic started by: tomn on April 23, 2024, 11:39:14 pm
-
I have a Keithley 2400 C10 with the following issue:
- The unit powers up, the display works, and it can make measurements when commanded over RS-232, so the ROM self-test passes and the analogue section works.
- After pressing some buttons on the front-panel, it becomes unresponsive – buttons do nothing, the display does not change, and it no longer responds to commands over RS-232.
- Some buttons cause it to crash instantly (e.g. on/off and front/back), while others take a few presses (e.g. edit crashes on the third press), and some don’t crash at all (e.g. digits, menu). The behaviour is always the same.
I’ve been working on this for a few days and haven’t really got anywhere.
Here’s what i’ve tested so far:
- Power supplies seem fine. I’ve checked the incoming 12V and 5V supplies, and all analogue supplies.
- Reset for the display and CPU seems fine – held low for ~250ms after 5V is stable.
- It behaves exactly the same with the analogue board removed.
- Communication between the display and main board seems OK. I can see communication in both directions, and when it’s crashed I can see that the display board still sends key-presses. I can’t see the “Pulse train every 1 ms.” from the main board to the display board listed in the service manual, but this seems unlikely on a 9600 baud serial line? I’ve attached a trace of the display rx, tx and reset lines during startup with two button presses before it crashes. Does this look right?
- Looking at the activity on the CPU external bus, it is definitely still running while crashed, but is probably in a tight loop (repeating patterns on address lines).
- Exactly the same issue occurs when simulating key-presses by sending SYST:KEY commands over RS-232.
Anyone got any bright ideas, or things to test? I’d like to avoid having to disassemble the code and work out where it’s crashed with a logic analyser, but that feels like where this is heading…
If I get it working, I’d be interested in a source for a new button pad – this one has always needed a lot of force and cleaning didn’t seem to help.
Cheers!
-
did you try the steps as outlined in chapter "Battery Replacement" of the service manual, especially the ":SYST:MEM:INIT" sequence?
also, i wouldn't trust the EEPROM sockets on the digital board too much, you could pull and give them a "deoxit & re-seat" treatment.
as for the key pads, a key pad repair kit for tv remotes will do the trick. iirc, the stuff i used was "gumki do pilotów" by TermoPasty.pl from a*n. i glued the new pads right on top of the button stakes without even removing the old pads, using a drop of high temperature silicone (instead of the silicone that was supplied in the kit) and letting them cure for 24 hrs. button feel is slightly "stiffer" now, but key responsiveness works like a charm since 3 years now.
edit: forgot to mention: you may want to check the electrolytic caps :horse:
-
Thanks for the reply.
did you try the steps as outlined in chapter "Battery Replacement" of the service manual, especially the ":SYST:MEM:INIT" sequence?
Not yet, I'll try today. I'm a bit wary of losing RS-232 access (still need to get a GPIB adapter), but I think SYST:MEM:INIT should keep the settings the same...
also, i wouldn't trust the EEPROM sockets on the digital board too much, you could pull and give them a "deoxit & re-seat" treatment.
Yeah, I forgot to mention, i did re-seat them. As the self-test always passes i doubt this is the problem, but i can give them another go.
as for the key pads, a key pad repair kit for tv remotes will do the trick. iirc, the stuff i used was "gumki do pilotów" by TermoPasty.pl from a*n. i glued the new pads right on top of the button stakes without even removing the old pads, using a drop of high temperature silicone (instead of the silicone that was supplied in the kit) and letting them cure for 24 hrs. button feel is slightly "stiffer" now, but key responsiveness works like a charm since 3 years now.
Ah, i did not know this was a thing, thanks!
edit: forgot to mention: you may want to check the electrolytic caps :horse:
There's only one or two that could be a problem for this (on the digital 5v supply). They seems fine, and the supply seems quiet. Maybe if I get really desperate I'll consider making an offering :)
-
Unfortunately SYST:MEM:INIT didn't make any difference.
Looking at the CPU32 manual, it seems quite possible to build a debugger for it. It would be nice to have a less valuable target to develop against, though.
-
If you have a sticky front panel button, such that it sticks 'on' after being pressed, that would cause other front panel buttons to become inoperative. Perhaps unlikely to cause the serial comms to stop.
Other than that, I would say close visual inspection of everything, re-seat all connectors, verify firmware checksum.
-
If you have a sticky front panel button, such that it sticks 'on' after being pressed, that would cause other front panel buttons to become inoperative. Perhaps unlikely to cause the serial comms to stop.
Good idea, thanks. I tested all the contacts (none are stuck), and all keys produce a unique scan-code on the serial port, so it seems unlikely. It could be that the key-up message (0x40) is actually wrong, but I don't have anything to compare it to. Edit: actually, i can get into the keyboard self-test, and it all works properly. It's probably nothing to do with the keypad/display.
Other than that, I would say close visual inspection of everything, re-seat all connectors, verify firmware checksum.
Yep, already done unfortunately. I'll have to get a programmer for the ROMs, but the ROM self-test passes so again it seems unlikely.