Keithley 2000 - Adjusting single ranges possible?

[Alex Nikitin]

Finally I managed to totally mess up DCV ranges...
Tried to adjust manually and via GPIB, without success.
Any idea to set it back to "default values"?

It looks like I need a programmer to try to reanimate that K2000 via I²C.
Any suggestions for a good value programmer?

Could you describe how exactly did you manage to mess it up? A partial adjustment where you save the constants after a section is described in the service manual so should be perfectly valid (and I've done it a number of times on two meters without any problems).

Cheers

Alex

[z01z]

If you are looking for a programmer now, the chances are you didn't dump the contents of the EEPROM in the beginning.
Probably the best would be to try to calibrate the DCV and resistance ranges, as those the ones seem to be messed up.
As Alex mentioned, if what you did was normal procedure, this shouldn't have happened. This can well be a bug or you could've done something out of sequence.

As for the programmer, TL866 can be an option. It's cheap, so far worked fine with serial/parallel E(E)PROMS for me. For SMD packages there are a lot of adapters available. It all depends what do you want to use it for.
If you only want to program the 24LC16 in your meter, for a quick and dirty solution an arduino could also be used.

If it helps, I could print out the constants and dump the EEPROM in my meter. Please PM me if you need this.

[carl_lab]

Could you describe how exactly did you manage to mess it up? A partial adjustment where you save the constants after a section is described in the service manual so should be perfectly valid (and I've done it a number of times on two meters without any problems).

I used an existing Met/Cal (= Fluke calibration software) procedure, I modified before to skip specific cal steps.

First, I skipped DC adjustments step 1 to step 5 (closed circuit, open circuit, DC ranges 10V, -10V, 100V full scale) and tried to start with step 6 (1kOhm 4-wire).
Result: Met/Cal displayed error message:

E566: Error Infomation from instrument on board 1 at IEEE-488 address 16: -200,"Execution error"

Test was interrupted, so test steps to save cal constants were not executed.

Then I set back adjustment procedure to original, but skipped all cal steps except step 1, saving cal constants and resetting security code.
It worked without error message, but calibration was (way) out of spec for DCV and 2-wire-OHM.

Then I set back adjustment procedure to original again, but skipped all cal steps except step 1+2, saving cal constants and resetting security code.
It worked without error message, but calibration was out of spec as before.



(this image is a montage of 4 test result screenhots: Test 1 + Test 2 is unchanged K2000. Column "UUT indicated" is from TEST1 only, I did not copy the new values of the following tests)

Following attempts of using complete (original) Met/Cal adjustment procedure and complete manual adjustment ended without error message, but results were unchanged and out of spec as before. I tried 2 or 3 times - no changes. It seems to ignore new attempts of adjustment.

I think, now I understand, what Tin said:

Low-level calibration must be run completely in order listed in SM, otherwise meter will become upset and reject new calculated values.
That's why I couldn't calibrate 2001 before without actual 5700, even though I could run comprehensive cal for 2V/20V/20K/1Meg.

[carl_lab]

If you are looking for a programmer now, the chances are you didn't dump the contents of the EEPROM in the beginning.

Yes, I know. I should have read out EEPROM before starting this experiment...
But maybe I can copy data from a working K2000. I'm not sure how to read out and write back in-circuit.

Probably the best would be to try to calibrate the DCV and resistance ranges, as those the ones seem to be messed up.

That's what I tried. But no visible success (see results table above).

As Alex mentioned, if what you did was normal procedure, this shouldn't have happened. This can well be a bug or you could've done something out of sequence.

I really don't know, what went wrong.

If it helps, I could print out the constants and dump the EEPROM in my meter. Please PM me if you need this.

Thanks for your offer. Can you read out data in-circuit? How to set meter's CPU in hi-Z or inactive state?

[Muxr]

The worst case scenario is you find an affordable calibrator and have it calibrated by a real lab. Not sure how much it costs but shop around. You'll also get a calibrated piece of equipment out of it.

[Alex Nikitin]

Probably the best would be to try to calibrate the DCV and resistance ranges, as those the ones seem to be messed up.

That's what I tried. But no visible success (see results table above).

What are you using to supply the voltages required (+/-10V and 100V)?

Cheers

Alex

[carl_lab]

Our calibrator is Datron/Wavetek 4808.

[z01z]

But maybe I can copy data from a working K2000. I'm not sure how to read out and write back in-circuit.

It might worth a try, though there are other stuff stored there, apart from the calibration constants, the serial number for example. And who knows what else, hopefully only menu settings and nothing important.
Fixing the corrupted ranges could be another approach.

Thanks for your offer. Can you read out data in-circuit? How to set meter's CPU in hi-Z or inactive state?

Yes, it should be possible by keeping the uP in reset (it was discussed in some other topics). It did work for me but others had problem with this method. What worked for them I think was to remove the two PLCC EPROMs.

The EEPROM contents also depend on the firmware revision, so you should get a dump from the same fw as yours. It is displayed at power on and it's also printed in the answer for *IDN?.
I've a dump somewhere from the time when A05 revision was running and I can dump it again quite easily on the A19 currently in use. With more effort I could even install the fw version you have (if it's not the A20, which requires recalibration).

[carl_lab]

Fixing the corrupted ranges could be another approach.

Yes, of course. But you have to know memory adresses and how to recalculate checksum.

With more effort I could even install the fw version you have (if it's not the A20, which requires recalibration).

It's Rev. A13/A02.
Do not read out or do anything, before I got my ordered EEPROMs and tried to copy complete EEPROM from working K2000, maybe that that's enough to reanimate.

[z01z]

Well, I did try to install the A13 fw from TiN's site but the meter did not work with it (no comm link). Either downgrade like this doesn't work or that dump is not good. After putting back the A19 fw, the meter works again.
I can try again if you read the EPROM contents once you have your programmer, if needed.

I can reconfirm however, that with the EPROMs removed, the EEPROM can be read. It was done with a TL866 and an SO8 clip like this (which is just a random image from google search), though it's a tight fit.

[TiN]

Just hold CPU in RESET and you can just hook SDA/SCL/GND to TL866 to readout the calibration EEPROM data. That's how I did it on 2001/2002's.

It's strange (to say softly) to experiment with calibrations without saving original dump first. 
So we saw the described outcome coming. 

[hwj-d]

Yeah, shit happens, everytime, everywhere.
The truth is, without, we're mostly all not able to learn 2'nd half of bees dick. 

Just hold CPU in RESET and you can just hook SDA/SCL/GND to TL866 to readout the calibration EEPROM data.

 

[carl_lab]

Just hold CPU in RESET and you can just hook SDA/SCL/GND to TL866 to readout the calibration EEPROM data.
That's how I did it on 2001/2002's.

Thanks, for that information.

It's strange (to say softly) to experiment with calibrations without saving original dump first. 

You are right, but there's also a bad error handling by Keithley, I did not expect.
Trying to directly execute resistance adjustment via GPIB leads to an error message "Execution error" and break off. So far, so good.
But nevertheless cal constants were changed, and following adjustment attempts are ignored anyhow. (why?)
Normally, at the end of adjustment, you have to save cal constants explicitly by GPIB command (or front panel confirmation)...

PS: edited after finding hardware failure...

[Robert763]

We had a couple of 2000's at work and on their 2nd calibration (3years old) one came back from Keithley as BER due to being out of calibration on one or two ranges (can't remember the exact details).
This is, for me at least, unacceptable for an expensive current production meter and has put me off them for work or home use.

[carl_lab]

What is BER?

[Alex Nikitin]

What is BER?

 Beyond Economical Repair.

Cheers

Alex

[Andreas]

We had a couple of 2000's at work and on their 2nd calibration (3years old) one came back from Keithley as BER due to being out of calibration on one or two ranges (can't remember the exact details).
This is, for me at least, unacceptable for an expensive current production meter and has put me off them for work or home use.

Hello,

And why do you think this is different on other manufacturers?

Opening and closing a 1K$ DMM by a qualified technician, error finding
and exchanging one of both defect PCBs will cost more than a new unit produced in Malaysia.

with best regards

Andreas

[carl_lab]

Finally I found the cause of the problem when I tried to calibrate another DMM (34410A)...

One of our 4-wire calibration shorts Agilent 34171/34172 was faulty!



We have 4 of them so the problem wasn't consistent. Problem: One of the clamping nuts was loose, but the wire touched the bolt, so resistance wasn't consistent or temporary was complete interrupted.
I also did not know, this specific calibration short has clamped shorting wire, because one of our Agilent calibration shorts, i opened some day, has soldered wire, so I did not consider loose connections...

Error message was correct and not caused by previous failed calibration attempt.

Sorry for accusing Keithley of bad error handling!
I was wrong... 

At the end, complete adjustment using short with re-tightened clamping nuts, was successful - no need for reprogramming EEPROM. 

[chekhov]

Let's revive this thread a bit.

I have K2010 that has sick or 'sick' 1M-100M ranges (I've looked in reversed schematics of K2000 and partial of K2010 and it doesn't seem the problem is in TF-245 or switches or anything else, at least not for now).
Instead of 1M is shows smth like 1.00434... on 1M and 10M ranges, which is more than 4300ppm off.
That may seem to be 'fine/enough' for Australia (but unacceptable for me) on 10M range that has 400 ppm/year spec and meter wasn't calibrated for 9 years.
But not for 1M range - 70 ppm/year let's say.

So, I decided to try adjusting it to something. And similar to topicstarter I bumped in this silly and artificial obstacle - the need to go through all steps. That is even worse in my case since 1M is the highest adjustable range and that is STEP10.

Nowadays it seems to be popular discovering hidden commands in DMMs, I decided to give it a try.

(What's next is for quite educational purposes, don't try things since you can loose your precious calibration - if you screw up it's your responsibility)

After some digging I found the following unknown to me commands:

Code: [Select]

:CALibration:PROTected:RCOunt
:DIAGnostic:KEIThley:CALibration:AC:CONSTant
:DIAGnostic:KEIThley:CALibration:DC:CONSTant
:DIAGnostic:KEIThley:CALibration:UNLOCK
:DIAGnostic:KEIThley:EHRaccess
:DIAGnostic:KEIThley:ISN
:DIAGnostic:KEIThley:WARMBOOT
It's time to try some of them, but first - let's insure we won't loose our precious calibration. :'(



Capacitor makes it a bit harder, but clip accurately sits on the right side of the chip where data lines are, only need to connect programmator to ground in some other place.

Calibration flash data is saved, now we are prepared and safe.
By different reasons, first thing I tried to execute was :CALibration:PROTected:RCOunt.
This command doesn't seem to take any arguments and just does one unpleasant thing - immediately clears calibration count and dates , of course persistently saving them in a flash - precaution measure was very right decision, this meter is very unkindly to unknown command seekers.

After some digging, I found that some other commands are doing:

• :DIAGnostic:KEIThley:ISN is "Instrument Serial Number", they need somehow to program it, right ?
  Execution format is :DIAGnostic:KEIThley:ISN '1234567' - these quotes were quite unexpected thing, I only tried them because of how current measurement function is set, like :SENS:FUNC 'RESistance'. Maximum length is 7 symbols, but you can specify less. If someone specified symbols are not printable they will be shown as ' ' in *IDN? command. Action is also immediate, persistent and irrevertable.
  
• :DIAGnostic:KEIThley:WARMBOOT  is just some kind of reboot, still quite handy thing during experiments because things like calibration constants are not applied to the meter until reboot (or maybe some other action but I don't know exactly).
• :DIAGnostic:KEIThley:EHRaccess sounds like "External Hardware Access", but I have no idea what it really does inside, maybe just freezes CPU via special instruction, anyway it will unlikely help me with my task.
• :DIAGnostic:KEIThley:CALibration:UNLOCK does not take any arguments, it just does something (will see later).

Finally, the most tasty things :DIAGnostic:KEIThley:CALibration:AC|DC:CONSTant.
Unfortunately doesn't start constantly playing AC/DC on the meter  , but for success execution should take a number - number in various formats that meter usually accepts.

And as usual, nothing really happens, I've tried to execute them several times w/o any evident result.
Than just applying logic of how calibration happens, I decided to SAVE calibration - in order to to that you have to specify current and next calibration dates (which I already wiped).
So we executing:

Code: [Select]

:CALibration:PROTected:DATE 2000,01,01
:CALibration:PROTected:NDUE 2001,01,01
:CALibration:PROTected:SAVE
Rebooting the meter ... and immediately seeing something like

+440: "Gain-aperture correction error"

Let's call it a success.

Then we invoke command :CALibration:PROTected:DATA? and after some staring at the screen with old and new output we realize that some calibration constants changed to all that nonsense that I've tried before.
After some experimenting and digging I found that:
:DIAGnostic:KEIThley:CALibration:UNLOCK - allows to change calibration constants. Each time it invoked it resets in-memory constants we will change to the ones the meter has for now. Also allows to invoke calibration code change command.

:DIAGnostic:KEIThley:CALibration:AC|DC:CONSTant - these commands just take all calibration parameters from corresponding section one after another, very similar how calibration steps go.
In my case :CALibration:PROTected:DATA? shows 91 value:  26 AC constants (not sure about first 4 numbers) and 66 DC constants. In order to change one of them you have to invoke appropriate command, passing previous constants as they are (that's not really true, a bit later about it), then put a changed value(s), save calibration and reboot the meter - adjustment is ready.

This all enables possibility to play with calibration constants in repeatable and almost revertable way. Why almost?
Remember how meter outputs constants - it will show number like '+2.78018988E-01'. Fine, right ? Not really.
If we look now it's stored in flash (which btw has a few sections which meter reads and updates as single huge blocks, also with a hash in the end of most of them) then we find that all constants (except 4 numbers in the beginning of DATA? output) are represented as 8-bytes double numbers.

Number we try to find is (python is helping here):

>>> hex(struct.unpack('>Q', struct.pack('>d', +2.78018988E-01))[0])
'0x3fd1cb102748210a'

And we only see something like:

>>> struct.unpack('>d', struct.pack('>Q', 0x3fd1cb1027a256fa))[0]
0.2780189883281846

So here is the little trap for putting original constants back - we need 15 digits after decimal point in order to put back what is supposed to be here, but meter is only printing 8. For most of constants which are small, 10^-4 or 10^-6, but that's a bit unpleasant, +1 for why dumping flash directly from chip is very good option for those who can open the instrument.

Having all that, it's possible to adjust something in a meter like with a screw driver like in the old days, but don't screw it up completely.
Since my meter has much more constants than K2000 I cannot say which does what, finding that is the other huge task.
I can only say that setting constants one by one (via small script of course), I found gain constant for 1M range (which applies to 1M-100M ranges) and additional constant that applies to 10M and 100M ranges on the top of previous one (since as far as I understood 10M divider that is used for high voltages is used to measure 10M and 100M resistance in parallel to it). I still haven't found the way how to skip calibration steps, but this is at least something that helps me to solve my issue.

[alm]

Nice work! Please share which constants you have (roughly) identified the function of.

[chekhov]

I spend some time and identified almost all DC constants and what they are doing, see attached screenshot from my table.

Each calibration step may modify several constants, in firmware they are arranged in blocks with additional info, this way I found which ones are modified by each step and in which sequence.

Basically, values stored are:

• Values of standards used for calibration
• 'RAW ADC values' for zero offsets
• 'RAW ADC values' measured with each standard

Here 'RAW ADC values' are not exactly RAW because they are scaled, not just integer values. In table I'm writing 'gain' just for convenience, in reality they are more like 1/Gain.

I don't know what happens in a code exactly, so all is my imagination is only based on what I see from constants changing and results observing, I unfortunately not going to spend years reversing it all (at least for now).
In order to show some similar measurement, DMM likely using Zero and 'Gain' constants as values of two points that define a line going through them:

Measurement = (ADC_val - Offset) / (Gain - Offset) * Cal_standard_val

In case of OCOMP and DRYCKT modes:

Measurement = (ADC_High_val - ADC_Low_val) / (High_gain - Low_gain) * Cal_standard_val

I will double check eventually, but constants #52 and #54 are supposed to be zero offsets for rear ohms - 10K, 100K and 1M. They seem to be calculated during calibration but don't used in reality. If that's a bug, that's really funny, or I just missed it all twice.

Constants #36 and #37 do something unknown to me at the moment. They seem to be some kind of ratio - change of ratio changes measurements, but just scaling them changes next to nothing. At the moment I'm not brave enough to hook 'digital analyzer' to switching circuitry in order to identity actions that DMM does when calculating them, but may be related to ADC itself - maybe 1V goes into it and meter executes charging/discharging sweeps. I tend to think in this direction.

BTW, I noticed that my meter does not have TF-245 but one custom network + networks made from equal resistors (though still has footprint for TF-245).

[chekhov]

Instead of epilogue ...

Since I anyway found all high and low level entry points for calibration steps, I decided to try to break hard sequence of calibration steps.
Indeed, high level functions have several checks of variables and appropriate error codes.
I've tried to flip a few bits, and got some result ... it allowed me to execute cal steps in non-standard way without immediate '-200,"Execution error"'.

Unfortunately I wasn't able to make it work smoothly - somewhere somewhere deep inside crazy spaghetti or state machines there are additional check that always fails the first execution of any step I try.
However:

• Second execution of the same cal step passes (time to time I see failures, maybe due to meter wasn't warmed enough, or my meter is getting sick, no idea)
• All oher cal steps also pass (at lease a few I tried)
• Save works as usual

I cannot really call it a win, but at least pretty valuable 'success'.

So, what are the tweaks you may ask ...
Since each firmware is unique (unique addresses of all the same functions in most cases due to little change), patch is only applicable to version I worked on - A15. Changes basically skip check and instead of going somewhere by condition just go somewhere as if condition had the result we wanted.
Here is the diff:

Code: [Select]

EVEN:
-0000e530: ff67
+0000e530: ff60

-0000e5f0: 0004 2dff 6720
+0000e5f0: 0004 2dff 6020

-0003ffe0: 0000 0000 0000 0000 0000 0000 0000 0071
+0003ffe0: 0000 0000 0000 0000 0000 0000 0000 0072

ODD:
-0003ffe0: 0000 0000 0000 0000 0000 0000 0000 00f8
+0003ffe0: 0000 0000 0000 0000 0000 0000 0000 005a

Thus, brave meter owners that have a few SST39SF020 laying around may try this change. Don't forget to sump cal flash before any manipulations.

Unfortunately, I don't have opportunities to verify whether steps executed in reverse/arbitrary order are going to produce 'same' result as steps going in their natural order. I only see that steps change CAL constants in the way I annotated in my table.