New Keithley DMM6500 and now DAQ6510

[Kleinstein]

The jumps look a little like the "normal" level of popcorn noise from a LM399 reference.
So chances are high this is a limitation of the hardware. Besides the reference also resistors could produce a similar noise. The DMM6500 is sold as a 6 digit meter after all and not for 7 digit performance.

[HighVoltage]

Agree, it might be the 399 --- though I dont think I've seen it jump for that long of a time period before. When I get my loaner back, I can try this as well see what it looks like. I assume this data was taken in a very temperature stable environment with care taken with the cables and connections as well.

Yes, temperature was very stable in my lab and I used metrology grade PTFE cables.
Thanks for looking in to this.

[HendriXML]

I did some experiments with an fixed cold side junction temp (about 40°C). The results seem to show that it works, even with a very cheap thermo couple.
https://www.eevblog.com/forum/testgear/diy-cold-junction-compensation-on-a-dmm6500/msg2808948/#msg2808948

The setup can be improved a lot, but I like the idea that it is possible to do thermocouple measurements with CJC this way.

[Wintel]

I had the DMM6500 hooked up to a very stable LTZ1000A output.
The problem that was noticed before, with a sudden jump in the graph is still happening.

So, most likely this is a hardware problem and can not be solved in the firmware?

Have you try to connect another DMM (34470A / 34465A) to the LTZ1000A at the same time?

It is easy to see that the sudden jump is only happen in the DMM6500.

[HighVoltage]

I had the DMM6500 hooked up to a very stable LTZ1000A output.
The problem that was noticed before, with a sudden jump in the graph is still happening.

So, most likely this is a hardware problem and can not be solved in the firmware?

Have you try to connect another DMM (34470A / 34465A) to the LTZ1000A at the same time?

It is easy to see that the sudden jump is only happen in the DMM6500.

Yes, these sudden jumps only show up on the DMM6500
Other DMM in parallel that I tested, like the 34470A / 34465A will not show this.
So, it is for sure related to the DMM6500
Also, the Keithley DMM7510 does not show this phenomenon.

[Kleinstein]

The 34465 uses the same type of LM399 reference. So similar jumps are expected for this meter too - but of cause not correlated and possibly at a different rate. Not all LM399 must behave the same, but I would still expect some popcorn type noise. There may be different levels of selection for the references.

[KedasProbe]

Hi,

On my second unit (at work) the firmware update failed:
I did return to firmware 1.0.04b and it looks like it works ok now. (although not sure)

During the firmware update I got error: 2305

Rebooting after the failed update I got  error: 1149

P.S. I submitted an official support ticket.

[KedasProbe]

So is it alive again? I always thought an FPGA programming failure bricked the unit. I'll ask about it.

Yes it is working again,  (on the older firmware)
Apparently an AFPGA init failure doesn't brick it. (how many FPGA's are there?)
It will contain the previous version in it so it's not like it's not working.
Although I'm not sure if the downgrade worked as it should, I didn't get an error during downgrade though.

[Kleinstein]

I don't think the FPGA will still have the old code as a backup. One could be lucky that at least the part for communication and upgrade (kind of boot-loader equivalent) worked.  A possible error scenario could also be that the upgrade of one FPGA did not run at all and the errors are due to not compatible versions / failed verify . In this case the way back has a good chance to work.

[MegaVolt]

how many FPGA's are there?

Judging by the photos, the device has 2 FPGA:
1. Spartan 6. (Presumably an exchange between two processors, an exchange with memory, digitizing, etc. ...)
2. Actel ProASIC3 (management of multislope ADC, maybe some other tasks.)

The analog most likely is called the second FPGA.

[HighVoltage]

The jumps look a little like the "normal" level of popcorn noise from a LM399 reference.
So chances are high this is a limitation of the hardware. Besides the reference also resistors could produce a similar noise. The DMM6500 is sold as a 6 digit meter after all and not for 7 digit performance.

Here are pictures from today.
The DMM6500 and the 34465A in parallel hooked up to a stable 10V reference.
There are no jumps to notice at the 34465A
But always some jumps with the DMM6500

Both instruments set to 1 NPLC, no filter, Auto Zero ON



 

[HendriXML]

It wouldn't surprise me if theses where ADC (DNL?) errors, specific to your device's ADC. In that case it may happen only on specific voltages when several bits overflow, exaggerating an analog rise/fall.
But comparing both brands is hard on those pics, the DMM6500 has what looks to be a stronger zoom on the signal.

[Kleinstein]

The Level of the jumps is about what is expected for an average LM399 - so it would be a surprise not to find it. Not all units are the same and the 34465 may have a slightly better selected ref. or just luck. The graph as shown does not have enough zoom to show the noise - there are just a few indication visible. The relatively slow popcorn noise would probably get more visible at 10 PLC.

[iMo]

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

[HendriXML]

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


[Mr. Scram]

Any word on when the new revisions that fix the known hardware issues will appear?

[JxR]

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.

[HendriXML]

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.

[jancumps]

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?

[HendriXML]

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


[HendriXML]

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.

[JxR]

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

[HendriXML]

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


[HendriXML]

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.

[Mr. Scram]

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