New Keithley DMM6500 and now DAQ6510

[Kleinstein]

The 3 A range would not see much protection from the diode bridge. The shunt for the 3 A range would be somerhing like 20 or 50 mOhms, so even with 30 A this would be only some 600-1500 mV. The Diode brigde is more to protect the smaller ranges. The critical would be the next with something like an 1 Ohms shunt. This may get quite hot with a higher current before tripping the fuse.


U32 is likely some logic chip like 4094 to provide more control lines. The additional wire could give the HW more control to switch the photo-mos schwitch independently from the relais. This may help reducing wear on the relay contacts when switching (e.g. 1000 V and 10 V range) under high voltage conditions.

[Hydron]

The 3 A range would not see much protection from the diode bridge. The shunt for the 3 A range would be somerhing like 20 or 50 mOhms, so even with 30 A this would be only some 600-1500 mV. The Diode brigde is more to protect the smaller ranges. The critical would be the next with something like an 1 Ohms shunt. This may get quite hot with a higher current before tripping the fuse.

1A/3A shunt is 100milliohms, so would hit 2 diode drops at ~14A, still quite a bit of power (~20W), but this is all assuming that the 3A fuse is arcing over, so you'd assume the 3.5/11A HRC one would go open in short order.

Note that the max burden voltage spec on the 1A/3A ranges is awful - 1.7V at 3A, obviously mostly due to the resistance of 2 fuses in series (and add another half volt for using the rear terminals). If the 11A fuse is safe and drops it down a bit then it would certainly be welcome. Before people run off and buy a 34461A because of this, the Keysight meter is even _worse_ at 2V burden (though it has the major advantage of putting the 10A input on the front, and they basically tell you to ignore the 3A range unless you need it for 34401A compatibility - use the 3A input for <1A, and 10A for >1A).

[maxwell3e10]

If there is a hardware revision, I wonder if it will be possible to fix the problem discussed on page 25 of this thread (reply 600 on), which has to do with undesirable interaction between current shunts and the high voltage 1:100 divider. When current is passed through current terminals and a voltage is measured at the same time, it has an offset of 10-20 mV. This is largely unavoidable. But when the voltage range is set to 100 or 1000V range, the offset becomes several volts! Other meters don't have this problem.

[maxspb69]

To keep the offset at 20-30mV, use the 10A terminal on the rear panel to current measure. In this case, even in the 100V and 1000V range, the V-offset remains about  20-25mV for 1A.

[maxspb69]

If you get the chance, could you check what U32 is? (I assume you've put it back together though, I am not asking you to open everything again!). Also would you be able to check the burden voltage of the 3A range at say 1A (source 1A from a PSU, measure voltage across the input terminals of the DMM). Would be interesting to compare with a 3.5A fused instrument.

[Hydron]

Thanks, makes think it might be what maxwell3e10 is suggesting. Also good to know the 10A input doesn't suffer the offset issue - I suspected this was the case due to the use of a remote shunt but nice to have a confirmation. Did you ever do the offset test with the 3A input on your "improved" unit?

[voltsandjolts]

Who makes those DG444 analog switches? I don't recognise the logo.

[Kean]

Who makes those DG444 analog switches? I don't recognise the logo.

Vishay Siliconix.  I was also wondering and so I did a Google image search on "siliconix logo" to confirm,  It looks awful when laser etched.

[maxspb69]

Did you ever do the offset test with the 3A input on your "improved" unit?

Yes. My device behaves exactly like everyone else in this case when using 3A terminals. When using 10A terminal, the offset does not depend on the  range and is about 25mV per 1A.

[voltsandjolts]

Maybe folks are aware of this but maybe I've found a bug.
On latest firmware 1.7.5b
Measuring on 10V range (manual ranging) record some data, then go overrange (and stay there a while).
The sample buffer fills up very quickly and within about 30 seconds it loops around and all your data from before the overrange event is gone.
100K buffer, NPLC 2, continuous triggering, 10Vdc range...probably similar behaviour on other settings, haven't tried.

You could say its not a bug, the overrange sample just happens in a fraction of the time that a normal in-range sample does.
But I would prefer when at a given NPLC, all samples (even overrange) have the same memory recording interval.
Or would that break somethng else I haven't thought about?

Anyway, it's something to be aware of if you are datalogging on manual range - don't go overrange!

[KedasProbe]

I have 1.7.3c

I couldn't really see the same thing you describe the time steps stay the same.
I tried 1V and 10V 1PLC (no zero) and if I graph the buffer on the DMM6500 or in CSV the time scale is correct.
with a 50% duty cycle I had an equal amount of overflow (9.9E+37) as normal measurement points

And this screenshot is also an example about how their raster choice deserves a facepalm. 

[voltsandjolts]

Hmmm, yeh, it seems there is some funky combination or sequence to get into that 'fast buffer fill' state.
I couldn't reproduce it until I switched to MANual trigger and then back to CONTinuous trigger, go in and out of overflow, then it seems to do it quite readily.
I'm not complaining, I really like this meter, this is just something minor and overall the firmware has improved a lot since the early days.

How is your build of the mux card coming along?

[Joel_l]

Where are you finding FW 1.7.5? Last version I see is 1.7.3.

Joel

[KedasProbe]

1.7.5 was mentioned before in this thread, I will need to update before using my scanner card.
https://www.tek.com/sitewide-content/software/m/o/d/model-dmm6500-firmware-revision-175-and-release-notes

How is your build of the mux card coming along?

I have all the parts for 2 cards, assembly is on the to do list.

[rej]

The KickStart software gives me an error (something like "can not connect") when I try to connect to my DMM6500. I use the latest firmware 1.7.5 and the latest Software 2.4.0. I connect the multimeter and the laptop with a LAN cable. The communication with the web interface works fine. KickStart detects the multimeter, but throws en error, when I try to connect to the device. Some time ago everything worked without a problem, but I can't remember which firmware/software I used.

Is there anyone else who has this problems?

[skander36]

For me is not working at all. It start see the DMM and immediately close without any warning or error.
LabView work with him without any problem.
Using last  fw.

[Mike G]

Just wanted to say a big thank you to E-Design and the service team at Keithley in Munich, Germany.
Having had problems for a couple of years, which I had thought were firmware issues but updates failed to solve, E-Design examined the symptoms and suggested it was most likeley a hardware issue.  He set the ball rolling and the service manager at Keithley Munich contacted me with an RMA number. From there on the meter was shipped back to Germany by Keithley, repaired in two days and then couriered back to me with a total round trip time of 7 days   and this was from and back  to Cyprus, amazing, and under the three year warranty.
So far the meter has been absolutely perfect, I am still learning something new every time I use it, what a piece of kit
The icing on the cake was that it came back with a 10 page calibration certificate and report, now I can see for myself that these meters don't just meet their specs, they blow them into the weeds
All in all one very happy customer, trying to justify a SMU now to keep it company
Thanks again E-Design and team

[KedasProbe]

Version 1.7.7 is released with 2 fixes:
NS-2025
Symptom:While running a test loop in an application that sends the reset()command as part of the code, a blue screen appears after running the test for several days.
NS-2043
Symptom:While remotely communicating with the instrument, if a new error is displayed on the front panel shortly after a previous error is being cleared from the front panel, the instrument may become unresponsive or inoperative.
https://www.tek.com/sitewide-content/software/m/o/d/model-dmm6500-firmware-revision-177-and-release-notes

[Mike G]

If anyone is interested I have improved the power reading script.
Just change the file extension back to .tsp and should be fine.
I accept no liability for it's use, just for fun or improvement.

[KedasProbe]

I was wondering if the power measurement script could be using CONTINUOUS buffers with buffer.fillmode = buffer.FILL_CONTINUOUS (instead of readings for 1 to 500)
This way it would be running until you want it to stop and remembers the last 500 readings. (like the default buffers do)

[Mike G]

Yes, no reason why not, the basic script is there for anyone to adapt to their own ideas.  The screen shot just is an example that was running when I "snapped" it.
If you run it yourself you will find that in the  "Change Setup" menu the shunt value, shunt power rating, number of readings, delay between readings and Filter on/off may be specified and any change are updated on the "Current Setup" part of the swipe screen. Also while the script is running the other swipe screens are available for more information, stats, graph etc.
Default start up values are in the script and can be easily edited for individul preference, my shunt is 1.157 ohms so that is the default
Currently exploring an elegant way of pausing, restarting or exiting the  loop that takes the readings

[Mike G]

Ok I admit being baffled   Please can someone throw me a lifeline?
In a For i=1, readings  Do loop in the power read script I am trying to give an option to cancel the readings before the set number is reached.  I have made the START button change to a STOP button once the reading loop starts, have made the function called by the button activate RESET().  On pressing STOP during a readings run nothing happens until the number of reading set has completed and only then does the RESET() run. It seems as though the button press is seen and logged but the command does run until the end, does anyone know anything that may help explain why this happens and, more importantly, suggest a way round this please
If I have posted this in the wrong place I apologise.
Thanks, Mike

[KedasProbe]

Maybe setting it to manual trigger will stop the loop, so it will not be the stop button but still stop it.

[Mike G]

Morning Kedas Probe, a worthy suggestion but, sadly, one I have already investigated.
It seems as though the meter sees the STOP button press but does not act upon it until the loop has completed. I have substituted a WHILE loop and put the button action within that loop and tested its condition at the end of each loop round, it still will not break out of the loop.  I have proved that the button press is seen during the loop but is then stored until the loop finishes and then performs the function. Is this to do with interrupts?  I am an ageing, old school hardware engineer so this software business is a very steep learning curve for me. To give you an idea of what I mean, when I learnt my trade semiconductors were the new things in town.
Regards Mike

[simsys.pl]

Hi everyone,
I have tried to write some script to improve/repair awful default diode test. My script works as on good old flukes (e.g. model 45) - as old as me probably

Here is what script can do:
-one beep: when you are in range (0,25V..0,8V).
-no beep: when you are above,
-contstant beep: when you are below.
-frequency for sound is 2kHz (not this original shitty sound).

All seems to be fine when script is running BUT I observed some really big problem: after switch-off script and go to regular mode e.g. voltage measuring all is ok. When I switched-on script again meter became unusable. Sometimes is just one sequence on-off-on, sometimes two when unit is stop responding. The only rescue is reboot unit.

Could one of you can confirm this? Please find tsp file in attachment.
I thought that in my script some routine at the end like "reset buffer on exit"  is missing however I dint find something like this.
What is wrong?