Keithley DMM7510, SMU 2450 & 2460 problems

[HighVoltage]

The new Keithley instruments are really great, when they work alright. But ...

My DMM7510, the SMU 2450 and 2460 all suffer from time to time of several problems.

1. "Blue Screen of Death"
2. Not responsive to any button

I have contacted Keithley / Tektronix Germany but was not offered any help.
There is a hope that this will be fixed with any future FW update but who knows.
I was told by Keithley Germany, that this is a single incident, that only I have these problems and Keithley is not aware that others have these problems too.

The latest FW Version: 1.6.1a is installed
Release Date: Aug 23 2016 - 12:00 am

I have heard from other people here in the eevblog forum, that they have similar issues / problems.
May be we can help Keithley by compiling all problems in this thread and hope they can use it to fix everything in a new FW update.

So, if you have encountered any issues with your new Keithley instrument as well, please post them here.

Blue Screen Error Codes (so far detected)

- PC=0003D660
- PC=0003D661

[dr.diesel]

FW=1.6.1a on both my 7510 and 2450.

I've seen both issues you list above with #2 being very common.  I can easily trigger #2 by navigating the graph tabs via the instrument's web interface.

We should add a line item for maxwell3e10's noise discovery:

https://www.eevblog.com/forum/metrology/dmm-adc-noise-comparison-testing-project/msg1081347/#msg1081347

During a quasi non-responsive time I managed to catch this before it fully locked up:

 

[dr.diesel]

Posted a message on the Keithley forums, linking to here.

https://forum.tek.com/viewtopic.php?f=363&t=139083#p281815

[maxwell3e10]

1. Confirm blue screen with latest firmware

2. When using trigger programming from front panel to arrange for timed measurements, the meter stops triggering after some random number of samples.
 
3. Not a bug, but when saving buffer to USB, the meter does not check for existence of a file with same name, instead, it just always asks to confirm saving file.

4. Most directly dealing with performance, the autozero does not effectively remove flicker noise on DCV 10V scale for continuous measurements on time scales of 1-50 sec, as illustrated in figures below. As the result on 10V DCV scale the noise performance of DMM7510 is significantly worse than Keysight 34465A.

[_Wim_]

Wow, I would not have expected this from Keithley. I realize that every brand can release a software with some issues left, but then I would expect them to at least acknowledge these and assure the customer they are working on a fix for the next firmware release. Especially because it seems it not very difficult to trigger the fault…

Still, I think their gear looks really fantastic, and would love to have your setup (with our without problems). But for the moment I do to little development to warrant that kind of cost…

[HighVoltage]

Thanks for adding to my list of problems.

Lets hope, it is all only software related, which I think it is.
My 2450 SMU never showed a blue screen until one of the the last FW updates, so this would indicate only a software issue.
But the noise discovered by maxwell3e10 might be HW related?

I will make a similar noise test comparison between the 7510 and the 34470A
Will be interesting, to get the same results

[plesa]

On some instrumets it takes Keithley years to fix issues:
2600B series 3.3
2400 series 33
And some of them still remains.
Do yo know how to reproduce instrument hag up issue or how to prevent their occurrence?
For instance on K2400 is bug with disabling display, but on 6517B series is already fixed:)
It must be quite painful for Keithley and other manufacturers that people are sharing issues on this forum.

[carl_lab]

It must be quite painful for Keithley and other manufacturers that people are sharing issues on this forum.

It should be painful.
They can fix the problem, and everything is all right...

[plesa]

It must be quite painful for Keithley and other manufacturers that people are sharing issues on this forum.

It should be painful.
They can fix the problem, and everything is all right...

I do not think they do not want to fix it but I expect that software team is shared across platforms and they are limited by resources for maintenance.
You can speed it up by describing steps to reproduce and connecting fix to big deal:)

[HighVoltage]

Do yo know how to reproduce instrument hag up issue or how to prevent their occurrence?

Reproduce, partially yes:
The none response can be easily triggered through the web interface and it required a cold / hard restart
The "Blue Screen of Death" happens out of the blue once in a while, but mostly when swiping from the statistics screen to the graph screen.

Prevent:
No.
It is possible to use the DMM7510 for hours and without any problems.
Suddenly it crashes.
After a reboot, it is very well possible that this crash will happen right away again of it can take hours again.
Worst case, one stores a lot of good data and wants to save a screen shot and right then it crashes.
 

[Kleinstein]

Thanks for adding to my list of problems.

Lets hope, it is all only software related, which I think it is.
My 2450 SMU never showed a blue screen until one of the the last FW updates, so this would indicate only a software issue.
But the noise discovered by maxwell3e10 might be HW related?
.....

The noise problem gets smaller if triggered readings are used (visible in the curve in the noise comparison thread). So the software can do better, if used in a different mode. If done the normal, simple way the AZ function should take care of the flicker noise on time scale longer than two readings (input and zero) even better - just like it did with the Keysight instruments. There would have to be something really odd in hardware to get this type of noise spectrum with active AZ mode. Even if there is some special Hardware involved the better performance using a different mode shows that at least some of the noise is avoidable.

The much more likely reason it, they tried to be clever and used different (more complicated), non standard way of doing the AZ mode and this just does not work well. It might be possible it worked ok on older very different HW. The curve for the K2002 somewhat suggests that there might be a similar weakness with the K2002 too.

Different from the other SW bugs, this is not a rare glitch happening under special conditions. This is more like a well defined point in the software, where a not so good formula is used. Normally this should be relatively easy to find and fix.

[maxwell3e10]

Has anyone tried to keep track of the code it displays on the blue screen? Perhaps it would be useful to make a list of the codes.

When I program a trigger series from the front panel, there is 100% chance it will lock up soon, although not blue screen.

[dr.diesel]

Vince W from Keithley just responded:

"Thank you for bringing this to our attention. I have forwarded the links on to our product teams to address these issues. We would post any responses on our forum, so the blog participants should watch here."

Direct link:

https://forum.tek.com/viewtopic.php?p=281837&sid=f0617886f132ba13c5af865cee429a5d#p281837

[dr.diesel]

Has anyone tried to keep track of the code it displays on the blue screen? Perhaps it would be useful to make a list of the codes.

I don't see the blue screen near as often as the general lockups, but this is the error I've seen repeatability.

PC= 0003D660

[HighVoltage]

I just had a different blue screen error code on the screen:
PC=0003D661

All error codes will be edited in to the first post.
Any others?

[dr.diesel]

Just caught another one on my 2450.  Then happened via Quickset > Voltmeter > Clicking Yes on the warning box.

PC= 000282DC

I suspect we'll need to mirror this info on the Tekley forums.

[adranp]

Just wondering, have you had the same issues prior to FW 1.6.1a?

[dr.diesel]

Yes, I've had stability issues with all FW versions, however it does "seem" like the most recent is more problematic.

[boborich]

Just to report that have blue screen issues with the recently purchased DMM7510 with the latest FW 1.6.1a.

Code: PC=0003D660

This happens a lot when playing around with the buffer and chart operation.

[plesa]

Just to report that have blue screen issues with the recently purchased DMM7510 with the latest FW 1.6.1a.

Code: PC=0003D660

This happens a lot when playing around with the buffer and chart operation.

Are you going to return this unit?

[adranp]

Did anyone running 1.6.1a tried to downgrade to an older FW release and do some tests?

Thanks.

[dr.diesel]

Further response from Vince at Tekley:

"We are addressing these issues now and applying engineering release control and audit rigor for a new firmware release. We apologize for getting this latest release out with the issues you have found. Each release takes time and this is a difficult time of year to get all resources working at full speed because of the holidays."

Sounds like a new FW revision might be headed out way soon.   

[boborich]

Just to report that have blue screen issues with the recently purchased DMM7510 with the latest FW 1.6.1a.

Code: PC=0003D660

This happens a lot when playing around with the buffer and chart operation.

Are you going to return this unit?

Not sure yet, it is a nice bit of tool and I have printed the 1000 pages of the reference manual

Hopefully keithley will fix these issues with FW releases.

Btw, if I return this, what shall I get? 34470 or 34465? In China, 34470's price is close to DMM7510 and that is the reason why I bought 7510 at the 1st place.

[boborich]

Further response from Vince at Tekley:

"We are addressing these issues now and applying engineering release control and audit rigor for a new firmware release. We apologize for getting this latest release out with the issues you have found. Each release takes time and this is a difficult time of year to get all resources working at full speed because of the holidays."

Sounds like a new FW revision might be headed out way soon.   

I saw that reply too, get my finger crossed, and thanks for putting everything together and pushing Keithley to look into this for us!

[boborich]

Did anyone running 1.6.1a tried to downgrade to an older FW release and do some tests?

Thanks.

I downgraded to 1.5 yesterday and seems to be much better than 1.6. Haven't got any blue screen or lock up so far. Recommend you try that before the new FW come out.

[HighVoltage]

I downgraded to 1.5 yesterday and seems to be much better than 1.6. Haven't got any blue screen or lock up so far. Recommend you try that before the new FW come out.

Good to know.

My DMM7510 came with FW v1.5 installed and had no issues.
This confirms that the problems increased with the FW v1.6

[dr.diesel]

Two updates from Tekley:

When I asked specifically about the AZ bug:

"I am waiting on an analysis from our engineering team in regard to performance/autozero; not sure it's a bug unless I missed something. In the meantime, I'll suggest some ways to reduce noise (flicker was mentioned). Autozero is designed to reset drift from the 0.000 reference, but it comes at a time expense. To reduce noise levels, you can increase NPLC, turn on Line Sync -both under Menu->Settings (under Measure)- and use a moving average filter -see Menu->Calculations (under Measure)->Filter."

And then:

"REGARDING BLUE SCREENS AND LOCKUP CONDITIONS:

We have confirmed blue screen and lockup conditions and are testing a hot fix for v1.6.1a firmware. This hot fix would be available for all touchscreen products. The hot fix will not be a general download because it is not a standard firmware release. We will be making it available to customers who have a critical need and are not able to use the next-rev-down firmware on their instrument. This hot fix will be incorporated into a future standard firmware release.

We encourage you to down-rev your firmware as a first attempt to correct the situation.
To down-rev your firmware from v1.6.1a, you can retrieve the most recent prior rev:
2450 http://www.tek.com/source-measure-units/2450-software-12
2460 http://www.tek.com/source-measure-units/2460-software-1
2461 http://www.tek.com/source-measure-units/2461-software
DMM7510 http://www.tek.com/digital-multimeter/dmm7510-software

If you have a critical need for the hot fix, please send me a private message with your email address for follow-up (click on Private messages [X] in the top right corner of the page, select Compose Message)."

[maxwell3e10]

I switched to earlier version of firmware, but the problem with triggers is still present. Attached is the .tsp set up file, renamed .txt to allow download. It is actually just  a text file anyway.

The triggers are programmed from the front panel. The goal is to make measurements every 100 msec for 100000 samples. The program works, but it has never reached 100000 samples, usually stops somewhere between 5000 and 30000, at a random number.

Perhaps someone can upload this script and try to run it on their meter, to see if its a common problem.

[HighVoltage]

Just to update everyone on this issue.
I have updated my 2450 SMU successfully to the hot fix (interim) FW version 1.6.3b  and the blue screen has not happened so far.
All looks good so far.

Keithley is planning to release a full FW update right after the holidays.

[bson]

I do not think they do not want to fix it but I expect that software team is shared across platforms and they are limited by resources for maintenance.

Of course, no one sits around and waits for a bug report to appear in their in basket and leaps to it...  Bugs are added to the scheduled and prioritized work of any engineering group and handled as they get to it.  However, HOW bugs are prioritized, and what's considered critical enough to drop other work and fix ASAP is telling of how customer-focused an organization is vs how engineering-focused it is.  (Engineers hate being broadsided like this and are very uncomfortable with context switching, especially when they're neck deep in working on a new product and have it entirely in their mind.  Not fun to have to switch this to some other product they haven't touched in a while and get back into that.  Tends to bias the views when prioritizing.)

As for inadequate information, if there's not enough in the report, such as engineering needs a reproducible test, then they should ask for it - reach out to the customer and ask.  But in a lot of organizations engineers aren't permitted to communicate directly with customers.  This is totally ack basswards - engineers should talk to customers when they need technical information and not have to go through product.  Product should prioritize bugs!  The reverse is anathema to customer response.

[HighVoltage]

Just another update ...

Today I upgraded my 2460 SMU to the the hot fix (interim) FW version 1.6.3b
And I used the instrument all day and had no blue screen.
Really good so far.

[plesa]

Just another update ...

Today I upgraded my 2460 SMU to the the hot fix (interim) FW version 1.6.3b
And I used the instrument all day and had no blue screen.
Really good so far.

Kudos for Keithley 

[maxwell3e10]

Good to hear the BSD seems to be solved. Now they just need to solve the functional problems:

A. Make the meter trigger at uniform timing without crashing. In contrast, Keysight 34465a has two different methods to program uniform sampling.

B. Resolve noise issues. I made a few more plots to show the problems. Of course the suggestion of their engineer to use the moving average filter makes it only more obvious that it doesn't work properly.

[HighVoltage]

Yesterday I updated the last one, my DMM7510
It has been used for many hours and also did not show any Blue Screen anymore.
I think the BSD issues have been solved completely on the 2450, 2460 and 7510.

Thanks to Keithley for taking care of this issue so fast and so well with an interim FW solution.

May be Keithley can fix the remaining problems in a future full FW update soon.

[maxwell3e10]

Has anyone tried to run the script I posted above for uniformly timed measurements?

If its confirmed in other meters, we should break it out into a separate item and post on their support page.

[dr.diesel]

Has anyone tried to run the script I posted above for uniformly timed measurements?

If its confirmed in other meters, we should break it out into a separate item and post on their support page.

I'll get mine running your script today! 

[dr.diesel]

Has anyone tried to run the script I posted above for uniformly timed measurements?

If its confirmed in other meters, we should break it out into a separate item and post on their support page.

I'll get mine running your script today!

Well, mine made it to 34464 readings, then just quit, no errors.   

Running the test 1.6.3b FW.

[maxwell3e10]

Thanks. That is what I was seeing, it stops at a random number without errors, the data are still there. The problem was both in 1.6.1 and 1.5 versions.

[dr.diesel]

Thanks. That is what I was seeing, it stops at a random number without errors, the data are still there. The problem was both in 1.6.1 and 1.5 versions.

I have forwarded the info/script to Keithley for their confirmation.

[maxwell3e10]

Thanks. Who are you talking with?
We still need to press them about the noise issue, but I figure this will be easier to handle first.

[dr.diesel]

Thanks. Who are you talking with?
We still need to press them about the noise issue, but I figure this will be easier to handle first.

PM incoming.

[HighVoltage]

I just ran your script as well

FW  1.6.3b
Stopped at 34464 rdgs

Also interesting:
The symbol on the top line switched from RUN to WAIT but sometimes it just stopped and did nothing for a few seconds and then alternated between RUN and WAIT again.
 

[maxwell3e10]

Ah, interesting, stopped at the same number of points. For me it would usually stop at fewer points and not the same number, but maybe once it was in the 30 thousands.

[donkey77]

Maybe it stops before 34465 as it would then promote Keysight!

[HighVoltage]

Just an update and confirmation:
It has been a few weeks now that I have used this interim FW on all three instruments and I had zero blue screen effects.
That problem seems definitely solved.

Remote control hangup still happens from time to time on the DMM7510.

[dr.diesel]

I can echo the above, zero bluescreens since the interim FW.

The web interface is still unusable, programmed trigger/AZ issue are still present.

[maxwell3e10]

I wonder if we should separate the issues into 3 items and post them individually on their support page, to increase the visibility of the problems.

[Kleinstein]

AFAIK the 3 instruments use a very similar software for the display part and it seems like the the big problem with blue screens is more or less solved.

The not so good AZ implementation is a little different from that. Some of the shown curves in the DMM noise comparison thread even suggest that this problem could be common with even more Keithley instruments (like the 2002). I have not seen noise spectra of Allan deviation curves for the SMUs - so not sure they are also effected.

[HighVoltage]

I wonder if we should separate the issues into 3 items and post them individually on their support page, to increase the visibility of the problems.

I was told that Keithley is working on all issues and it will be addressed in the next official FW update.

[dr.diesel]

I was told that Keithley is working on all issues and it will be addressed in the next official FW update.

Dumping a change/fix for the AZ bug could be interesting.  Although quite small it might pose some problems for critical automated test cells.

[HighVoltage]

Just to update you on my progress...

Keithley released another interim FW version1.6.3c
Last week I installed it on my three Keithley instruments 2450, 2460 and 7510
It seems this has fixed the hanging web interface problem as well now.

An official new FW update should come soon.

[dr.diesel]

Keithley released another interim FW version1.6.3c

It also fixed (I've not tested the web interface yet) the triggering issue reported by maxwell3e10

[dr.diesel]

It seems this has fixed the hanging web interface problem as well now.

Tested the web interface today, locked it up twice within 3 min each time.   

[maxwell3e10]

I played a bit with the new FW. The trigger hang-up problem does seem to be solved. Now there is a new problem, some menu items become grayed out. In particular, when Save to USB is grayed out, one cannot save the data and the only way I found to fix it is to restart the instrument, thereby loosing data in the buffer.

Regarding noise, the behavior is the same. I tested another method using a .tsp script:
repeat
dmm.measure.autozero.once()
dmm.measure.read()
until false

This forces the autozero and eliminates the bump in the Allan variance. The only problem is that it is slow, the cycle time is about 20 times PCL setting. But it is still better than normal operation, which again points to the fact that the AZ algorithm is too smart for its own good.

[maxwell3e10]

I played more with a .tsp script to force autozero between measurements. Here are the results of an optimized script (attached) that uses four 1 PLC measurements between each forced autozero. This works  much better than continuous 10 PLC readings. Still not as good as Keysight 34465A.

[HighVoltage]

Keithley has release a new official FW for the DMM7510 on April 20th 2017
FW v 1.6.3.d.

So far it looks good.
Release notes PDF is enclosed

[maxwell3e10]

The file is dated Feb 17, 2017, so its probably similar to the interim version c.

[Klaas]

I have my new BMM7510 now for 4 hours and it had several blue screens with Frmw 1.6.3d. Also after network connect I lost my touch screen and only could control the unit with the rotary switch. To be honest, for a device >3K euro's and already for 2 years on the market, I think this sucks.

I will ask Farnell tomorrow if I can send it back, this is not workable.

How are those PSU from Keithley? Are the software problems only in the SMU and DMM's?

[dr.diesel]

I have my new BMM7510 now for 4 hours and it had several blue screens with Frmw 1.6.3d.

Could you please post screenshots of the bluescreen text/error message?

[Klaas]

I already put it back in the box in order to send it back.
I'm a bit frustrated so I don't have the energy right now to give it another try.

BTW
I think that problem with network connection and that  touch screen is easy to reproduce.
I also didn't succeed showing front panel screenshots with that web server, it is always just busy.

[HighVoltage]

I have played with the instrument and new FW installed and found no issues at all so far. No more blue screen for me or freezing situations. For me it works perfectly right now.
But lets wait a few days for the final verdict.

[maxwell3e10]

Here is an interesting plot of Dr.diesel's data measuring 731B 10V voltage reference using a custom AZ script that I wrote (lownoise.txt). I compare it to the data that I took earlier using a standard 10PLC measurement of a 10V battery. 
https://www.eevblog.com/forum/metrology/dmm-adc-noise-comparison-testing-project/msg1094322/#msg1094322

One can see that in the time range of 10 to 100 sec the custom AZ script removes the noise bump in the Allan variance. At longer times both measurements are affected by the drift of the voltage references in the meters or by the voltages sources themselves.

This confirms that when measuring a finite voltage the autozero problem of DMM7510 is significant and limits the performance on a time scale of 10 to 100 sec.

They have not attempted to fix this problem with the newest firmware release.  To me this problem was obvious within 5 minutes of getting the meter (at first I thought it was defective until I found data from others posted by TiN). Even though the meter meets the specs since there are no specs for longer than 5 PLC, the time domain data look crappy.  I have already spent a lot of time on corroborating and diagnosing this problem, but at this point it's probably better to just stick to Keysight meters.

[HighVoltage]

... but at this point it's probably better to just stick to Keysight meters.

This is great info again in your post, thanks.

How does a comparable chart look like from a Keysight meter?

[maxwell3e10]

How does a comparable chart look like from a Keysight meter?

I posted earlier a comparison for Keysight 34465A. For finite voltages it does not look great, but I think its because of the voltage reference. I need to get a 34470A for a fair comparison. Or perhaps someone else here has a 34470A and a decent voltage reference.

[Klaas]

@HighVoltage

E.g. Are you also using the LAN network connection  and Kickstart software?
It freeze my touch screen and causes blue screens if I start using the rotary knob.

[dr.diesel]

Couple quick notes on the latest 1.6.3d FW.

 - I'm still regularly locking up the web interface
 - This morning when I came in the unit it'self was locked up.  Screen was dimmed, it brightened up when I touched it, but no other functions/buttons responded.

Both of the above required an instrument reboot.

Brian from Tek suggested switching from DHCP to Static, which I did prior to the above, so no improvement.  So far no comments from them regarding the AZ issue.

If anyone else is seeing issues, including already mentioned ones, please share them here and on the Tek site:

https://forum.tek.com/viewtopic.php?f=363&t=139083

[dr.diesel]

Turns out during all the FW updating my 7510 somehow defaulted to one less digit of precision, but only in SCPI mode, TSP and the display were fine.

Well the good folks at Keithley were kind enough to relay a command (I don't recall this in the manual, but did not verify) that defines the output precision:

Code: [Select]

:FORMat:ASCii:PRECision 16
16 is the max value, which will return 1.000006082692534E+01.       

A big thank you to Keithley Tech support.

[HighVoltage]

Nice to know about that command, thanks

Since the last FW update, I had no more issues with my 7510 and I am really happy with it.

[HighVoltage]

The firmware version v1.6.4c has been released for the 2450, 2460, 2461 SMU and DMM7510
Release Date: Wed, 09/06/2017 - 12:00

I have just updated the FW on both my SMU and they seem to run stable.

https://www.tek.com/source-measure-units/2450-software/2450-firmware-revision-164c-release-notes


Critical Fixes DMM7510
Blue Screen Crash when using the navigation knob.
Models affected:
All 7510 models
Symptom:
Steps to reproduce:
1.   Power cycle the unit.
2.   Press the QUICKSET button.
3.   Change the function to Temperature
4.   Press the MENU key and navigate to the measure settings screen
5.   Change the tranducer to 4-wire RTD
6.   Press the HOME key and go back to the home screen
7.   Press the navigation knob once and the blue screen occurs.
Resolution: This issue has been corrected.

[kj7e]

Any updates to report since v1.6.4c Firmware?  Where the BSD crashes addressed?  Any improvement to the A/Z noise?

I have been eyeing the DMM7510 for a Christmas gift (to myself).  Doing my due diligence and trying to read up on all of the reported experiences.

Last question, how has the display been holding up for those who leave the instrument powered on continuously?  Any burn-in, fade, delamination or other issues?

[dr.diesel]

I've not seen a BSD since the last update, however using the web interface will still cause lockups, no AZ improvements.

No screen issues and mine is powered 24-7.

The AZ issue has been clearly documented and reproduced on several units, however Keithley refuses to comment on it, I suspect it will never be addressed.  I would encourage you to ask the same questions over at their forum:

https://forum.tek.com/viewtopic.php?f=363&t=139083&sid=1ca6a4715bcd253c04e7750bd83fdf6a

As Keithley does not appear to read here, posting above might help the cause some.

[HighVoltage]

Since I have installed v1.6.4c Firmware, I had no more BSD crashes.
The A/Z noise has not been addressed by Keithley, not even a word of explanation, as far as I know.
The display works perfectly from a viewing and touch perspective, no issues at all.

The DMM7510 is a really nice instrument and besides the A/Z noise, it can be highly recommended.
The ACAL works more stable, compared to the Keysight 34470A
And the instrument reads stable after only 3 min after the cold start.
Nice Christmas present!

[maxwell3e10]

I haven't seen a literal BSD, but it still hangs up sometimes with a certain sequence of touchscreen commands requiring a restart.

[bozidarms]

The DMM7510 is a really nice instrument and besides the A/Z noise, it can be highly recommended.

For one lab-grade DMM , low noise should be one of the key factors, otherwise  is than huge shortcoming for 7510.

[kj7e]

I'm going for it. It was either a new DMM7510 or a used and questionable 3458a, since I don't "need" the 3458a's 8.5 dig but could use many of the other features the 7510 has, it won.  Should be here next Tuesday.  Early Christmas gift.

[niner_007]

Here is an interesting plot of Dr.diesel's data measuring 731B 10V voltage reference using a custom AZ script that I wrote (lownoise.txt). I compare it to the data that I took earlier using a standard 10PLC measurement of a 10V battery. 
https://www.eevblog.com/forum/metrology/dmm-adc-noise-comparison-testing-project/msg1094322/#msg1094322

One can see that in the time range of 10 to 100 sec the custom AZ script removes the noise bump in the Allan variance. At longer times both measurements are affected by the drift of the voltage references in the meters or by the voltages sources themselves.

This confirms that when measuring a finite voltage the autozero problem of DMM7510 is significant and limits the performance on a time scale of 10 to 100 sec.

They have not attempted to fix this problem with the newest firmware release.  To me this problem was obvious within 5 minutes of getting the meter (at first I thought it was defective until I found data from others posted by TiN). Even though the meter meets the specs since there are no specs for longer than 5 PLC, the time domain data look crappy.  I have already spent a lot of time on corroborating and diagnosing this problem, but at this point it's probably better to just stick to Keysight meters.

if it was designed that way deliberatly it's not a bug, and it can't be considered noise; from all the information available, it seems like they optimized it specifically at 5PLC; also, since the script removes the bump I don't see how it is a problem, or just use it at 5PLC; what am I missing? it seems like this whole thing was blown out of proportions (PS sorry in advance for being a noob)

[niner_007]

How does a comparable chart look like from a Keysight meter?

I posted earlier a comparison for Keysight 34465A. For finite voltages it does not look great, but I think its because of the voltage reference. I need to get a 34470A for a fair comparison. Or perhaps someone else here has a 34470A and a decent voltage reference.

I have a 34470A, tell me what to do and I'd love to do it

[Kleinstein]

There are already similar curves for the Keysight meters earlier in this thread. The suitable test would be to collect data for a reasonable long time (e.g. 1-3 hours) under stable conditions. Ideally with a very stable source (e.g. LTZ1000 or better) in 10 V range, but the extra noise is also visible with just a short.

The Alan variance curve is kind of related to the frequency spectrum of the noise. The curve from the custom AZ script is about the normal shape expected. In some metrology applications the minium value reached is an important quality criterion, especially if this is not at too long a time scale. That 10-100 seconds time scale is just the one needed for doing test with dividers or similar. The custom AZ script can do better in this range, but as one can see it is rather noisy on the short time scale, and an internal solution if done right could likely do considerably (about a factor of 1.5-4) better. So the extra script is kind of a work around but not a full solution.

Just using the 5 PLC mode does not solve the problem. Once you average those data taken at 5 PLC to get even lower noise that extra noise comes back and noise even goes up when averaging more than about 100 samples. This might also lead to wrong conclusions if the normal statistics is used to estimate noise. One would normally assume the data are not correlated over more than maybe the next neighbors - but with the Keithley meters (to some extend a similar bump is even visible with the K2002 and may very well effect more meters) there seem to be some correlation up to 100 seconds.

From the analysis done so fat in this thread, it looks like Keithley is using some averaging on the zero readings when doing AZ, even if digital filtering is turned off. This sounds like a good idea at first sight and could reduce the short time scale (high frequency) noise a little. However it comes at the price of not so good suppression of 1/f noise of the ADC/amplifier. So generally this is not a good idea and it would be really nice if Keithley would also offer the normal simple difference AZ mode.

[niner_007]

There are already similar curves for the Keysight meters earlier in this thread. The suitable test would be to collect data for a reasonable long time (e.g. 1-3 hours) under stable conditions. Ideally with a very stable source (e.g. LTZ1000 or better) in 10 V range, but the extra noise is also visible with just a short.

The Alan variance curve is kind of related to the frequency spectrum of the noise. The curve from the custom AZ script is about the normal shape expected. In some metrology applications the minium value reached is an important quality criterion, especially if this is not at too long a time scale. That 10-100 seconds time scale is just the one needed for doing test with dividers or similar. The custom AZ script can do better in this range, but as one can see it is rather noisy on the short time scale, and an internal solution if done right could likely do considerably (about a factor of 1.5-4) better. So the extra script is kind of a work around but not a full solution.

Just using the 5 PLC mode does not solve the problem. Once you average those data taken at 5 PLC to get even lower noise that extra noise comes back and noise even goes up when averaging more than about 100 samples. This might also lead to wrong conclusions if the normal statistics is used to estimate noise. One would normally assume the data are not correlated over more than maybe the next neighbors - but with the Keithley meters (to some extend a similar bump is even visible with the K2002 and may very well effect more meters) there seem to be some correlation up to 100 seconds.

From the analysis done so fat in this thread, it looks like Keithley is using some averaging on the zero readings when doing AZ, even if digital filtering is turned off. This sounds like a good idea at first sight and could reduce the short time scale (high frequency) noise a little. However it comes at the price of not so good suppression of 1/f noise of the ADC/amplifier. So generally this is not a good idea and it would be really nice if Keithley would also offer the normal simple difference AZ mode.

Thank you for explaining it. Is the 10 - 100 seconds here referring to the integration time, or the overall time at which the sample was taken? If the latter (unlikely), couldn't one just wait 100 seconds?

[Kleinstein]

The 10-100 seconds time scale where additional noise appears refers to the timeframe used for comparing data or the length of record to calculate noise. The Allan deviation is averaging data over a given time and than compared adjacent averages. So it is a little like taking 10 second average reading of a voltage of interest and than 10 seconds of zero reading to compensate for an offset that is effected by the noise like the 10 second point of the Allan deviation.
With many normal meters the 10-100 seconds range is about the sweet spot, with the lowest Allan deviation. Thus this time frame is often used in sensitive tests - it also kind of matches what is practical with manual switching and reading. So for such manual operated tests the Allan deviation at some 10 seconds is the relevant noise parameter, not 5 PLC noise.

Waiting more than 100 seconds not really a solution as here noise sources like slow thermal drift will come in. So at 100 seconds it is only back to the 2 seconds value.
The script to force a kind of manual triggered measurement is a workaround, but due to extra waiting times involved it would add noise.

[niner_007]

could one in theory implement better (custom) AZ, by using an external ultra precise reference and custom scripting on the DMM, so when you do the AZ, you switch to the reference (relays), measure, offset (on the data read from the DMM), then continue measuring? without modifications to the DMM, of course, this would all be external

[niner_007]

There are already similar curves for the Keysight meters earlier in this thread. The suitable test would be to collect data for a reasonable long time (e.g. 1-3 hours) under stable conditions. Ideally with a very stable source (e.g. LTZ1000 or better) in 10 V range, but the extra noise is also visible with just a short.

The Alan variance curve is kind of related to the frequency spectrum of the noise. The curve from the custom AZ script is about the normal shape expected. In some metrology applications the minium value reached is an important quality criterion, especially if this is not at too long a time scale. That 10-100 seconds time scale is just the one needed for doing test with dividers or similar. The custom AZ script can do better in this range, but as one can see it is rather noisy on the short time scale, and an internal solution if done right could likely do considerably (about a factor of 1.5-4) better. So the extra script is kind of a work around but not a full solution.

Just using the 5 PLC mode does not solve the problem. Once you average those data taken at 5 PLC to get even lower noise that extra noise comes back and noise even goes up when averaging more than about 100 samples. This might also lead to wrong conclusions if the normal statistics is used to estimate noise. One would normally assume the data are not correlated over more than maybe the next neighbors - but with the Keithley meters (to some extend a similar bump is even visible with the K2002 and may very well effect more meters) there seem to be some correlation up to 100 seconds.

From the analysis done so fat in this thread, it looks like Keithley is using some averaging on the zero readings when doing AZ, even if digital filtering is turned off. This sounds like a good idea at first sight and could reduce the short time scale (high frequency) noise a little. However it comes at the price of not so good suppression of 1/f noise of the ADC/amplifier. So generally this is not a good idea and it would be really nice if Keithley would also offer the normal simple difference AZ mode.

could one use the AZ script as a workaround? what is the problem with using it, beside the noise in the shorter time scale? speed?

[Kleinstein]

The script is a kind of workaround at the costs of higher noise for shorter time scales. In addition the timing is a little different (slightly slower). Depending on the application this can help, though an upgraded ("fixed") software in the DMM would be better (lower noise) and easier to use.

The allan deviation curve looks so odd that the the first though was of a software bug that might find a quick fix. However as a similar effect is found with other meters too  - this "feature" looks more like part of very old software at the heart of the measurement system, that might not be changed so fast.

[niner_007]

The script is a kind of workaround at the costs of higher noise for shorter time scales. In addition the timing is a little different (slightly slower). Depending on the application this can help, though an upgraded ("fixed") software in the DMM would be better (lower noise) and easier to use.

The allan deviation curve looks so odd that the the first though was of a software bug that might find a quick fix. However as a similar effect is found with other meters too  - this "feature" looks more like part of very old software at the heart of the measurement system, that might not be changed so fast.

thank you; and that all in the context of the AZ implementation, correct?

[Kleinstein]

We don't know for sure, but the likely cause of the extra noise for the 10 s time scale is likely due to the AZ implementation. The script for the workaround also supports this.

My suspicion is that they use some kind of filtering on the zero readings used in AZ mode. So instead of simply using the last zero reading the suspicion is that some kind a average zero reading from the past 10-30 seconds is used. I also have a faint memory (was some 20 years ago I used one) of such a description in one of the older Keithley meters (like 196) to do it like this, but I could not find it in the manuals.

This sounds like a good idea at first because it would hide much of the white noise if the zero reading. However the downside is that the 1/f noise in the time frame for averaging is no longer suppressed. Depending on the noise spectrum this might have been OK with the old (lower resolution) meters with high white noise, but for the DMM7510 and most other modern ADCs  this is a really poor choice.

Let's hope they get this one fixed when they bring out an DMM85xx - it at least would make it much easier to get 8 digit resolution, when you get about a factor of 2-4 improvement from a simple software change.

[maxwell3e10]

I have slight hope that the autozero problem is fixed in DMM6500, but wouldn't hold by breath. If it has as low noise as DMM7500 and the only difference is in the voltage reference, it would be a great meter.

In general, I think they are putting more effort into a nice user interface than into the intricacies of analog design. And it makes market sense, it's both easier to hire engineers who can design apps and easier to sell meters based on shiny interface than on obscure specs. Even on eevblog  there are more posts about "noise" as in fan noise instead of actual electrical noise. So, as someone else had said here, its not obvious that a meter rivaling HP3458 will ever be build.

[niner_007]

We don't know for sure, but the likely cause of the extra noise for the 10 s time scale is likely due to the AZ implementation. The script for the workaround also supports this.

silly question, what if you turn AZ off and don't use it at all?

[maxwell3e10]

silly question, what if you turn AZ off and don't use it at all?

Look at reply #3 in this thread. Basically, the autozero algorithm behaves as if it's not even used until about 30 sec, while the 1/f noise of the meter is such that it would benefit from autozero after 1 sec.

[niner_007]

silly question, what if you turn AZ off and don't use it at all?

Look at reply #3 in this thread. Basically, the autozero algorithm behaves as if it's not even used until about 30 sec, while the 1/f noise of the meter is such that it would benefit from autozero after 1 sec.

is the noise because of the drift? if you have a super stable environment, would it still happen? so after AZ is ran, it starts to drift until you run it again? basically constantly drifting?

[kj7e]

AutoZero corrects offset voltage drift from the input gain and A/D stage.  These drifts happen to all DMM's including the 7510, 34470, or the 3458.  The AZ function switches from the input signal to an internal short or known zero to calibrate the zero offset.  The issue with the 7510 seems to be how and when the AZ happens.  Its not a major issue (IMHO), just appears not to work as well as it should and it shows up as some extra front end noise.  It is a concern, especially if it could be better optimized in software.  So far Keithley has not made any public comments on this, so its possible it's not an easy task.

It would not matter how stable your environment is, you cant stop the internal voltage offset drifts from happening.  See this video which helps explain some of this behavior;

[Kleinstein]

Besides drift the auto-zero function also suppresses 1/f noise of the ADC and input amplifier (the part included in AZ function).
For some reason this does not work well with the DMM7510 until some 0.02 Hz.  Especially with a higher grade DMM were the ADC is not adding much white noise this giving away some possible performance.  For many applications it is not a problem,  more like a negative surprise as the performance to something like 100 PLC or with external averaging is way lower than what is expected from the 5 PLC specs. Its kind of the step from barely 7.5 digit resolution to nearly 8 digits that is given away due to some odd software.

I don't have much hope to get it fixed with the DMM6500 - the problem is more like some old tradition carried on for to long and not need to change this for 6 digit performance.  I have more hope if they want to bring out an 8 digit version that they might realize it would help to suppress 1/f noise.

[PA4TIM]

new 7510 , first hour of use a BSD.
Firmware rev 01.06.4C,
faultcode: PC=0012D6F8

I was in the continuity function, pressed MENU and the screen got blue.

OT: Great meter, I really like it. For me the speed, the sampling part (even better as I hoped), the dry circuit ohms, the nOhm-Gohm , pA resolution and the easy user interface are the winners but I do not know if I like the continuity and diode functions.
2 functions that are very important for me.  (I really like the continuity from my 2000)
Continuity is fast enough but it latches much to long and the beep sounds like a mix of bird with a cold and a choked mouse.
Diode test has two levels and a beep (the same choked mouse), what is great on its own but not for my use. (component level repair work) My Agilent beeps once for a diode and stays beeping on a short so I do not have to look to the screen. The 14V is also great but not always for use in situ.

[PA4TIM]

Today the continuity stalled the meter. I changed the limit to 1.5V . I could change to the function screen but when I pressed another function the round in progress thingy showed up and stayed. I had to re-power it.

I still like the meter, it is so comfortable in use. I normally have a handful of meters powered up so I do not need to switch functions, but it is a bit sick a meter in this class after 3 years still has bugs. My Siglent scopemeter has some too but not in a way it stalls and need a repower cycle (and is probably the cheapest isolated scopemeter on the market)

[maxwell3e10]

Yes, I have seen it hang up with various less frequently used features, like temperature in my case. I think they managed to get the bugs out for the most common voltage and current measurements, but other may still not be tested thoroughly. There is a Tek forum devoted to this topic: https://forum.tek.com/viewforum.php?f=363
If you post there, they will try to reproduce the problem and maybe it will get fixed in the next FW update. Not sure why we have to do their work for them, though.

[MegaVolt]

Firmware rev 01.06.4C

I got a freezing part of the interface working only with a touchscreen.

https://youtu.be/Rvf8-_G8208

[kj7e]

New 7510 Firmware v1.6.7c now available,;
https://www.tek.com/digital-multimeter/dmm7510-software/model-dmm7510-firmware-revision-167c-and-release-notes
 

[MegaVolt]

New 7510 Firmware v1.6.7c now available

Thank!!!

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

The file with the data is attached.

Emissions are not large and fit into the instrument specification. But they look like some kind of problem May be software.

FW 1.6.4

[dr.diesel]

New 7510 Firmware v1.6.7c now available,;
https://www.tek.com/digital-multimeter/dmm7510-software/model-dmm7510-firmware-revision-167c-and-release-notes

2450 also!

[MegaVolt]

And here's another oddity:

This voltage jumps when the input resistance changes on the ranges of 0.1V and 1V at 1NPLC

Moreover, for a range of 0.1V, the jump is 6 µV or 60 ppm.

AutoZero can be in any condition.

The input is shorted.

Does anyone else see this?
Or is it a marriage?

[maxwell3e10]

Its also surprising that the noise is dramatically higher on the 10 Mohm setting. I have actually seen something like that, but it was not reproducible, sometimes the noise would not increase. So, its not a mirage, its a ghost.

[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.

[suntar]

MegaVolt, thanks,
TSP/SCPI interface seems to be broken:   only *idn? command gets answer, others return either an empty string or timeout.
for example,
==
loadscript test
print(localnode.model)
endscript
test()
==
returns nothing. 

Also, people in our lab have an idea that previous firmware upgrade to 1.1.0s  version  could be done improperly, like 1 time instead of 2 in a row. It was long time ago and we can not check this nowdays.
The unit was working fine with this 1.1.0s, except real buttons.

[HighVoltage]

Also, people in our lab have an idea that previous firmware upgrade to 1.1.0s  version  could be done improperly, like 1 time instead of 2 in a row. It was long time ago and we can not check this nowdays.
The unit was working fine with this 1.1.0s, except real buttons.

You can always downgrade to an older FW version and see if the problem persist.

Lately I have no more problems with my DMM7510, it is very stable.

[suntar]

>You can always downgrade to an older FW version and see if the problem persist.

That's probably what I need.  But how do I do this  if screen is not working anymore? 

[HighVoltage]

It seems more like you can not do this yourself.

I would call them by phone.
The Keithley staff in Munich / Germany is very helpful on the phone.

[bson]

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.

Don't they have a scripting language to create apps like this?  How hard can it be to put one together?

Can apps be controlled using SCPI over LXI?

[Sparky]

@HighVoltage, since you have some Keithley equipment too I just wanted to point out this problem I've discovered with the 2450.

I wonder if you can verify, perhaps with your 2460 also?

[HighVoltage]

Since the last few years and latest firmware update I had no more problems with either one of my Keithley's

I posted my results in the other thread

[YetAnotherTechie]

Since the last few years and latest firmware update I had no more problems with either one of my Keithley's

I posted my results in the other thread

Bad screen on the top right instrument?

[HighVoltage]

Bad screen on the top right instrument?

No, the refresh rate of the DMM7510 is so fast that the camera was too slow.