Incomplete data file (saving)

Chris · August 19, 2024, 11:30am

Hello everyone
I have recently started using SweepMe! and have a problem with saving my measurement data. First of all, some information about the test setup. I am using a Keithley 2701 with a 7700 module. A RTD-100 (four-wire) is connected to it, which is to be read out via SweepMe!. The connection to the PC is realised via a RS232 interface and a corresponding USB adapter. I use the Logger-Keithley_2700 as driver and first of all it seems to work - The COM3 is found by the software and the Keithley can be controlled accordingly.

When I now start the measurement, the data is displayed correctly on the dashboard and the plot is also created. What is striking here is that the Keithley displays Error-101 (invalid character) and then Error-221 (settings conflict) at the start of the measurement, but then executes the procedure without further error. There is also no error message in the debug window of SweepMe!. The data transmission (temperature value) seems to be correct.

When I stop the measurement and open the data file, the entries for the temperature measurement are missing (see screenshot below). What could be the reason for this?

Kind regards and many thanks
Chris

grafik

Axel · August 19, 2024, 3:09pm

Hi Chris,

thanks for reporting this issue. When more people are starting to use a driver, it can happen that something that worked so far does not work for other users anymore if for example a different configuration etc. is used.

There are three reasons why SweepMe! saves “–” instead of a value:

The driver returns float(‘nan’) which is a placeholder for no value. Because you can see the data in the plot, this seems not to be the case.
If a data type is not yet supported. Because the data can be plotted, it is either a float or a numpy data type for which we defined how to save them to the text file.
If data is not zero-dimensional (point), but one-dimensional (list). In this case, SweepMe! saves at each measurement point of the sequencer a list data into an extra file.

Case 3 could be the reason:

github.com

SweepMe/instrument-drivers/blob/4cbc9728609b27aa85c43f00537090de530f35e0/src/Logger-Keithley_2700/main.py#L282


      
              #    self.port.write("form:elem READ\n;READ?") # This returns just the reading
          
          def call(self):
              answer = self.port.read()  # here we read the response from the "READ?" request in 'measure'
              readings_list = np.array([float(x) for x in answer.strip('\n').split(',')])
              #print(len(readings_list))
              #print(readings_list)
              #print(len(self.channel_list))
              #print("Response to READ? command:", answer)
          
              if self.scanning:
                  # Currently averaging is not implemented for scanning
                  return [[x] for x in readings_list] #[np.mean(x) for x in np.split(readings_list,len(self.channel_list))]
              else:
                  return [np.mean(readings_list)]
          
          
          def get_identification(self):
          
              self.port.write("*IDN?")
              return self.port.read()

If I check the above code, I can see that in “scanning” mode a list of lists is returned that is an indication for SweepMe! to treat the the data as one-dimensional.

We have created a minimal driver example to reproduce this issue and see the same problem: SweepMe! omits one-dimensional data if the length of the list is 1. Although this is a bug that we need to fix, it is not the real solution to your problem as the driver itself should not return a list for each variable.

The Keithley 2700 driver was once contributed by one of our users. Although we check the code for consistency, we have not been able to test it with a real instrument. Still, each contribution is valuable as the driver get better step by step with each user feedback.

As a first workaround, you could test whether it works if you uncheck the option “scanning”. In this case the code in line 286 is used and you get a mean value of the readout data. If you have only one sensor i.e. one value, it should actually help as the mean value is the same value and you can continue with your measurements even though it is not a general solution for the readout of multiple channels

To solve the problem, you could either create your own custom version of the driver and do modifications on your own:

or you can use our services and we will help you with revising the driver. In this case, feel free to write to contact@sweep-me.net
Probably, 1-2 video meetings are needed to revise and test the driver together.

Let us know whether the above workaround works.

Thanks and best,
Axel

Axel · August 19, 2024, 3:15pm

The fact that the Keithley 2700 throws some display errors at the beginning is probably a different issue. If you see data in the plot, it looks like that the measurement was performed, but it could be that a command from the initialization or configuration phase of the driver is not correctly performed.

Here, one needs to go line by line through the driver to identify the command that makes a problem.

Invalid character error sound like a command that contains an unknown/unsupported character.

Setting conflict error sounds like two commands that cannot be used together in the same measurement.

Chris · August 20, 2024, 6:01am

Hello Axel

Thank you very much for your quick reply and your suggestions. I will have a look and test it.

Kind regards
Chris

Christian · August 20, 2024, 11:47am

Hi Chris.

If you are willing to attempt a debugging on our own, an easy approach I often use is as follows:

create a custom version of the existing K2700 driver (Drivers - SweepMe! Wiki)
start with the initialize section and look for the first SCPI command (here: self.port.write(“*RST”) at instrument-drivers/src/Logger-Keithley_2700/main.py at 4cbc9728609b27aa85c43f00537090de530f35e0 · SweepMe/instrument-drivers · GitHub)
insert a new line and add the following, alligned with the indent of the previous command (written for your Keithley 2701):

    self.port.write("ERR?")
    errorflag=self.port.read()
    print("Error until here: ", errorflag)

Run the program and watch the debug window if the printout contains an error message
if not, move the section behind the next SCPI command in question and check again until you find the one that cause the error(s)

Best wishes,
Christian