New Keithley DMM6500 and now DAQ6510

[E-Design]

Yes I noticed Digitizer in the csv but I am not using the digitizer, this just appears at random. While it is in this fault condition the meter sort of locks up, some hard buttons do nothing, some perform the wrong function, the screen is non responsive.  If I prod butons at random, I have not been able to repeat a sequence that helps, it will suddenly wake up and carry on as if nothing happened but leaves a gap in the readings.  It used to stop until I intervened but now if I leave it alone it does, eventually, restart by itself, this can be seen on the home screen image which shows several hours of data. It is a shame because when it works correctly this meter is a superb piece of equipment. When I initially bought it other people were reporting blue screens, freezing etc so I assumed it was a firmware problem and Keithley would sort it out, unfortunately I am now suspecting a possible hardware issue    
Let's see if E Design can throw any light on it
Thank you for your input, regards Mike

Hi Mike, sorry to hear you are having trouble, you mentioned it can run just fine for hours so thats not usually a characteristic of a hardware problem (though its possible, just not as likely)

Couple of things...

1) Did you contact support? If you did, I can work with them to nudge the progress along if you are not getting any satisfactory help.
2) What vintage is the instrument. If you PM the serial, I can look it up to see if its an earlier unit that may have had some intermittent digital board issues (that was a hardware issue)
3) A bit of a long shot, but can you verify the instrument has a proper earth ground for your mains connection? Its not enough to just check that the pin on the cable is connecting to the instrument - but rather that wherever it is plugged in, does actually have a sufficient connection to earth. We have seen some sometimes strange display and digital behavior when the instrument isnt properly grounded in some environments or with very high voltage potentials nearby. Hopefully, its an easy thing for you to verify..
4) Try actually downgrading the firmware to something that is several versions ago (off hand, I dont know what the latest release is..) but try something significantly older and then let it run for long periods doing the same testing you have been doing.. sometimes this can help establish when a particular firmware issue might have been introduced- and sometimes its just a waste of time unfortunately.

[Mike G]

Hi E Design, thank you for the information.  I will answer your questions in turn

1)  No.  As I thought it was  a known issue I was watching on the forum and hoping a firmware upgrade would eventually fix it. If I go down that route can you suggest a contact point please?  I am in Cyprus. It was bought from UK.
2)  I bought it from Farnell UK in early April 2019 S.No 04415206
3)  The L-PE impedance at the wall outlet is 3.54Ω,  at the IEC connector to the DMM6500 it is 4.19Ω   The mains supply is 243volts and the DMM6500 is set to 240volts input.
4)  Have not tried this as it has had problems from when first received and it had a very early firmware installed then. I will try it if you think that may shed some light on the problem. It is currently running 1.7.3c

Thanks in advance, Mike

[Mike G]

Sorry E Design I didn't include the L-N impedances in question 2 without which the L-PE wont mean as much.   The L-N impedance at the wall outlet is 0.66Ω, at the IEC connector to the DMM6500 it is 0.95Ω
Regards Mike

[E-Design]

Sorry E Design I didn't include the L-N impedances in question 2 without which the L-PE wont mean as much.   The L-N impedance at the wall outlet is 0.66Ω, at the IEC connector to the DMM6500 it is 0.95Ω
Regards Mike

Hi Mike,

When the operation become strange, do you get some kind of message or error ? if so, what is the exact error stated?

and if I am understanding your setup, it looks like you just setup DCV 100mV range (not *digitize V) and let it fill the default buffer with readings.. sometime after say 20 minutes or some hours, then it misbehaves by what looks like digitzer readings polluting your default buffer. Additionally, the front panel / buttons become unresponsive or misbehave.... and it could appear to be frozen for sometime until it just snaps back into working..

do I have this description right?

Thanks

[Mike G]

Hi again E Design

When it stops there is no error message, it just freezes and the two rotating arrows next to the CONT on the top left of the screen stop rotating.
Randomly pushing physiacal buttons can usually make it restart, I say randomly because there is no definite sequence I have found that always makes it restart. Also when in his stuck mode the physical buttons often actuate a dufferent function from the one they are meant to start   More recently, as you realise, if left it will restart after a random time, this is a new feature but no changes to the setup have been made to cause this

The 100mV range is automatically selected by the meter, it is not runnung any script, the unit is starting up in default mode other than the DEF1 buffer is set 1,000,000 readings and Filter ON (Repeat 10)

If it is power cycled while in the fault state it hangs permanently on boot at the red Keithley logo, before the relay clicks, no beep nor front terminal indicator lamp lights, hope this may help.
Thank you
Mike

[E-Design]

Mike G, check your PM

[Mike G]

Thank you E Design

[HendriXML]

Sometimes (maybe 33% of the times) when doing a ratio measurement and a clear buffer, the first reading in the buffer is that of a secondary measurement,  thus voltage.

I think I understand what's happening. Setting up a secondary measurement creates a 2nd buffer. When the default buffer is cleared it may be unavailable for a moment so the 2nd buffer is used.
The creation of a second buffer in the ratio case was not know to me, so there seems to be 2 ways of getting the input voltage of a ratio measurement via scpi, one via the extra value of the default buffer. And one by setting up a secondary measurement.

Edit:
The extra value contains the sense voltage (difference between SenseHi and SenseLo).

[HendriXML]

I've been tuning the circuit and my measurement setup to a degree of repeatability I'm happy with.

The SenseLo, SenseHi, InputHi are all buffered with a generic TL082, and smoothed with a 1k/10uF RC filter and 10uF capacitors at the terminals.

Considering this and the fact each dc ratio measurement consists of 3 sub measurements separated in time, this 12 min graph seems very acceptable, and good enough to be able to distinguish between different transistors.

The amplification of a transistors is very dependent on even slight temperature differences at this "level of accuracy". Now that is becomes noon and a bit colder this seems already affect the measurements. Having to do 60 transistors under controlled circumstances (same temp) might be tricky. However for me the end result is not the most important.

[Mike G]

Hi E Design
I have replied to your PM but as I have never sent a PM before please can you confirm receipt?
Thanks, Mike

[HendriXML]

I've been reading the reference manual, but I cannot find a way to set the secondary measurement function using a scpi command's.

Then I thought maybe just use a configuration list.. But secondary measurement seem not to be managed by them.

Also swapping between primary and secondary measurements doesn't seem to have a corresponding scpi command, so a dead end as well.

Then I tried to record related actions in a macro and have a look inside such a script. But these secondary measurement actions are not recorded.

Maybe someone had more success and/or knows how?

[HendriXML]

I think I understand why the secondary measurement can not be configured remotely. Here's my view on the matter..

One of my ongoing project is to sync the states of my scope, awg, psu, dmm with an inifile, so the settings are documented and can be recalled later on. On most devices this works by setting up the user interface via scpi commands. On my scope even menus are switched accordingly.. (this slows things down unnecessary).  Or another example: when you change two dependent parameters in a single command like low/high level. One of them might be discarded, because if you would manually change them in that order the bounds wouldn't (momentarily) make sense. (High bound lower than low bound). But in an api I think you owe it to the user to just buffer them and check them in buffer.. (Now one needs first read the current state, to change the parameter order accordingly..) So some manufacturers make it too easy on them selves...

The dmm6500 is different in this regard. It more like the user interface can setup a (hidden) trigger model. In which the primary and secondary measurements are configured in a configlist that are switched during measuring. The secondary measurement (dc-voltage) of a dc-ratio function is (from what I understand) a new measurement,  eventhough it is already part of one of the 3 sub-measurements.

So a way to do a secondary (and "tertiary"..) measurement via scripts is to (directly) setup such an trigger model ourselves. However determining what secondary function is active seems not possible. So no way of documenting/restoring that state.

One challenge that I face is that I need to cache the settings of a function to determine the 2 year calibration accuracy of the measurement. This is used to show the significant digits, instead of 7 or 17 (real). But also in calculations, in which these measurements are used the accuracy is (automatically) propagated. 

It would great if the dmm would calculate the accuracy instead!! (user may select the used "calibration duration")

This settingscache at the moment does a "write through" to the active state of the device. But due to the need of alternating functions these settings now need to remain in a config list. One problem here: with TSP commands it is possible to change settings without making them active, but when using scpi commands it is not. For my scripts it would have been nice to be a be able to do a two way sync. Having to make a function active to change a setting in a configuration list,  makes it less flexible. (For instance changing the range of a function in script while running the trigger model, would be disruptive)

One thing I've also been thinking about is that each measurement (all rows of the buffer) could have it's own "configuration reference" (an index in a system maintained configlist). That way the uncertainty determination (for instance) could be done without caching settings. But that would be a nice challenge for the Keithley developers. 

[HendriXML]

I made the script and ran it.

The script runs the attached trigger model and each time the event is logged, my script gets notified that 2 values can be read from 2 seperate buffers after which the dmm gets triggered to continue.

This is done via a Visa callback and requires no polling.

The measured shunt voltage is then used to adjust the powersupply to get closer to the target voltage of 4.8375 V ± 700 μV  . This needs a few cycles. The powersupply has a UI resolution of 1 mV, but using scpi commands more can be achieved. When using dmm feedback it has very high accuracy as well.

In the setup I used a 3 (female) pin low quality mounting strip for the transistor under test, I think this may have added extra noise. So I'll be soldering them to some male pins. This will heat up the transistor of course, but by letting the script watch the transistor amplification go down due to cooling and get stabilized this can be used to take the final measurement.

PS
I just had to put 4.8375 V ± 700 μV in the above text, this value and accuracy was aquired from the measured shunt resistor of 27.025 kΩ ± 4 Ω. Having accuracy info besides the values can give some indication what margin of error one has or need to maintain during experiments. Normally my script would show accuracy by limiting the significant digits, only verbose mode shows it with ± xx.

[MegaVolt]

This is done via a Visa callback and requires no polling.

It is very interesting. Could you tell us more about how you do this?

[HendriXML]

My scripting tool/script is a bit specific, but it still good to show the steps using it as an example:
At the dmm side of things:

Code: [Select]

<Execute Statement="Dmm.MapEventToOperationRegister(TEventCode.InfoMessage4, TRegisterBit.B1)"/>
<Execute Statement="Dmm.OperationRegisterCascadeMask:= TRegisterBits.B1"/>
<Execute Statement="Dmm.ServiceRequestMask:= TDmmSTBFlag.OSB"/>
<Variable Identifier="OSBState" Type="TRegisterState" Init="Dmm.StatusState[TDmmSTB.OSB]"/>

Which will lead to the following scpi output.

Code: [Select]

Sending: :STATUS:OPERATION:MAP 1, 2737
Sending: :STATUS:OPERATION:ENABLE 2
Sending: *SRE 128
ReadSTB: 0
Sending: :STATUS:OPERATION?
Received: 0

Status bit are read using destructive reads, so I manage changes in those bits using large integers (TRegisterState). So if a certain bit is set, then a corresponding integer is incremented. This way checking bits can be done at several locations in the script, without "destroying" a state change.

Essentially a report type (TEventCode.InfoMessage4 = 2737) is mapped to a certain bit. Than this bit is enabled to send a ServiceRequest when it is logged.

At the script side of things the used tool should register a ServiceRequest callback/handler using the Visa api.

Code: [Select]

    RetValue := viInstallHandler(FVisaResource.FSession, VI_EVENT_SERVICE_REQ, VisaEventHandler, Self);
    RetValue := viEnableEvent(FVisaResource.FSession, VI_EVENT_SERVICE_REQ, VI_HNDLR, 0);
In my tool this registered handler (under water) sets a win32 Event on which the script can use to wait for to be signalled.

Code: [Select]

<Variable Identifier="ServiceRequestEvent" Type="TVisaEvent" Init="Dmm.VisaResource.ServiceRequestEvent"/>
<Execute Statement="ServiceRequestEvent.Enabled:= True"/>
Which is used for waiting and checking the right status:

Code: [Select]

<RepeatUntilLoop Expression="Dmm.OperationChanged(TRegisterBit.B1, NewMeasurementState)">
  <RepeatUntilLoop Expression="Dmm.StatusChanged(TDmmSTB.OSB, OSBState)">
    <Suspend>
      <Resume.EventHandle Handle="ServiceRequestEvent.Handle"/>
      <Resume.BreakRequest IssueExit="True"/>
    </Suspend>
  </RepeatUntilLoop>
</RepeatUntilLoop>
Which results in these scpi commands:

Code: [Select]

ReadSTB: 192
Sending: :STATUS:OPERATION?
Received: 2
It may look like the loop is polling, but this loop is just too ensure the right event (InfoMessage4) has happened, it will only do that if and SRQ notification was send by the dmm (Visa will open a dedicated network port for that).
The loop can also be used without waiting, but than it's more like polling the dmm (Sending many queries).

[Pinörkel]

Hello, I just noticed something strange with my new DMM6500. The push button that switches between front and rear panel inputs has kind of a scratchy feel and a comparatively high resistance when pressing it. Through the venting holes on the right side I can see that the button is connected via a diagonal rod to a switch on the PCB at the top of the instrument. Each time I actuate the button and switch it to the rear inputs, this PCB flexes momentarily at least 5mm in an upward direction, which looks extremely unhealthy. The actuation force is so high that it is impossible to actuate the button without holding the meter in place on the table. Is this normal, or is it likely that my switch has a way too high mechanical resistance and is actually defective?

[maxwell3e10]

Mine doesn't seem to be harder than usual, the meter doesn't slide. I can also see the board flexing a few mm.

[Pinörkel]

Mine doesn't seem to be harder than usual, the meter doesn't slide. I can also see the board flexing a few mm.

Thank you for checking the PCB flex on your device. I just measured the actuation force on my button and it is approximately 800g. That is about 50% more than the force for most of the push buttons on my vintage devices, but none of the latter have that scratchy feel while pushing the button.

As for the flexing, this looks like really bad design to me. Bending a PCB like that is kind of a predetermined breaking point for the traces on it. The only sound reason I can imagine for constructing it like this is, to make the bending of the PCB act as a strain relief for the solder joints of the push button switch.

[HendriXML]

I had some fun using the ratio functionality to measure the input/output current ratio of the attached current mirror circuit. The input current was derived from the extravalue which can be get from a full style buffer. This current is set using a few cycles tuning with an awg. From gnd (and dmm com) vs sense lo, is a about -7 V at the highest currents, this way the "fixed 10 V range" is used more like a 20V range.

Did some averaging myself (running average of about 30 s of samples, until stddev of the running samples was lower than 0.0001).

The transitors were measured and "best matched" (out of 15 in total) using a different circuit (also using the ratio functionality to determine current amplification).

At higher currents the ratio climbs a bit, probably due to uneven warming up of the transistors.

The current mirror seems very usefull in this current range. 

[HendriXML]

Here's a nice science vid from Applied Science of a dmm6500 in action as a precision (differential) temperature measurement device. (Don't be shocked about the water spill)
https://youtu.be/9wZ0wTqJIxY
I was wondering though, wouldn't a 4 wire measurement not be better? Now a small part of the leads contribute to an unknown/unwanted resistance change as well.

Buying a sensor like this:
https://nl.mouser.com/ProductDetail/Measurement-Specialties/PTFM101T1A0/?qs=e%2Fel81Nv5ixCDfWDEYh9tw%3D%3D

And attaching 4 wires to it (and some electrical isolation) would make for a cheap (3€), but maybe better measurement setup, no?

Edit:
After thinking about it some more, his calibration propably rules out the wire resistance change. Looking at the addition of water, the amount does not need to be precise as well 
However between different measurements both water amount and cm of sensor lead in water must be the same. And the leads should have comparable heat response (lineair).

[HendriXML]

I wanted to experiment with 2 transistor constant current source, to measure the Vbe voltages of a certain transistor at a range of currents (controlled by awg dc offset).

Having only one dmm6500 I tried to use the ratio functionality to measure 2 voltages at the "same time". The switching the dmm does between sub-measurements seems to make this method unusable. (I've tried adding delays).

One can see the difference in the shunt voltages measured (sense Hi vs Lo). When using the ratio functionality combined with a separate voltage measurement, the voltages seem to be jumping between 3 distinct levels (besides some noise). This I find somewhat fascinating..

Previously I buffered the signals to the dmm, to get around this issue. But the need of having to change the circuit under test is inconveniant. Maybe someone has another solution?

[Kleinstein]

The second voltage reading (from the ratio data) look odd. The points high are som 130 mV higher than the rest.  If this a artifact from the meter this would be a huge error.
As far as I heard there is detailed info on the buffer data - so more than just voltage readings, but also data on the source and time. This may help to show why some points are off so far.

A voltage reading of some 5 V is odd for the given ciruit. 5 V for B to E is a bit high for Q102  .

The more straight forward way would be using a scanner card that is available for the 6500.
Otherwise using the ratio mode should be OK as a workaround to get 2 readings - it would be however much better if the SW would support this directly.

[HendriXML]

Thanks for responding, the measured 5V is the voltage across R101. The "constant" current voltage  .
In the ratio measurement it is measured between the sense lines. Technically using 2 sub measurements between sense hi/lo and com (so it can be time related).
In the normal measurement, between input hi and com.
The strange thing is that it can be stable for a short period, and then it jumps a level. Then after a shorter period it jumps back.
 Using the awg, makes it difficult to do a normal scope measurement across R101, but I could use 2 channels and substract. I could also try a ratio measurement of a simple resistor divider and check its behavior on a scope.

[HendriXML]

I measured a simple resistor divider (51k vs 51k) and (only) once I got a jump.

The wires I used have crimped connectors on them and I'm starting to suspect them not being optimal. If thats the case this can be given funny business for some time now, maybe invalidating my previous findings on interference on ratio measurements.

However I'm a bit skeptical of a loose wire being the issue. The measurements I do are mostly remote, thus without physical inteference. And why would the jumps be so alike..

[HendriXML]

Wires and connectors are checked:

Code: [Select]

Blue 63,8 mΩ ± 200 μΩ
Green 64,4 mΩ ± 200 μΩ
Black 32,5 mΩ ± 200 μΩ
White 32,1 mΩ ± 200 μΩ
(Black and white are thicker)

Also wiggling them around had never an effect on the problem.

My script tests for these currents, with corresponding shunt voltages:

Code: [Select]

10 mA 5,0710 V
8,2 mA 4,1582 V
6,8 mA 3,4483 V
5,6 mA 2,8398 V
4,7 mA 2,3834 V
3,9 mA 1,9777 V
3,3 mA 1,6734 V
2,7 mA 1,3692 V
2,2 mA 1,1156 V
1,8 mA 912,8 mV
1,5 mA 760,7 mV
1,2 mA 608,5 mV
1 mA 507,1 mV
820 μA 415,8 mV
680 μA 344,8 mV
560 μA 284,0 mV
470 μA 238,3 mV
390 μA 197,8 mV
330 μA 167,3 mV
270 μA 136,9 mV
220 μA 111,6 mV
180 μA 91,3 mV
150 μA 76,1 mV
120 μA 60,9 mV
100 μA 50,7 mV
By tuning the awg to a certain shunt voltage, the actual measurement begins. But only after that shunt voltage is stable.
It seems to really depend on the current measured whether it becomes jumpy (And this is not always the same target current).

Attached is now the 6,8 mA - 3,4483 V target.
The 10 mA-5,0710 V and 8,2 mA   - 4,1582 V targets have then successfully passed. (Those failed previously)

At the beginning there's tuning. Which was now heavily osccillating due to the problem. After 30 s, it became stable during 10 reads so the measurement enters the final stage. In this stage no more tuning, just waiting for the measurement to have a low running std dev. Which will not happen..