Erroneous timestaps returned when reading trace buffer

[andisa]

Hi,

Sometimes, especially if the Keithley has been on several Days, the command TRAC:DATA? will return +9.9E37 instead of the just reset relative timestamp. Also the comma that should precede it is missing!
See attached log file line 130, log time 15:02:55.9. “DMM 0” is the Keithley 2700. “PS 0” is a Keithley 2401.

Once the error has occurred it will occur each time until the Keithley 2700 is turned off and on again.

We have been running the same sequence of commands many times on many Keithley 2700 and it almost always work fine. The error has however occurred on several units, over the years.

The problem is that we now have a customer who want to run automatic measurements for two months in a row and we fear that the Keithley 2700 will end up in this erroneous state before completion.

Is there a more stable firmware version? We have used B10, see log line 51, log time 15:02:43.3.
Do you have any other solution to suggest?

Regards @nders

[Dale C]

What software are you using? Excelinx, Labview, etc.
Is this a 2700 or 2701?
What communication bus are you using? GPIB, Ethernet, etc.
B10 is the latest firmware, you so you have the most up to date firmware.

[andisa]

Our software is witten in C#.
We are using Keithley 2700 not 2701.
We are using RS232 for Communication.

[Dale C]

What are the RS-232 parameters of the 2700 set to? BAUD, FLOW and Terminator?
Can you post the SCPI Commands used?

[andisa]

TermChar:13 XOnXOff StopBits:One Baud-rate:9600

This information and all sent commands together with answers to the query commands are in the log file that is attached to my first posted message.

I take it that you don’t have a solution ready for us.

I suspect that there is a firmware error causing the time stamp counter to overflow and not be resettable again. Could sending "SYST:TST:REL:RES" every hour or so be a work around?

[Dale C]

That will reset the time stamp every time you send it.
that should help as I have no answer yet for you.

[Pieterkuijpers67]

Dear Andisa (or others), could you inform us if this matter has been solved in the meantime.....?
We are currently experiencing the exact same problems on a Keithley 2700, used for long-duration testing.

Your reply would be highly appreciated.

Pieter.