Author Topic: New Keithley DMM6500 and now DAQ6510  (Read 93491 times)

0 Members and 14 Guests are viewing this topic.

Online imo

  • Super Contributor
  • ***
  • Posts: 2234
  • Country: 00
Re: New Keithley DMM6500 and now DAQ6510
« Reply #850 on: December 03, 2019, 09:59:41 pm »
The typical jumps are 4-5uV with LM399H/AH at least here (new original LT).
Periods are ~minutes so it does not matter whether it is 10 or 100NPLC.
PS: All LT's LMs I got are > 7.05V. As Andreas elaborated the best performing LMs are those with around 6.95V made by NS (and probably with less popcorn)..
« Last Edit: December 03, 2019, 10:12:09 pm by imo »
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: nl
    • KiCad-BOM-reporter
Re: New Keithley DMM6500 and now DAQ6510
« Reply #851 on: December 07, 2019, 11:59:55 pm »
Maybe someone can help me with the following. I've created the following trigger model:


A simple (test) loop that waits for the SCPI "*TRG" command to cascade the trigger and do a single measurement.

The idea is to measure with an oscilloscope and the dmm at the same time. Having the DMM executing the loop, but the SCPI client doing the data handling of both devices (dmm: FETCH).

This would be easy if there was a way to let the SCPI client wait for the completion of the measurement.

So is there a solid way to wait for the "new" measurement or poll the status of it?

One way would be to have another wait block after the measurement and check whether the loop is in a waiting state, but that might introduce a delay of 100 ms before that state is set.
Code: [Select]
:TRIGger:STATe?
Waiting: The trigger model has been in the same wait block for more than 100 ms
« Last Edit: December 08, 2019, 12:27:21 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8192
  • Country: 00
  • Display aficionado
Re: New Keithley DMM6500 and now DAQ6510
« Reply #852 on: December 08, 2019, 12:24:12 am »
Any word on when the new revisions that fix the known hardware issues will appear?
 

Offline JxR

  • Supporter
  • ****
  • Posts: 268
  • Country: us
Re: New Keithley DMM6500 and now DAQ6510
« Reply #853 on: December 08, 2019, 03:07:14 am »
Maybe someone can help me with the following. I've created the following trigger model:
(Attachment Link)

A simple (test) loop that waits for the SCPI "*TRG" command to cascade the trigger and do a single measurement.

The idea is to measure with an oscilloscope and the dmm at the same time. Having the DMM executing the loop, but the SCPI client doing the data handling of both devices (dmm: FETCH).

This would be easy if there was a way to let the SCPI client wait for the completion of the measurement.

So is there a solid way to wait for the "new" measurement or poll the status of it?

One way would be to have another wait block after the measurement and check whether the loop is in a waiting state, but that might introduce a delay of 100 ms before that state is set.
Code: [Select]
:TRIGger:STATe?
Waiting: The trigger model has been in the same wait block for more than 100 ms

Your probably looking for something like polling the event registers and generating a SRQ.  Check out Appendix B in the reference manual. 

You could also possibly do the entire thing with the DMM6500 collecting the data from the oscilloscope with a TSP script.  You could connect the trigger out of your scope to the DMM6500 for a sync measurement.  Then send the SCPI command from the DMM6500 to trigger the scope.  If your scope has an ethernet LXI interface, then it can sends SCPI directly from the DMM6500 via a TSP script.  Requires learning lua and the TSP commands though.  If that sounds interesting to you, check out TSP-Net in Section 10 of the reference manual.
« Last Edit: December 08, 2019, 03:32:44 am by JxR »
 
The following users thanked this post: thm_w, HendriXML

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: nl
    • KiCad-BOM-reporter
Re: New Keithley DMM6500 and now DAQ6510
« Reply #854 on: December 08, 2019, 09:39:55 am »
Maybe someone can help me with the following. I've created the following trigger model:
(Attachment Link)

A simple (test) loop that waits for the SCPI "*TRG" command to cascade the trigger and do a single measurement.

The idea is to measure with an oscilloscope and the dmm at the same time. Having the DMM executing the loop, but the SCPI client doing the data handling of both devices (dmm: FETCH).

This would be easy if there was a way to let the SCPI client wait for the completion of the measurement.

So is there a solid way to wait for the "new" measurement or poll the status of it?

One way would be to have another wait block after the measurement and check whether the loop is in a waiting state, but that might introduce a delay of 100 ms before that state is set.
Code: [Select]
:TRIGger:STATe?
Waiting: The trigger model has been in the same wait block for more than 100 ms
Your probably looking for something like polling the event registers and generating a SRQ.  Check out Appendix B in the reference manual. 
That is exactly what I was looking for! It can even do SRQ callback to my SCPI client, so polling would not be needed (which would have cause a lot of network traffic).
Nice to know that the DMM can also do SCPI communications to other devices. But for now I'll be using a scripting tool which I developed myself. The script that needs this stuff will create translation interpolation (calibration) tables to do precise measurements with a scope, using those tables and letting the offset DAC "follow" a (slow) signal in combination with a sensitive range (1 mV/div or 500 uV/div). I already had some good results using that technique, but without using a precision DMM.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline jancumps

  • Supporter
  • ****
  • Posts: 1216
  • Country: be
  • New Low
Re: New Keithley DMM6500 and now DAQ6510
« Reply #855 on: December 08, 2019, 10:23:41 am »
It can even do SRQ callback to my SCPI client, so polling would not be needed (which would have cause a lot of network traffic)...l
Do you happen to have a LABview example of that?
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: nl
    • KiCad-BOM-reporter
Re: New Keithley DMM6500 and now DAQ6510
« Reply #856 on: December 08, 2019, 02:09:53 pm »
I'm not using LabView, but here's what I found out:

My first thought was that the DMM would set the Measurement Event (MSB) bit of the "*STB?" register after each measurement. But no, that bit can only be set by event mapping.
Events are those things that end up in the eventlog info/warning/error and having a code. One can use such code to map it to a bit in another register (Questionable Event Register) which if the bit is enabled can cascade it's state to the MSB bit of the "*STB?" register.
There's also another register (Operation Event Register) which cascades to the OSB bit of the  "*STB?" register. In the following example I've used that.
Code: [Select]
INITIATE

// map bit 0 to information message 4
:STATUS:OPERATION:MAP 0, 2737

// Let bit 0 cascade to the "*STB?" register (OSB bit)
:STATUS:OPERATION:ENABLE 1

// Let the OSB bit send service request events
*SRE 128

// Clear event logs
SYSTEM:CLEAR
STATUS:CLEAR
« Last Edit: December 08, 2019, 06:03:05 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 
The following users thanked this post: jancumps

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: nl
    • KiCad-BOM-reporter
Re: New Keithley DMM6500 and now DAQ6510
« Reply #857 on: December 08, 2019, 09:11:44 pm »
There's one thing that needs some consideration when using these registers. When the STB is read via the VISA api, that is an destructive read (love the term). Which means is is read and set to 0 in one atomic operation. That's solid!
Reading the other registers don't work this way. Which mean that getting the register content and resetting it, cannot be done atomically. The danger of this is that after reading the content, a new state can be set at the device, just before clearing it. That way that status change will be unnoticeable.
The remedy against this is not clearing the register until one knows for certain that the dmm execution is in a safe state to do so.  A destructive read would have been preferable, because until that safe state event bits cannot be "reused".
Another technique might be to make the reading of the register and clearing it uninterruptible.
This could be done between:
TRIG:PAUSe
TRIG:RESume
But one does not want to do this while polling. :-+
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline JxR

  • Supporter
  • ****
  • Posts: 268
  • Country: us
Re: New Keithley DMM6500 and now DAQ6510
« Reply #858 on: December 08, 2019, 10:08:44 pm »
There's one thing that needs some consideration when using these registers. When the STB is read via the VISA api, that is an destructive read (love the term). Which means is is read and set to 0 in one atomic operation. That's solid!
Reading the other registers don't work this way. Which mean that getting the register content and resetting it, cannot be done atomically. The danger of this is that after reading the content, a new state can be set at the device, just before clearing it. That way that status change will be unnoticeable.
The remedy against this is not clearing the register until one knows for certain that the dmm execution is in a safe state to do so.  A destructive read would have been preferable, because until that safe state event bits cannot be "reused".
Another technique might be to make the reading of the register and clearing it uninterruptible.
This could be done between:
TRIG:PAUSe
TRIG:RESume
But one does not want to do this while polling. :-+

A few people on here like to use Raspberry Pis for dedicated loggers and instrument control.  One benefit I expect of such a setup is a set of GPIO pins.  If you setup a digital output trigger after the measurement is completed you could use it to trigger an interrupt.  Unfortunately digital output pins are only available if you purchase the TSP link card on the DMM6500.  Although I expect if you made a cable, you could technically use the BNC trigger out.  Both might require some level shifting to be compatible with the Pi though.

On GPIB connections the SRQ is just an output on one of the pins.  I've never actually messed around with it on an Ethernet interface.  I agree that polling is not the most efficient way to go about it.

Bringing out all the digital IO pins from my instruments and setting up a dedicated logging and control system with something like a Pi has been on my todo list for a while now...
 
The following users thanked this post: HendriXML

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: nl
    • KiCad-BOM-reporter
Re: New Keithley DMM6500 and now DAQ6510
« Reply #859 on: December 08, 2019, 11:19:55 pm »
I have it working, no more polling!
On an ethernet interface it opens an extra incoming port on the client. Via some underlying VISA mechanics that port is probably used by the DMM to post a SRQ message.
The time it takes to:

Client: signal the notification on the DMM
DMM: to get it to do a measurement (1 NPLC, 20ms)
DMM: post an event message
DMM: handle event message, post a SRQ via network
Client - Visa: Receive a SRQ via network
Client - Visa: execute call back
Client: Handle call back, set a windows Event
Client: Waking up from a wait on that windows event
Client: Checking STB status
Client: Checking Operation Event Register

Is about 40 ms. (So happily for my purpose fast enough.) The same code should also run using a GPIB or an USB connection.

Here's a list of timestamps (one second long) which show that every measurement is a new one:
Code: [Select]
12/09/2019 07:34:59.031936162
12/09/2019 07:34:59.076551859
12/09/2019 07:34:59.115640435
12/09/2019 07:34:59.168797708
12/09/2019 07:34:59.210993405
12/09/2019 07:34:59.248885829
12/09/2019 07:34:59.294446405
12/09/2019 07:34:59.330283587
12/09/2019 07:34:59.382150042
12/09/2019 07:34:59.423579860
12/09/2019 07:34:59.464834860
12/09/2019 07:34:59.504858587
12/09/2019 07:34:59.546109829
12/09/2019 07:34:59.597500920
12/09/2019 07:34:59.638888617
12/09/2019 07:34:59.682500526
12/09/2019 07:34:59.721256405
12/09/2019 07:34:59.823268920
12/09/2019 07:34:59.878116193
12/09/2019 07:34:59.917322890
12/09/2019 07:34:59.956568860
12/09/2019 07:34:59.999881072
« Last Edit: December 08, 2019, 11:35:48 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 
The following users thanked this post: JxR

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: nl
    • KiCad-BOM-reporter
Re: New Keithley DMM6500 and now DAQ6510
« Reply #860 on: December 10, 2019, 07:25:37 pm »
There's one thing that needs some consideration when using these registers. When the STB is read via the VISA api, that is an destructive read (love the term). Which means is is read and set to 0 in one atomic operation. That's solid!
Reading the other registers don't work this way. Which mean that getting the register content and resetting it, cannot be done atomically. The danger of this is that after reading the content, a new state can be set at the device, just before clearing it. That way that status change will be unnoticeable.
The remedy against this is not clearing the register until one knows for certain that the dmm execution is in a safe state to do so.  A destructive read would have been preferable, because until that safe state event bits cannot be "reused".
Another technique might be to make the reading of the register and clearing it uninterruptible.
This could be done between:
TRIG:PAUSe
TRIG:RESume
But one does not want to do this while polling. :-+
I found a general section of the reference manual that mentions that the register is indeed being reset after it's read. I'm glad that it does. Would have saved some time when it was mentioned in the query command as well though.
« Last Edit: December 10, 2019, 09:55:32 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline shodan@micron

  • Regular Contributor
  • *
  • Posts: 150
  • Country: ru
    • My personal page
Re: New Keithley DMM6500 and now DAQ6510
« Reply #861 on: December 11, 2019, 03:56:37 pm »
Fresh meat: Calibration and Adjustment Manual DMM6500-905-01 Rev. C (updated)

https://www.tek.com/tektronix-and-keithley-digital-multimeter/dmm6500-manual/model-dmm6500-6-1-2-digit-multimeter-0
« Last Edit: December 11, 2019, 03:59:42 pm by shodan@micron »
 
The following users thanked this post: Mr. Scram

Offline shodan@micron

  • Regular Contributor
  • *
  • Posts: 150
  • Country: ru
    • My personal page
Re: New Keithley DMM6500 and now DAQ6510
« Reply #862 on: December 11, 2019, 04:10:09 pm »
Diff between B and C revision: https://draftable.com/compare/SHOncpbXqVrN
 
The following users thanked this post: thm_w, HighVoltage, Mr. Scram

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8192
  • Country: 00
  • Display aficionado
Re: New Keithley DMM6500 and now DAQ6510
« Reply #863 on: December 12, 2019, 07:43:30 pm »
Does the C revision have the hardware issues discussed in this thread fixed?
 

Offline JxR

  • Supporter
  • ****
  • Posts: 268
  • Country: us
Re: New Keithley DMM6500 and now DAQ6510
« Reply #864 on: December 12, 2019, 08:32:27 pm »
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.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8192
  • Country: 00
  • Display aficionado
Re: New Keithley DMM6500 and now DAQ6510
« Reply #865 on: December 12, 2019, 11:14:15 pm »
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.
 

Offline JxR

  • Supporter
  • ****
  • Posts: 268
  • Country: us
Re: New Keithley DMM6500 and now DAQ6510
« Reply #866 on: December 12, 2019, 11:27:18 pm »
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.
 
The following users thanked this post: Mr. Scram

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8192
  • Country: 00
  • Display aficionado
Re: New Keithley DMM6500 and now DAQ6510
« Reply #867 on: December 12, 2019, 11:31:36 pm »
No, it's just a revision of the calibration manual.
My mistake.  :palm:
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 517
  • Country: be
Re: New Keithley DMM6500 and now DAQ6510
« Reply #868 on: December 13, 2019, 03:49:55 pm »
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.
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline drummerdimitri

  • Frequent Contributor
  • **
  • Posts: 402
  • Country: lb
Re: New Keithley DMM6500 and now DAQ6510
« Reply #869 on: December 20, 2019, 04:40:05 pm »
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?
 

Offline cozdas

  • Contributor
  • Posts: 38
Re: New Keithley DMM6500 and now DAQ6510
« Reply #870 on: December 20, 2019, 10:24:33 pm »
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.
« Last Edit: December 20, 2019, 10:54:44 pm by cozdas »
 

Offline cozdas

  • Contributor
  • Posts: 38
Re: New Keithley DMM6500 and now DAQ6510
« Reply #871 on: December 21, 2019, 01:44:18 am »
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.)
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 517
  • Country: be
Re: New Keithley DMM6500 and now DAQ6510
« Reply #872 on: December 23, 2019, 06:43:03 pm »
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.

Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: nl
    • KiCad-BOM-reporter
Re: New Keithley DMM6500 and now DAQ6510
« Reply #873 on: December 25, 2019, 01:34:22 am »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline JxR

  • Supporter
  • ****
  • Posts: 268
  • Country: us
Re: New Keithley DMM6500 and now DAQ6510
« Reply #874 on: December 25, 2019, 03:40:27 am »
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)

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf