Avoiding wrong data when using Keithley multimeters remotely - Page 1
Forum section: electronics / general

author: SanderMTI
author_rank: Contributor
timestamp: May 13, 2025, 05:53:06 pm
content: Hello All,My Keithley 2000 and 2700 both have the same bug when used remotely via GPIB, so it may be a universal Keithley thing.When the measurement mode is set, and NPLC is set above 4, these meters skip the first READ? and give the result of a previousREAD? ever after. No error is produced.The cure is to "read back" the measurement mode immediately after setting it with the corresponding ? query.Ditto for setting the NPLC .The readbacks apparently prevent the measured data form going "out of phase".This is the short version of the story, PM me for the details.Sander

author: aronake
author_rank: Frequent Contributor
timestamp: May 14, 2025, 11:58:48 am
content: All respect to your SCPI programming skills, but have you considered the possibility that it is your remote controlling programming that has bugs rather than instruments that have been around for 25 years and seen multiple firmware updates?

author: voltsandjolts
author_rank: Unknown
timestamp: May 14, 2025, 12:09:04 pm
content: I have a few Keithley instruments. Can you post a short pyvisa program that shows the problem, and how you fixed it. Thanks.

author: zlymex
author_rank: Frequent Contributor
timestamp: May 14, 2025, 01:45:19 pm
content: My keithley 7510 may have an opposite bug.When NPLC is set to 4 and below, the internal storage skip 20% of data.This is the interval in second of internal .csv file when set to V=100mV and NPLC=1.The interval should be arround 0.02s but 1 out of 5 is 0.04s.

author: maat
author_rank: Regular Contributor
timestamp: May 14, 2025, 02:45:22 pm
content: @zlymex ACAL?

author: SanderMTI
author_rank: Contributor
timestamp: May 14, 2025, 03:39:42 pm
content: Quote from: aronake on May 14, 2025, 11:58:48 amYes, Since I am writing the remote control software, that is the first thing which came to mind.If I tell the meter to convert, and ask for the result, it gives me a blank result after about 180 Milliseconds, which is roughlythe normal response time for NPLC 10 with autozero off.That suggests that it simply forgot to put the conversion result in the output buffer before setting EOI to indicate that it is done.Mind you, you can only see the issue if you compare the meter display with the data it sent for that conversion.Sander

author: zlymex
author_rank: Frequent Contributor
timestamp: May 14, 2025, 06:09:17 pm
content: Quote from: maat on May 14, 2025, 02:45:22 pmThanks very much for reminding me. I find out it was Auto Zero which is set by default.

author: SanderMTI
author_rank: Contributor
timestamp: May 14, 2025, 08:07:03 pm
content: Quote from: voltsandjolts on May 14, 2025, 12:09:04 pmYes, well.. I don't do Python, I use a prologix with compiled Pascal.The issue is that IF you set the measurement mode and/or the integration time, you have to give the meter time to do it's internalthing before you ask it for a reading.How much time you have to give it depends on the integration time you have asked for.This is not much different from what happens when you power the meter up.There is a period of time where it does not give any readings yet.I have found by experiment that following the "set mode" and "set nplc" commands with their corresponding readback queries provides enough time to avoid getting a blank first reading.In contrast, HP(AK) meters do not need any delay, you can ask for the first reading immediately after changing the integration time,and it will give the correct result. This is how it should be in my opinion.Since there is nothing in the Keithley docs which says that you have to allow time after certain remote commands, I consider theKeithley behaviour to be a bug.The bug applies to both command triggered and hardware triggered readings and has been observed in a Keithley 2000, 2400 and2700.Sander

author: SanderMTI
author_rank: Contributor
timestamp: May 14, 2025, 08:12:34 pm
content: Quote from: zlymex on May 14, 2025, 01:45:19 pmAh yes, well, that is also a firmware bug in my opinion.If the meter can't do things at a certain rate, it should should flag an error if you ask for a rate which is beyond what it can handle.Sander

author: Kleinstein
author_rank: Super Contributor
timestamp: May 15, 2025, 03:56:34 am
content: Many of the Keithley meters (2xxx series) use a rather odd auto zero mode. Meters like the K2001 or K2282 have a separate low noise ref. for the ADC and LM399 ref. for the long time. They need to include some extra measurements to connect the ADC gain to the LM399 - a little like one of the ACAL steps, measuring the LM399 derived reference.The older K19x meters had this step as fixed part of the AZ cycle and thus 3 ADC conversions in the cycle and thus a bit slow. The new meters seem to use a bit different sequence to hide the extra measurements. The extra delay seen with the DMM7510 could be the time for such an internal gain measurement that is added and just needs extra time.In a different thread the AZ sequence was just measured for a K2001:https://www.eevblog.com/forum/repair/keithley-2001-high-offsetpulsing/msg5908702/#msg5908702The non standard AZ sequence with extra measurements could also be the reason for the additional low frequency (~ 0.5 Hz range) noise, that is seen with many of the Keithley meters.With the extra steps needed and likely some averaging for the gain / Zero, it makes sense that it takes some time after a change in the mode or NPLC and likely also gain. A dealy would be OK, giving wrong data is a bug.

author: SanderMTI
author_rank: Contributor
timestamp: May 15, 2025, 12:26:51 pm
content: Quote from: Kleinstein on May 15, 2025, 03:56:34 amThank you for this post, it is exactly why I turn off autozero first. Of course, I turn averaging off as well. A discrepancy between the meter display and the reported value should never happen.In my opinion, it should not be this difficult to get a meter to produce correct readings, nor should the "correctness" depend on the NPLC you ask for. HP meters do not have this issue at all. Apparently, they wait until they are done with their internal setup beforeexecuting a "READ?" command, as it should be.Sander

author: Kleinstein
author_rank: Super Contributor
timestamp: May 15, 2025, 02:12:16 pm
content: AFAIK the HP meter (newer than the 3455) use a simpler AZ cycle with only a signal and zero reading. So no cirrction for the ADC gain and they get a valid result after just 1 cycle. With averaging (e.g. more than 10 PLC) they probably wait for a new valid result. With additional background averaging for the ADC gain measurement it would take quite a bit longer for a complete new reading. So one may get a mix with old and new data. The ADC gain is normally not changing fast, and thus no real issue averaging for that.Turning AZ off may not be an option when low drift is needed. Non AZ mode comes with less white noise, but more LF noise and more drift.

author: SanderMTI
author_rank: Contributor
timestamp: May 15, 2025, 07:18:42 pm
content: A fellow board member suggested that I explain what exactly it is that I am doing, so here is the complete Keithley drama:I have written software to set up GPIB meters and get data from them.This needed testing with the meters I intend to use with it, so I used the following test sequence without any time delays between theappropriate SCPI commands:Turn off continuous conversion / display updates.Turn off autozero and filteringSet the measurement modeSet the NPLCTake a reading and measure how long the response takes. (command or externally triggered)wait 5 secondsTake a reading ....etcetera.The first test subject was an HP 34401, which showed no issues at all from 1 to 10 nplc, either command or externally triggered.Next up was a Keithley 2000, and around nplc 4 or greater, the misery started.The first reading was often blank, but would take a "normal" time to acquire, subesequent readings would show the previous reading.This is not acceptable, so it needed fixing.The Keithley 2700 had similar symptoms.The 2400 fared much better, only showing the issue when externally triggered at NPLC > 8.What followed was a long period of experimenting in order to find out what these meters needed in terms of delays or command sequence.It was found that following the "set mode" and "set NPLC" commands with their corresponding readbacks solves the issue forcommand triggered acquisition, and that is where this post started.For those of you who write scripts for command triggered meters this tip may prevent some grief.(Externally triggered mode needs more than that, and this is where the Keithley drama is at right now)From my point of view, I want to make sure that what I write works with the meters I write it for.HP meters don't need any special considerations, just throw the commands at them and they will work correctly.Writing something for a Keithley is a different kettle of fish and becomes a research project in order to find out how they need to be talked to in order to work correctly.Keithley meters do work correctly if you skip setting the measurement mode or NPLC remotely.The price of convenience, I wanted the mode and NPLC configurable from the computer screen.Sander

author: voltsandjolts
author_rank: Unknown
timestamp: May 15, 2025, 07:39:10 pm
content: Quote from: SanderMTI on May 15, 2025, 07:18:42 pmI undertsand your frustration because, yes, experimenting to 'find the needed delays' is a PITA. But it's the wrong way.You shouldn't use delays but instead poll the meter for measurement status (BFL), or better still, setup and wait for the meter toraise SRQ. I'm not familiar with prologix, but I seem to recall that it supports SRQ, in that you poll the prologix to see if SRQ is asserted. I could be wrong about that. If not, you can certainly poll the gpib instrument itself for measurement status, e.g.Code:import timeimport pyvisa as visarm = visa.ResourceManager() # default backendkei2000 = rm.open_resource("TCPIP::192.168.1.84::gpib,20::INSTR")kei2000.timeout = 10000 # milli-secondskei2000.read_termination = '\n'kei2000.write_termination = '\n'kei2000.write("*rst; *cls")print(kei2000.query("*IDN?"))kei2000.write("func 'volt:dc'")interval_in_ms = 100number_of_readings = 16kei2000.write("status:measurement:enable 512; *sre 1")kei2000.write("sample:count %d" % number_of_readings)kei2000.write("trigger:source bus")kei2000.write("trigger:delay %f" % (interval_in_ms / 1000.0))kei2000.write("trace:points %d" % number_of_readings)kei2000.write("trace:feed sense1; feed:control next")kei2000.write("initiate")kei2000.write("*TRG")print("Sampling", end='')while (512 & int(kei2000.query("status:measurement?")) == 0):time.sleep(0.5)print(".", end='', flush=True)print("\nRetrieving...")voltages = kei2000.query_ascii_values("trace:data?")kei2000.write("trace:clear; feed:control next")kei2000.close()print(voltages)print("Readings requested: ", number_of_readings)print("Readings retrieved: ", len(voltages))

author: SanderMTI
author_rank: Contributor
timestamp: May 15, 2025, 11:42:30 pm
content: Quote from: voltsandjolts on May 15, 2025, 07:39:10 pm

author: Geoff-AU
author_rank: Frequent Contributor
timestamp: May 16, 2025, 12:11:15 am
content: Does it respond to *OPC? appropriately?

author: SanderMTI
author_rank: Contributor
timestamp: May 16, 2025, 06:50:30 pm
content: Quote from: Geoff-AU on May 16, 2025, 12:11:15 amYes, it does.I have feeling there may be more to it than just the meter.I see software as a house of cards, which is easily destabilized if the software has to interact with hardware.The problem at hand is that under some circumstances, a reading can be "missed" , which puts all subsequent readings out of phasesince they actually belong to a previous trigger.You can clearly see this as the number on the meter showing up on the computer screen at the next reading.To me, that smells like a data buffer issue and there are a few buffers in the data path.There is one in the meter, one in the Prologix, possibly one in its driver, and since Windows thinks it's a com port, it will have a buffer too.In principle, any one of the buffers going out of sync can produce the observed result.Playing with the .DLL version of the Prologix driver is on my list of things to try.The exact cause of the issue can only be guessed at, because I can only see the data which actually arrives.How it got there and what left the meter is invisible.Sander