Keithley DMM7510, SMU 2450 & 2460 problems

[MegaVolt]

Its also surprising that the noise is dramatically higher on the 10 Mohm setting.

I do not understand the physics of what is happening. Input impedance should not play a role when the inputs are shorted.

So, its not a mirage, its a ghost.

I get it from the touchscreen. Switching hands ranges and resistance.

[MegaVolt]

Next bug 

Multiple error when choosing the maximum buffer.

I chose Digitize voltage and tried to set the maximum buffer size. It will receive many errors with descriptions of the maximum allowed buffer size. Attempts to set the correct buffer size led to subsequent errors and a suggestion to reduce the buffer.

See the video for details.

[MrFox]

Next bug 

Multiple error when choosing the maximum buffer.

I chose Digitize voltage and tried to set the maximum buffer size. It will receive many errors with descriptions of the maximum allowed buffer size. Attempts to set the correct buffer size led to subsequent errors and a suggestion to reduce the buffer.

See the video for details.

There is the same bug in the 6500. Resizing buffers can sometimes cause memory fragmentation or memory leak.

Steps to reproduce on the 6500 (I have firmware 1.0.02a):
1. Reboot (power off, power on)
2. Go to Reading Buffers
--> The bug will appears if you do NOT touch the Buffer selector button and leave it at defbuffer1
3. Change capacity to 1M
4. Set buffer to defbuffer2
5. Change capacity to 10
--> Here the bug we see is that the buffer selection goes back to defbuffer1, but the capacity button is the value from defbuffer2
6. Set buffer to defbuffer1 (reselect it even if already selected)
7. Change capacity to 10
--> From this point, 1M is missing, it's not possible to either resize or create a buffer larger than 6M (7M is the max on the 6500). Until the next reboot.

In the mean time, it's simple to avoid the bug, always reselect the buffer before changing capacity.

[MegaVolt]

There is the same bug in the 6500. Resizing buffers can sometimes cause memory fragmentation or memory leak.

I failed to repeat this error on 7510.

[MegaVolt]

It's inside DotNet 

That's what it gives out when trying to run a demoscript.

com.keithley.internal.dotnet.ProxyIKeithleyTspInstrumentData.Java_com_keithley_internal_dotnet_ProxyIKeithleyTspInstrumentData_Write(IntPtr pEnv, IntPtr pObj1, IntPtr pStr2)
KeTSP Driver version:  4.0.6766.19771

[MrFox]

On windows, the apps like TSB are using dotnet.

But the instruments seems to be running freebsd (I think?) and a Lua interpreter for scripting. Lua is a nice efficient solution.

[MegaVolt]

On windows, the apps like TSB are using dotnet.

It is very good. And then I was already scared

But the instruments seems to be running freebsd (I think?) and a Lua interpreter for scripting. Lua is a nice efficient solution.

I learned so many new words with this device ) And so far all I could get is a buffer through the web interface at a speed of 334 kB / s

[Brad O]

It's inside DotNet 

That's what it gives out when trying to run a demoscript.

com.keithley.internal.dotnet.ProxyIKeithleyTspInstrumentData.Java_com_keithley_internal_dotnet_ProxyIKeithleyTspInstrumentData_Write(IntPtr pEnv, IntPtr pObj1, IntPtr pStr2)
KeTSP Driver version:  4.0.6766.19771

On windows, the apps like TSB are using dotnet.

It is very good. And then I was already scared

Were you using TSB?  The boxes themselves have no .Net or Java.  Can you share your script that causes the error?

For your buffer resizing issues, a couple comments come to mind.  The DMMs don't have any defragmenting tools built into firmware, so if you continually make/resize/delete buffers, you will limit the maximum buffer size by limiting the size of contiguous blocks of memory.  Also, all memory is treated the same.  So buffers, TSP variables, scripts, and all other volatile memory objects use the same space.   As a consequence of this, variables created in a TSP script and not cleaned up properly can also affect the buffer size.

[MegaVolt]

Discovered curious spikes for a range of 100 V and NPLC = 1 and NPLC = 0,1. Other NPLCs look pretty ordinary.

In Firmware v1.6.7c emissions on the 100V range are gone !!!

But they appeared on the ranges of 0.1V - 10V with the input connectors open and the input resistance 10MΩ.

Emissions go exactly 160 measurements. I would venture to suggest that the problem is in synchronization with the frequency 50Hz. When the measurement does not get to the right place.

See attachment:

[MegaVolt]

Were you using TSB?  The boxes themselves have no .Net or Java.  Can you share your script that causes the error?

Yes, I studied TSB. Unfortunately, I can not describe the procedure. In my opinion, I copied a piece of the script from the help file and inserted it into the Instrument Console and tried to execute it

I will try in the future to lay out repeated mistakes

For your buffer resizing issues, a couple comments come to mind.  The DMMs don't have any defragmenting tools built into firmware, so if you continually make/resize/delete buffers, you will limit the maximum buffer size by limiting the size of contiguous blocks of memory.  Also, all memory is treated the same.  So buffers, TSP variables, scripts, and all other volatile memory objects use the same space.   As a consequence of this, variables created in a TSP script and not cleaned up properly can also affect the buffer size.

I manage to repeat the error with the buffer on the freshly turned on device and the touchscreen without any scripts.

[MegaVolt]

Emissions go exactly 160 measurements.

These emissions also disappear if you disable AutoZero.

[Kleinstein]

The data also show an odd timing:
there are 4 time steps of some 21 ms, e.g. a little more than 1 PLC (which would be normal without AZ mode) and than there is one time step with some 42 ms apart, which would be about the spacing expected with AZ active.
This kind of suggests that there is a zero reading only for every 5 th input reading. and for some reason things go wrong after 32 zero readings.

I don't think this is about line synchronization, as even the Russian grid should not be off so far, and in a way to get the exactly 160 readings period.  My guess would be more something with an extra measurement (e.g. temperature) and than maybe just a little short on settling time for some precharge phase, so that there is some current spike at the input, that than gets measured.

Knowing that the data are coming at a not so constant rate (with an extra 21 ms break every 5 readings) could be important. It there an other AZ more to get the data at a more conventional constant 40+x ms spacing ?

[MegaVolt]

Histogram looks very interesting.

a1  AZ ON
a2 AZ OFF

[MegaVolt]

wrong after 32 zero readings.

Yes, 32 is a beautiful number. I do not know how to find out what happens every 32 AZ

[MegaVolt]

in my signal can be broken like this:

[MegaVolt]

Measure the current.
Here, too, there are interesting moments:

Measurements with open inputs:

10µA range - 1.4 pA
100uA range - 24 pA
1 mA range - 127 pA
range 10 mA - 647 pA

These are excellent numbers around 0.1 ... 0.2ppm

Measurements with shorted inputs:

10µA range - 33nA (3300ppm !!!)
100 uA range - 330nA (3300ppm !!!)
1mA range - 3.3µA (3300ppm !!!)
10mA range - 28µA (2800ppm !!!)

These figures are possible in the presence of thermal EMF = 33 µV at the input (28 µV for the last range)

And this is not a thermo emf jumper. After measuring the DCV, I see nanovolts.

This is something internally.

Moreover, this displacement does not create any problem if we measure the "current source".

But it creates problems when measuring the current that generates a voltage source and series resistance. And a two-year error of 20 ppm we get at a voltage of just 1.65V and less. Unfortunately, I have nothing to test this hypothesis.

I would be grateful if someone checks this assumption on precise instruments.
And maybe he will give another version of the occurrence of this error.

[MegaVolt]

After talking with the engineers, Keithley revealed the following:
The device retains its accuracy only if the input impedance AUTO mode is set.
Accuracy in 10 MΩ mode is not verified and is not guaranteed.

One of the engineers suggested using relative measurements to zero the offset manually. But in my opinion there is too little information about the reason for this bias. And as a result, one cannot be sure that it is stable and is compensated for by AZ correctly.

The correct specification as I understand it looks like this:

[JxR]

New Firmware 1.7.0 is online.  Of special note: the "virtual front panel", now appears to be the same version used on the newer DMM6500.  I've personally never had the DMM6500's virtual panel crash on me, unlike the older versions previously on the 2450 and 7510.  This is all I have checked so far, but very happy with this one change.

[JxR]

1.7.1 released to address a critical fix for the SMUs (2450 atleast).

New I-V tracer app available that is installed via Kickstart 2.2.0. Seemed like a cool basic feature, until you find out it is a paid license that starts at $1500. 

Either way you can try it out for 30 days, then uninstall. 

[HighVoltage]

Wow, that was fast for a new release!

Is that I/V tracer app also $ 1500 for those of us who have a full license of Kickstart?

[JxR]

Wow, that was fast for a new release!

Is that I/V tracer app also $ 1500 for those of us who have a full license of Kickstart?

Honestly not sure, although this page: https://www.tek.com/keithley-i-v_tracer#product-list shows the price of the app is from: $1.5k to $5k.  I think the app is kind of neat, but lets be honest: it basically just lets you perform a I/V sweep manually (which we can just automate). I really don't understand what they were thinking when they decided on that pricing.

You can watch a video of the feature here: https://www.tek.com/i-v-tracer-overview

[suntar]

Hi all!

Recently I've upgraded  our 2450 SourceMeter  from  1.1.0s  to 1.6.4.c firmware versions.

It was going well,  then showed "press reboot" message and reboot button. On pressing this button, display didn't react.
Then I switched the unit off and then on. Now it looks died.

Current state:  when I start it, the display is not working, it remains dark all the time.
SCPI command interface returns only *idn?  KEITHLEY INSTRUMENTS,MODEL 2450,04049676,1.6.4 and ignores other commands.
Also web interface is still partly alive: basically I can access it but it doesn't load screen on Virtual Front Panel and buttons don't work as well.
Interlock LED is on (green), real buttons are not working.

Does anybody know how to make  2450 SourceMeter  working again? 

Before upgrade procedure it had non-working real buttons (including output on/off) but all buttons were accessible from web-interface (this is how I've accessed "Menu" to start upgrading process..). Now the whole unit is ruined =(

[Zucca]

Welcome suntar, I think you need to contact Keithley directly regarding your problem.

[suntar]

Thanks, Zucca! I've already contacted Keithley two days ago through tektronix.com website, waiting for their response..

[MegaVolt]

Does anybody know how to make  2450 SourceMeter  working again?

The device supports launching the firmware update through the TSP / SCPI / Test Script Builder commands.