• RE: Running measurement customizable scripts on Keithley 2636 via Python (PyVISA) - Speed problems

    Hy Andrea, thanks for the reply.

    Replying to your comments by topics:

    Comment 1: I have two 2636 equipments that I need to implement the objective, 2636A and 2636B, are the programming of these two models the same thing? Or maybe there are some difference between them?

    Comment 2: I actually know that 1 usec reading rates are way too fast for this equipment. I don't think that the equipment limitation is the biggest challenge for me, It looks like that my script in Python has an intrinsic execution time (running in my computer) that acts like a "bottleneck", limmiting my measure speed. I would like to know the most optimized way that I could build my software so I can make customizable scripts that run fast. With your vast experience, could you help me with any suggestion? Maybe running the scripts in the internal memory of the Keithley, I don't know. I also found this time spec in the datasheet (image attachment), It looks like it's the maximum time that the instrument needs to process the command and update the output, <1ms is still OK to me if I could make my software send the signals to update faster than that.

    Thanks for the file attachment, I'm going to study this document.

    Sincerely,
    Nickolas J.
     
  • Running measurement customizable scripts on Keithley 2636 via Python (PyVISA) - Speed problems

    Hi everyone, i hope you can help me.
    I'm currently trying to develop an application in Python to automate some measurements on Keithley 2636, I'm using PyVISA to communicate to my instrument via GPIB. I already have some GUI and data treatment features made, but I'm with some critical problems with the communication.
     Actually, it's not the comunicattion itself, because I succeeded controlling my instrument via PyVISA, but the timing of the communication.
    At first, I built a IV sweep code in python (logic in python), on which I update the Keithley as my code updates (I know this is probably not the most optimized way), it means that I send and capture the signal from my instrument point by point, everytime my code updates. It works, but with several limitations, mainly timing limitations, and there's the problem, I need updating times of about μs, and it looks like the program has an intrinsic execution time, that limits my updating speed on about 100 ms, obviously, the Python code will have an execution time by itself, but I don't think it's is the only problem here.
    So, summarizing, i need to build a Python apllication to run automated and customizable measurements scripts with very high speeds. And I'm currently facing this problem that I described.
    Some observations:
    •    At the same time that I need high speed capabilities on my program, I also need it to be extremely customizable, because I need to configure some extremely specific measurement routines.
    •    I think that it can be, maybe in part, Python speed limitation, since it is not the fastest language by far.&lt;/li&gt; &lt;li&gt;I though about speed limitations of GPIB, but I don't think so.
    •    I know that the Keithley 2636 has several tools that I can use, like buffers, FIFO, and internal memory. I tried using some of this, but have not succeeded, if someone thinks it can be a possible solution, please help me implementing these features correctly.
    •    I thought that maybe I can run TSP scripts that are saved in the Keithley internal memory, I think it should be faster, but I don't think I can make highly customizable scripts this way. Only if there might have been a way to load the script at the time of execution to the internal memory, run all the measurements, and after it is finished, delete the script so as not to occupy the internal memory.
    •    I preferably need to plot my data in real time, if possible.
    •    I will not upload any Python code here at the moment, because I don't think it's important at this point.
     If anyone can help me with any suggestion I would be extremely grateful.
    Sincerely,
    Nickolas J.