I am modifying a bit the Keithley SMU device for our application. In particular, I am adding a parameter to sense both voltage and current instead of saving only the set voltage (in CV) or set current (in CC).
That is not problem, because the Keithley returns the measured values right away from the call to the instrument if both sensing function “VOLT” and “CURR” are activated.
What I am trying to do also is to save both the set value and the measured value. Let me put an example:
Say I am measuring a sweep at CV and my DUT might hit my current compliance. In that case, I would like to record the actual voltage as well (not only the set one). With my current modification, I can record the measured voltage, no problem. Ideally, I would also like to record the set voltage and add it to the self.variables.
The problem is that I can’t find the way to access to it at the device level… it seems that the sweep is happening at some other level, perhaps at the module level? Is there a hidden attribute or method to get the current value of the sweep and return in as well in the call() method?
My idea is just to implement it if it is not too overly complicated, if that were the case, I can live with my current implementation
Hi Joan,
sorry for the late reply that is due to the vacation time.
As you alread wrote, the intsrument driver should already return the sensed/measured voltages and currents at each measurement point.
There are different (future) solutions:
The driver is informed about the new set value in the ‘apply’ phase via the attribute self.value. You could basically return it in call as the last known set value. Depending on the sweep mode (Voltage or Currrent) you can change the name of your variable that you return.
As you already expected, the sweeping is handled on the module level where you do not have direct access to, but with self.value you have the information you need.
The easiest solution is to add a “Calc” module to your sequence. There you can select for example the “Sweep value of SMU1” as x1 and just return it by entering x1 into the formula field. This way, the set value will be added to measurement data file, but is also available in the plot. It is probably the best solution, because you don’t neet to modify the driver and can ge ahead with the standard driver version and thus benefit from future improvement (instead of forking it).
A third and future solution would be that we allow users to select for each module whether set values shall be additionally tracked, saved and displayed. Then, this would a global feature that could be immediately used for all drivers.
I will create a backlog item for the 3rd solution but because the 2nd solution is a good workaround for now, it will not have the hightest priority.
Let me know if this helps or whether you need further information or help!
Thanks, it helps! I think I’ll go with the Calc now, as you said, seems the easiest. I also figure out that I could always read the setpoints from the *.set file, although a bit less neat perhaps.
