New Keithley DMM6500 and now DAQ6510

[KedasProbe]

- Hmm, should unlimited re-tests be allowed?  Was the bad contact just due to it taking a reading while you were still setting up or something else?

For my test I pressed through the isolation of a resistor matrix PCB.
But it should not be an extra retry, maybe if it failed and more than 5? time the tolerance you have to keep measuring up to 2 second before making it a fail, but this issue may fall in the same category of the sample and hold app that sometimes picks-up a reading it shouldn't, (and I will look into that later to improve/fix that)

[KedasProbe]

How can I make it wait for the ok button?
It asks the input field even before I presses ok if no USB drive is present. (multiple pop-ups)

Code: [Select]

--TODO Please insert code here.
if file.usbdriveexists() == 0 then   --
display.prompt(display.BUTTONS_OK, "Please insert a USB flash drive into the front-panel USB port.")    
display.waitevent()
delay(1.5) -- Wait some time for the USB to be mounted
end
if defbuffer1.n >0 and file.usbdriveexists() != 0 then
statsVar = buffer.getstats(defbuffer1)
desciption=display.input.string("Description",display.SFORMAT_ANY)
fileVar = file.open("/usb1/"..desciption..".csv", file.MODE_WRITE)
file.write(fileVar, "Mean:,"..statsVar.mean.."\n")
file.write(fileVar, "StdDev:,"..statsVar.stddev.."\n")
file.write(fileVar, "Min:,"..statsVar.min.reading.."\n")
file.write(fileVar, "Max:,"..statsVar.max.reading.."\n")
file.write(fileVar, "Relative Time, Reading,,"..desciption.."\n")
for i = 1, defbuffer1.n do
    file.write(fileVar, defbuffer1.relativetimestamps[i]..","..defbuffer1.readings[i]..","..defbuffer1.units[i].. "\n")     
end
file.close(fileVar)
beeper.beep(0.1, 1000) -- ready beep
else
beeper.beep(0.5, 100) -- fail beep
end
edit nevermind found it adding waitevent()

Script above to save custom .csv file (and faster, run script by pressing 'No Script' button)

[hwj-d]

KedasProbe:

In the moment I don't know anything about programming the DMM because I still haven't found the time yet. But what strikes me roughly is that you don't query the return value of the button. You don't use the procedure as a function. Forgive me if I am wrong. In other code snippets it looks like this:

Code: [Select]

function set_dci_range()
optionID = display.input.option("Select current range", "1A", "100mA", "10mA", "1mA",
"100uA", "10uA")
if optionID == display.BUTTON_OPTION1 then -- 1A
return 1.0
elseif optionID == display.BUTTON_OPTION2 then -- 100mA
return 100e-3
...
That's just an idea, roughly. Don't know if that'll get you anywhere.

[KedasProbe]

Because there is no option given, only an OK button, hence I know what they pressed, I only need to wait until they are ready to continue.

But maybe I see if I can make it a cancel button and loop detect when the usb drive is ready.
(but this is only when you forgot to plug in your USB drive, so it shouldn't really be used)

[hwj-d]

How can I make it wait for the ok button?
It asks the input field even before I presses ok if no USB drive is present. (multiple pop-ups)

and

Because there is no option given, only an OK button, hence I know what they pressed, I only need to wait until they are ready to continue.
...

You only call the ok-button to display, but don't ask when it is pressed, if I understand you correctly. So, option should be "button pressed".

(edit)
something like this:

Code: [Select]

promptID, result = display.waitevent()
...
display.prompt(display.BUTTONS_OK, "some text")
promptID, result = display.waitevent()
 if result == display.BUTTON_OK then
 ...

[KedasProbe]

The display.prompt and display.input.option works a little different for the 'input' one it will wait but for the prompt you have to ask to wait apparently.

Can be a good thing if you just want to give some info on the screen but while the measurement is still going.
like display.prompt(display.BUTTONS_OK, "Now is a good time to go get a coffee, it will take a while.")   

this is from the manual:

display.waitevent()
This function causes the instrument to wait for a user to respond to a prompt that was created with a prompt
command.

You can also check which button was pressed but since there was only one I didn't wrote if result==display.BUTTON_OK then because this will always be true.

[hwj-d]

Yes. I once ventured out because I believe that synergies in the Forum will develop as a result, not that someone have to be right. 

Your problem sounded to me like display.waitevent() is triggered by other events too. The correct react to a BUTTONS_OK event is of such a fundamental nature that there should be no problems at all. If someones own code doesn't act as expect, it usually helps to play around with alternatives. Once have found something that works, someone should reduce and optimize it back to the core.

[Brad O]

Hey KedasProbe, can I put that script on our GithHub repo for you?  I also see a couple small improvements I can make.

[cozdas]

Which reminds me, unfortunately the release of the next firmware has been delayed until the end of May.  The team was really hoping to get it out by the end of March but it just wasn't ready with all the features we wanted in it.

Hi Brad,
Is the new firmware getting closer to release? I'm looking forward to seeing the crash bugs with the user added swipe screens be fixed so that I can start implementing few ideas.

[JxR]

I'm showing a significant voltage drop in the 100V range when doing a simultaneous measurement of voltage and current.  Could anyone else confirm this:

Voltage Range: Auto or 100V, with an input voltage greater than 12V
Input Z: Auto
Current Range: 3A  (the drop is more severe the higher the input current).
I was using the front panel.

I'm seeing drops in voltage close to 50% of the input voltage, which doesn't seem right.  Would like to confirm if it is my unit or a bug. Look at the last half of this graph and see what I mean when I changed the voltage from 12V to 13V back and forth on my powersupply (Green is voltage). Going from 12V to 13V does a range switch from 10V to 100V (Auto mode).  I don't see any issues in the 10V range.  I sent a PM to Brad, but would like to see if anyone here can reproduce this.

[imagiko]

Hi All -
I just wanted to jump in on this thread as it looks like we have someone from Keithley helping out.
I work with low power BLE/WiFi devices, where current range needs to be dynamic (usually switching between uA to mA). I would like to record these measurements at a fast rate(enough to catch the current transients). To preface, I am not exactly an electronics guy so pardon my limited knowledge.
It looks like the 6500 might be suitable, but I am not entirely sure. I have been reading about burden voltage while measuring these current transients, so how will 6500 fare when making such measurements? I hope someone can pitch in to provide feedback. There is also 7510 that is being discussed, but that is almost 3 times the price of 6500.

[JxR]

Here is the chart from page 10 of the datasheet.  It lists the burden voltages for each range.  The 7510 is much better for this particular spec, but it is also quite a bit more expensive.

[imagiko]

So 6500 has upto 170mV burden voltage for upto 10mA range and 7510 has upto 15mV. How to gauge how low is "good enough" for dynamic current measurements, since lower is obviously better?

[JxR]

So 6500 has upto 170mV burden voltage for upto 10mA range and 7510 has upto 15mV. How to gauge how low is "good enough" for dynamic current measurements, since lower is obviously better?

That is just going to depend on your circuit and possibly where you take your reading.  Say your device runs on a battery, and after that battery is some kind of voltage regulator.  If you take the reading between the battery and the voltage regulator, and your regulator can still provide an acceptable voltage to your circuit regardless of the voltage burden, it might not matter at all.

If you take your measurement after the voltage regulator and your circuit cannot handle a voltage drop of 170mV, and the voltage regulator cannot compensate for the drop of that level, then maybe it matters quite a bit.  Unfortunately I think that is something only you can answer, and the answer could change from circuit to circuit. 

For me, it doesn't matter enough to justify the price difference atm.  It is good enough for me, only you can answer if it is good enough for you.  I still would like to have a DMM7510 though.  If this is a important business decision or something along those lines, then maybe you should contact Keithley to see if you could demo both models.

[Kleinstein]

The burden voltages for the 6500 are about in the normal range. The numbers are upper limits and include the switch resistance so the actual drop may be a little lower. So I would expect some 100 mV for the shunt and the rest from the switch and fuse.

Only the high burden in the 3 A range is odd and makes me worry a little. Much of this would be from the fuse - this is the downside of the HRC fuses used relatively close to the limit. Still it could be quite some self heating effect and thus possible linearity limitations in the 3 A range. One may get better accuracy (especially linearity) in the 10 A range above some 1 A.

The very low burden for the 7510 in the low current ranges is due to using a TIA and not just a shunt. A few meters, but not that many use this for low currents.  With a TIA the actual impedance is inductive (how much depends on the details) - in some circuits this can be a problem, so the low burden can be a little misleading.

[MegaVolt]

The very low burden for the 7510 in the low current ranges is due to using a TIA and not just a shunt.

I suspected that, but I did not see official information anywhere. Do you have any document?

[Kleinstein]

The very low burden for the 7510 in the low current ranges is due to using a TIA and not just a shunt.

I suspected that, but I did not see official information anywhere. Do you have any document?

Only a strong suspicion, based on the data - it gets very hard to impossible to get that good performance with just with a very small shunt.  A TIA makes absolute sense for the small currents, below some 100 µA. In the 10 mA range it's possibly though not that attractive due to self heating of the sensing resistor.

[KedasProbe]

Hey KedasProbe, can I put that script on our GithHub repo for you?  I also see a couple small improvements I can make.

Sure, but i changed the code:
I noticed when you add these headers the DMM6500 does sees the .tsp as a .tspa and puts it in the application list instead.
So you need to delete the first 3 lines to use it via 'No Script'.

Code: [Select]

-- $Title: Save Measurement with Statistics
-- $Product: DAQ6510, DMM6500
-- $Description: Save default buffer (defbuffer1) with basic statistics info
if file.usbdriveexists() == 0 then   --
display.prompt(display.BUTTONS_OK, "Please insert a USB flash drive into the front-panel USB port.")    
result = display.waitevent()  -- result isn't used, always button 'ok'
loopcount = 0
while (file.usbdriveexists() == 0 and loopcount<8) -- Wait up to 4 sec for the USB to be mounted after 'ok'
do
loopcount = loopcount + 1
delay(0.5)
end
end
sep=","  -- separator ',' used in the csv file.
--sep=" " --tab may be preferred.
if defbuffer1.n > 0 and file.usbdriveexists() != 0 then
statsVar = buffer.getstats(defbuffer1)
description = display.input.string("Description",display.SFORMAT_ANY)
fileVar = file.open("/usb1/"..description ..".csv", file.MODE_WRITE)
strunit=defbuffer1.units[1]
file.write(fileVar, "Relative Time"..sep.."Reading ("..strunit..")"..sep..sep..description .."\n")
if defbuffer1.n > 4 then
starti = 5
file.write(fileVar, defbuffer1.relativetimestamps[1]..sep..defbuffer1.readings[1]..sep..sep.."Mean:"..sep..statsVar.mean.."\n")
file.write(fileVar, defbuffer1.relativetimestamps[2]..sep..defbuffer1.readings[2]..sep..sep.."StdDev:"..sep..statsVar.stddev.."\n")
file.write(fileVar, defbuffer1.relativetimestamps[3]..sep..defbuffer1.readings[3]..sep..sep.."Min:"..sep..statsVar.min.reading.."\n")
file.write(fileVar, defbuffer1.relativetimestamps[4]..sep..defbuffer1.readings[4]..sep..sep.."Max:"..sep..statsVar.max.reading.."\n")
else
starti = 1
end
for i = starti, defbuffer1.n do
    file.write(fileVar, defbuffer1.relativetimestamps[i]..sep..defbuffer1.readings[i].. "\n")     
end
file.close(fileVar)
beeper.beep(0.1, 1000) -- ready beep
else
beeper.beep(0.5, 100) -- fail beep
end
edit: I made a pull request on github

[hwj-d]

result = display.waitevent()  -- result isn't used, always button 'ok'

 

[windsmurf]

KICKSTART 2.1.0 released
https://www.tek.com/software/kickstart/2-1-0

This might be a dumb question.... but why is Keithley 2700 on the supported list, but Keithley 2000 is not? 

[KedasProbe]

About kickstart 2.1, I see the inconsistency of significant digits displayed itn't fixed, sometime 5, sometimes 7.
But it stored the values correctly so not a big issue it just doesn't look professional.

[Mike G]

Hi Brad, still wondering when you will be releasing information regarding detailed use of the graphics commands for custom screens. ie can you specify the size of an object button to accomodate more text? Can you change the colour of the header text when creating an object swipe screen, if I add a hex colour code in the parameters it errors saying that only three parameters are allowed.

swipe_id = display.create(display.SCREEN_HOME, display.OBJ_SWIPE, 'Extra Data')

So far I have managed to achieve most of the things I need to but reverse engineering existing code can be a long and frustrating task, especially for a new programmer like myself, so any help would be much appreciated.

Is it possible to remove an obj swipe screen as part of a function to restore normal operation when leaving a script? Trying various methods usually locks up the meter.

A weird problem I have encountered when developing scripts is that when power cycling the meter, it does sometimes freeze if it doesn't like the script, it will hang on the Keithley logo, although the power button still works it comes back in the hung condition. I really thought I had bricked my meter but discovered that the way to solve this is to remove the power plug while displaying the logo, wait at least one minute then reapply power and, usually, this then results in a normal power up sequence.  Your comment on why this happens would be welcome.
Thanks for any information you can release, Mike

[cozdas]

Is it possible to remove an obj swipe screen as part of a function to restore normal operation when leaving a script? Trying various methods usually locks up the meter.

Unfortunately this is a known bug in the current firmware, you can't delete a user-created swipe window. If your script has routines to handle the UI messages from the user created swipe window, once the script is terminated the orphan window will crash your DMM (possibly it's trying to call the routines which are no longer in the memory).

Many months ago Brad told that it's already fixed in the development firmware but unfortunately Tektronix/Keithley hasn't released a new firmware since February. I wish their firmware team was using a modern branch/release flow which separates the development/feature branches from the bug-fix branches which would let them release bug fixes without waiting everything to be tied together. They were expecting to ship the firmware in March but it was delayed until end of May and apparently they missed that target too. My 30+yr software engineer hat tells me that "release often" is the way to go but they may have different limitations/ideas/restrictions in their company, who knows.

I stopped developing apps/scripts for the DMM6500 until the new firmware comes as hitting the crash wall multiple times a hour is very tedious and annoying.

[drummerdimitri]

Why isn't Keithley developing apps to be run from the Apps manager? Seems like this feature is going to waste 

I'd love myself a power app instead of running that power script someone posted on here a while back.

[Mike G]

Firstly thank you Cozdas for your information, I too look forward to seeing the new firmware release.
Secondly, hi  drummerdimitri, if you need a more finished version of a power meter script I have one that I have made which is quite easy to use. It allows you to input shunt values, both resistance and wattage (and will warn if you overload it), number of readings with options and a start(repeat)  button. It also displays DUT voltage, shunt voltage, shunt wattage and current on the swipe screen and records all data to three seperate buffers. I am only a beginner at this programming and have managed to create this by reverse engineering parts from various scripts written by others with a few ideas of my own.
I will try to attach a copy to this post. I accept no responsibility if you use it. Don't forget to change the "txt" extension to "tsp" before using, if you have any suggestions  or comments they are most welcome
If you install a script on to the DMM6500 you can select and run it from the home screen by touching the "No Script" logo at the very top of the home screen, this will drop down a list of installed scripts and you just need to touch the one you wish to use, easie than going to the apps menu.