Current point-by-point polling is limited by serial latency.
- python loop sends
:SOUR:VOLT <value> via VISA
- waits for the command to traverse the USB bus
- Sends
:READ? to request current measurement
- Waits for response to return.
This is finee(ish), however, puts a latency bottleneck onto the python loop rather than utilizing full efficiency by placing it onto Keithley 2460's internal ARM processor itself. Currently, the latency floor for the python is ~10-50ms, which when considering full sweeps (and future J-V long-term stuff) leads to 'dead time' in the seconds (technically leading to unnecessary degradation).
As such, moving that current method into a more efficient one is consideration that would need more research. The following proposed solution w/ limited research suggests:
- Migrate from
SOUR:VOLT loops to :SOUR:SWE:VOLT:LIN.
- Use the Keithley internal buffer to store results
:TRAC:MAKE ?
- Perform a single bulk-read after the sweep completes.
- Likely utilize
*OPC* query to let python sleep as well.
Once more, this should not be done UNLESS previous issues have been fully merged and tested.
Current point-by-point polling is limited by serial latency.
:SOUR:VOLT <value>via VISA:READ?to request current measurementThis is finee(ish), however, puts a latency bottleneck onto the python loop rather than utilizing full efficiency by placing it onto Keithley 2460's internal ARM processor itself. Currently, the latency floor for the python is ~10-50ms, which when considering full sweeps (and future J-V long-term stuff) leads to 'dead time' in the seconds (technically leading to unnecessary degradation).
As such, moving that current method into a more efficient one is consideration that would need more research. The following proposed solution w/ limited research suggests:
SOUR:VOLTloops to:SOUR:SWE:VOLT:LIN.:TRAC:MAKE?*OPC*query to let python sleep as well.Once more, this should not be done UNLESS previous issues have been fully merged and tested.