New Keithley DMM6500 and now DAQ6510

[JxR]

Does the C revision have the hardware issues discussed in this thread fixed?

I think the Keithley rep implied that it required a hardware revision to fix.

[Mr. Scram]

I think the Keithley rep implied that it required a hardware revision to fix.

I was under the impression that this is a new hardware revision.

[JxR]

I think the Keithley rep implied that it required a hardware revision to fix.

I was under the impression that this is a new hardware revision.

No, it's just a revision of the calibration manual.

[Mr. Scram]

No, it's just a revision of the calibration manual.

My mistake. 

[KedasProbe]

FYI about my failed firmware update to 1.7: they suggested to try again.

I booted it cold with a new stick with only 1 file on it and now it worked, so problem solved I guess.

[drummerdimitri]

Does anyone know how to measure both Voltage and Current properly?

I was able to do so without any relay switching (2A and 12V or so) expect either the current or the voltage would have to be negative.

Is there a way to display both values as positive ones?

[cozdas]

Gah! I missed the firmware update. It's not showing up in their web page under the usual section and I wasn't keeping an eye on this thread. Just updated my unit and pleased to see that Keithley implemented my suggestion for the graph Y axis and improved the auto-scale for human readability. Now it's much easy to monitor stabilities etc. Thumbs up.

I also noticed that the nasty bug that "user-added swipe screens crashes the system upon app-close" is now fixed. Now I can resume working on some tools and scripts. I know that the crash issue along with some others were fixed long time ago but apparently they are not found of frequent bug-fix releases, and holded those fixes until this one big update. Better late than never I guess.

While you're on it, can you also please make sure that the graph Y axis numbers show the informative, distinct digits rather than the common thus non-informative ones? Check the attached images: here the Y range is less than 100uV though in the current implementation Y axis numbers show the 10mv, 1mv and 100uV digits, totally missing the important part. Something like the second image is what I'd expect to see.

[cozdas]

Hmm. Actually their implementation is slightly different from mine, if min and max values differ in the first few digits, it switches back to a mode similar to the old behavior, thus making the y-axis labels useless again. I guess that they wanted to avoid the confusion of having ...999 below the 10.000... header, as it might be perceived as 10.000999 instead of 9.999999 but in my opinion it's not a big deal and having useful labels is much more important.

(Below images have the same scaling, just different y offset values.)

[KedasProbe]

Hmm. Actually their implementation is slightly different from mine, if min and max values differ in the first few digits, it switches back to a mode similar to the old behavior, thus making the y-axis labels useless again. I guess that they wanted to avoid the confusion of having ...999 below the 10.000... header, as it might be perceived as 10.000999 instead of 9.999999 but in my opinion it's not a big deal and having useful labels is much more important.

(Below images have the same scaling, just different y offset values.)

Just adding an extra grid line in orange with an 10.000 label would also take away the confusion.
And when they have finally done that they can try to figure out (I know it's easy) to make that orange grid line fall on top of a white one.
I'm still surprised by the limited creativity or know how to solve things like that.

[HendriXML]

I used a script that interacts with a triggermodel on the dmm, just like before, but now doing simultaneously the "exact" same reading with a scope.
https://www.eevblog.com/forum/testgear/battery-charging-using-a-siglent-sds1104x-and-spd3303x/msg2842750/#msg2842750
One thing that would be nice if there was a way keep the auto zero off, and do a "zeroing" somewhere in the trigger model, so it doesn't delay the actual measurement. Using the scpi command which does that is not allowed with a running trigger model. Imo it should have an action block for it.

[JxR]

I used a script that interacts with a triggermodel on the dmm, just like before, but now doing simultaneously the "exact" same reading with a scope.
https://www.eevblog.com/forum/testgear/battery-charging-using-a-siglent-sds1104x-and-spd3303x/msg2842750/#msg2842750
One thing that would be nice if there was a way keep the auto zero off, and do a "zeroing" somewhere in the trigger model, so it doesn't delay the actual measurement. Using the scpi command which does that is not allowed with a running trigger model. Imo it should have an action block for it.

Section 13
pgs 98-99
[:SENSe[1]]:<function>:AZERo[:STATe]

VOLT:AZER OFF   (Turn auto zero off)
VOLT:AZER ONCE  (Perform a single reference measurement)

[HendriXML]

I used a script that interacts with a triggermodel on the dmm, just like before, but now doing simultaneously the "exact" same reading with a scope.
https://www.eevblog.com/forum/testgear/battery-charging-using-a-siglent-sds1104x-and-spd3303x/msg2842750/#msg2842750
One thing that would be nice if there was a way keep the auto zero off, and do a "zeroing" somewhere in the trigger model, so it doesn't delay the actual measurement. Using the scpi command which does that is not allowed with a running trigger model. Imo it should have an action block for it.

Section 13
pgs 98-99
[:SENSe[1]]:<function>:AZERo[:STATe]

VOLT:AZER OFF   (Turn auto zero off)
VOLT:AZER ONCE  (Perform a single reference measurement)

While a trigger model is running that command is not allowed. Like (i assume) most SCPI commands.
Because of that, the trigger model imo should support it.

[Kleinstein]

The problem with zeroing may be more than just a software problem. I would expect a principle limitation from the hardware side: while the zero reading is running this would still need to complete (thus some 20ms). Even if aborted faster it would cause some delay - for a multi-slope ADC it just takes some time to restart. An extra abort of conversion would likely need low level support, so a more difficult part. So I would consider the 20 ms (16.x ms with 60 Hz) the minimum delay one has to expect.

Depending on the application this may be acceptable.
 

[HendriXML]

So I think having it as an action in the trigger model is a safe solution. An auto function imo should have a manual counter part. For my slow measurements it would be a good solution. Now I'm not sure how much the accuracy drifts in an hour or so. In my case it is just a fun experiment, but I can think of situations where it is critical to measure at the exact same time.
Another solution would be to do the auto zeroing after the actual measurement as an option, but doing that manually would be preferable.

[Kleinstein]

Depending on the actual HW used in the ADC, in non AZ mode there can be quite some drift and also low frequency noise (from the OPs, but also the resistors) that is suppressed with the zero reading. So it is not only about hours but already seconds can make a difference. So if time permits the zero reading can be really helpful. Doing the zero reading just after the actual signal could be a really good solution, if one can live with the extra delay for the result. However I am afraid this could be too close to the basics to be supported in the current software - so it may need a updated software. Ideally there would be different versions of the auto zero mode to choose: zero before signal, zero after signal and the current version that is likely doing some interpolation / extrapolations on the zero readings over some time frame.

The zero reading seem to be a tricky topic in the Keithley meters. It looks a little like some of the extra noise seen at the 10 seconds time scale is due to a not so good solution in doing the zero readings or taking the readings into account. This is kind of effecting the very basics of the meter, but it could be worth to get a better solution there. It may not be top priority with the DAQ6510 but a similar weakness shows up in other meters too - so kind of a legacy weakness, possibly dating back to the K2001 or even 19x times.

[cozdas]

I was planning to build a DIY Solid state, 10-chan SCAN card (so that I can collect data during the night at home without the dripping tap simulation), but since DMM6500 seems to drive the 20-chan card I changed my design to double the channels (the more the merrier).

I'll let you know if I hit a problem with the DMM6500 behavior,

It's alive!!!!

I still need to buy more solid-state relays to populate the rest of the board but what's there seems to work flawlessly (so far), silent and fast. Since I was trying to keep the cost as low as possible (you can tell from the all DIY PCB board), the relays are not the best, the on state resistance of each channel is around 2 Ohm. But it's not a big deal as I have plenty of channels to use kelvin connections if needed. A $12 Atmega32u4 based board is handling all the logic.

(top board: Keithley 2000-Scan with wires attached for protocol sniffing)
(bottom board: DIY 20-chan solid state scan card)

I just released the details of this project here for anyone interested in.

Enjoy

[drummerdimitri]

I have unfortunately plugged my meter on the 3A front current terminal directly to 220V AC by mistake and it has blown the internal 3.5A fuse but upon its replacement, I am getting a 0.7 A current reading without anything connected t o the 3A terminals (front and rear.)

I tried testing the rear 10A input and that still works fine so not sure what damage that might have caused.

Why did the damage occur in the first place? This is a common mistake and shouldn't damage such a DMM.

What to do now? 

[Kleinstein]

The fuse may not allays be fast enough to brake the current path, before doing damage. Beside the high current spike the spark in the fuse could cause trouble from RF interference. Ideally there should be no permanent damage except for the fuse, but it is definitely stressing things.

I first check would be so see if there is still connection in the 3 A range (e.g. a blown shunt or trace).
It could also be worth checking the very low current ranges (e.g. 100 µA).
The next step would than likely be a visual inspection to see if there is visible damage (e.g. blown trace). One could also measure (with a second meter) if there is actually a voltage aver the chain of shunt resistors.

If nothing visible it would likely be time do to some reverse engineering to see which chips are used for the current ranges. As the 10 A range and likely voltage are still working OK, the damage should be quite close to the input side of the current ranges: something like the OP for bootstrapping the protection, MOSFETs used for switching between shunts or the first CMOS switch or amplifier to see the shunt voltage.

[drummerdimitri]

The fuse may not allays be fast enough to brake the current path, before doing damage. Beside the high current spike the spark in the fuse could cause trouble from RF interference. Ideally there should be no permanent damage except for the fuse, but it is definitely stressing things.

I first check would be so see if there is still connection in the 3 A range (e.g. a blown shunt or trace).
It could also be worth checking the very low current ranges (e.g. 100 µA).
The next step would than likely be a visual inspection to see if there is visible damage (e.g. blown trace). One could also measure (with a second meter) if there is actually a voltage aver the chain of shunt resistors.

If nothing visible it would likely be time do to some reverse engineering to see which chips are used for the current ranges. As the 10 A range and likely voltage are still working OK, the damage should be quite close to the input side of the current ranges: something like the OP for bootstrapping the protection, MOSFETs used for switching between shunts or the first CMOS switch or amplifier to see the shunt voltage.

So pretty much all the 3A connection shunts are not working and there is no visible damage on the board whatsoever.

Voltage and 10A remain fully operational.

I'm not qualified enough to diagnose the issue and conduct the necessary repairs so does it have to go back to Keithley for that? Bought online from RS components by the way.

[HighVoltage]

I'm not qualified enough to diagnose the issue and conduct the necessary repairs so does it have to go back to Keithley for that? Bought online from RS components by the way.

Keithley would probably make a swap of the main board and not a component level repair.
Would be interesting to know, how much they charge for that.

The repair should be possible and not too difficult.
If you open it up, can you take a few pictures of the input circuitry of the shunts and surrounding area?

 

[drummerdimitri]

I'm not qualified enough to diagnose the issue and conduct the necessary repairs so does it have to go back to Keithley for that? Bought online from RS components by the way.

Keithley would probably make a swap of the main board and not a component level repair.
Would be interesting to know, how much they charge for that.

The repair should be possible and not too difficult.
If you open it up, can you take a few pictures of the input circuitry of the shunts and surrounding area?

Here you go.

[pmcouto]

K7 doesn't look good...

[Kleinstein]

The damage should be one of the more easy repairs, as it should be located very much near the input part.
If not covered by some warranty the repair at Keithley would likely be rather expensive - possibly not worth it, especially as the voltage and ohms ranges still seem to work and shipping may be expensive too.


I don't think K7 is involved. The blob on top looks odd, but this is more like glue to hold the resistor array.

So far I can not see the higher value shunts and identify the relays / MOSFETs used for shunt switching. They may be just left to the fuse under the shield. Only the smallest shunt resistor is visible right next to CR20 (which is the rectifier used to protect the shunts. It is a possible culprit - so one could check the rectifier in circuit for shorts. The DC side of the rectifier could also be a good test point to see which voltage is present there.

[HendriXML]

As once mentioned I have 2 master power switches to turn off all my devices. My scope has a soft power on/off, just like the dmm, but supports a setting like resume on power on, thus starting when the main switch is activated.
The dmm does not have this function, but I know it will resume when it was active before the master switch is turned off.

The question is: is it bad practice to switch it off using only the master switch. I normally do a shutdown of the device as well, but that seems shutdown immediately, so that it makes me wonder if its needed at all. The manual does not really addresses this.
But because it resumes I even think it might be a supported feature. Any idea's?

[MegaVolt]

New KickStart released.

https://uk.tek.com/software/kickstart/2-2-1