Keithley 2000 Service Request Timing Problem

[mikeporter]

Ok, that makes sense. With the longer integration time the Keithley couldn't keep up with what you were requesting.  According to the help you printed out an NPLC of 4 is somewhere between "medium" and "slow". Because that setting will effect the quality of your signal, you might want to see how much you can edge the value up before it inhibits to meet your 1 sec update time.

Mike...

[yitzoga]

It makes sense. I was thinking the same.

So, what I did to test out the theory was to set my sample rate to 1 sample per 20 sec; the instrument should integrate fast enough.

However, no, It is still taking 20.2 sec per sample...

[mikeporter]

Seems curious, but extending that setting seems to always add .2 seconds to whatever you set. Oh well, I guess that's the way it works.

Mike...

[JÞB]

It makes a lot of sense....If I go too fast on any of this ask---but read the manual first!

OK you hit a bug in the devices firmware-- Let me explain.

NPKC=4 actually gets coerced to 10 (the next option that contains 4)  this means "SLOW"  and humans are not going to notice the 200mSec in the devices display.....................

0.200 is 10 times 2 times 1/50 (you are on a 50 Hz grid or the equipment thinks it is-- there should be a setting for that)

Here is the bug: the device starts arm timer after the measurement completes.  It makes sense in a way.. we do not know what "Auto Zero" option may be selected.  (Think on that..... auto zero =on requires twice the measurement time)

In "fast" mode (NPLC = 0.10) the firmware in the device corrects for the lag between measurment start and measurement stop- Hey at those speeds a human eyeball may not be the only observer!)  I said it made sense in a way!

0.997 seconds------- the device derives its timing from primary power-  is the local power grid running just about 50.15Hz?  or do the math yourself- 50 Hz power is never 50.0000000000Hz!  and a device that thinks 50Hz is 60 Hz will always be mistaken in time.

[Blokk]

interesting things about how these multimeters operate! I've learnt a lot from this post 🙂

Just a question: is that really important that you want your Keithley to time and trigger a measurement exactly at every sec or so?

Why don't you configure the Keithley to have some optimal NPLC and maybe some integration (moving average in a way you get a mean value over about 1 sec?), and you use Labview to do the timing to read available data out exactly at every 1 sec or as you wish? (of course there will be always several msec deviations due to the operation system)

[JÞB]

---

@Blokk wrote:

interesting things about how these multimeters operate! I've learnt a lot from this post 🙂

Just a question: is that really important that you want your Keithley to time and trigger a measurement exactly at every sec or so?

Why don't you configure the Keithley to have some optimal NPLC and maybe some integration (moving average in a way you get a mean value over about 1 sec?), and you use Labview to do the timing to read available data out exactly at every 1 sec or as you wish? (of course there will be always several msec deviations due to the operation system)

---

Yes, the trick is figuring out exactly what the Kiethey does.  "How is my instrument lying too me?" is an important question.  All instruments "Lie."  I've just happened to catch on to how some of them lie to me through experience. (Often painful)

It makes me glad to know that there are other engineers out there that worry about the implementation details and develop those solutions for sample timing, filtering, noise surpression, tracability, etc ...ad nauseum.  with enough digging you can usually either get exactly what you want the device to do done or use what you get anyway.

In this case I'd use 10 NPLC and adjust the trigger arm timing by 20 PLCs and live with the fact that line power is not exactly 50/60 Hz or send in an external trigger that is timed to the needed tollerance.