[k24xx series] Fetching data while outputting a list

I am trying to perform IV measurements on photovoltaic devices. The scan rate (or dwell time per point) must be precise. Using the READ? function after setting a voltage relies on the host PC to determine the time between voltage steps. This turns out not to be very accurate, especially at short dwell times (<1 PLC). I wanted to use the precise internal timing of the Keithley to output a list of voltages at precise intervals. The output rate (and thus acquisition rate) for our measurements can reach up to 100 points/second, which should be well within the capabilities of the Keithley.

While I have been able to output this list and measure it. I can acquire the data only after all points have been output. As per the 2400 series datasheet on page 303 (17-4), I quote: 

After all source-measure operations are completed, the SourceMeter goes back into idle at which time the :FETCh? command is executed. The readings are sent to the computer and displayed when the Source-Meter is addressed to talk.

I haven't found a way to access the acquired data while a list is being output. Although from the datasheet it seems that the TRACE:DATA? command should return immediately with all data current in the data buffer, I have found that it, too, waits for the idle state before return any data. 
As some of the measurements may take over a minute to complete, it would be desirable to get the live data to understand if the measurement is going well.

So the main questions are
1. Is there any way to access the data in the buffer while a list is being output? If not, is there a different strategy to output (and acquire) a list of voltages at precise intervals?
2. How can I set a precise output timing? The TRIG:TIM command seems to crash the Keithley 2420, with only a hard reset as a solution.

P.S. We are using different Keithley 24xx models: 2400, 2420 and 2450.

With 2400 or 2420, don’t think you’ll get there.
To have each measurement available on the PC essentially as they are available would require the PC controlling a loop.  But as you observe, loops can have timing variation and changes with CPU speed, etc.
The use of trigger model allows better timing determinism, but as you observe, the instrument cannot serve up data and carry out the list sweep.  It’s available only at completion of the sweep.

The 2450 and TSP could be pressed into using trigger blocks to have good timing control and run some code that prints the buffer data to output queue for pickup by a VISA Read.  Keeping it coordinated will be a consideration.  For example, if you do VISA read too frequently, you could get timeout errors that would need handled.

There is a nice app note and Python sample on our GitHub for data streaming from our DMM7510 of DMM6500.  Similar approach can be applied to 2450, albeit at much slower rates than the DMMs.