2 x Keithley 2651a in series; pulsed voltage sweep locking up during sweep

I am working with two Keithley 2651a instruments in series to measure solar cells in a sweep. I followed the app note titled "Number 3115: Combining Keithley Model 2651A High Power SourceMeter® Instruments for 100A Operation".  I've written a python wrapper to implement the parts of the control language that are needed for this, and it all seems to be working as I can get high quality data from a resistor very reliably.

However, I am having trouble keeping the Keithleys stable for a similar sweep on a solar cell or series of solar cells.  My cells have a maximum voltage of 44 V, a maximum current of 3 A, and I want about 100 measurements.  Pulse and sweep details:

- period: usually 30 ms; I've tried between 10 ms and 100 ms
- pulse width: 1 ms - maximum in manual is 1.6 ms
- NPLC; 0.005
- voltage start: -0.1 V
- voltage stop: 44 V
- voltage steps: 100

Qualitatively, I can see the lock up starting when the SMUs sweep slowing down and stop when it's not going to complete successfully. The two voltages often end up out of sync when the sweep stops, by as much as 10 V - I interpret this as one of the timers/trigger models missing a transition edge or other event. After waiting for the sweep to complete, I get a 5042 error when attempting to read the buffer - however, I don't think this error is related to the underlying problem, but related to the sweep lockup causing the nonoverlapping function to stop executing. I haven't successfully implemented the status registers, but I am waiting four times the sweep duration before attempting to read the buffer, along with a waitcomplete() command. 

Here's what I've tried:

1. 1. Searching different configurations of voltage step number, pulse period, and voltage. Depending on the parameters used, the system is more or less stable, but I have not been able to get close to the target voltage range for a solar cell and complete a sweep

2. I looked quickly at High Capacitance mode but my string is under 1 nF, so this does not seem likely to be an issue

3. I've tried to look on the forums here, but I'm not seeing anything like this. 

4. There's a comment on Page 2-54 of the manual indicating that there's a preferred polarity for the channel 1 SMU when hooked in series; I'v e tried that and the same behaviour occurs

5. I've tried breaking up the scan into shorter segments, but this has not changed the behaviour. 

I've attached my node configuration code so you can see what I am attempting. While it's in python, I've taken care to mimic the structure of the control language, so it should be readable. Please let me know if additional information is required, or if you have any suggestions. 

Thanks! 

 

I’m not seeing any reason for loss of sync between the two 2651A.

I assume you are doing a tsplink reset.
And the armed event on one SMU is starting timers on both SMUs with tsplink trigger.

Why pulse mode?  At max 3A and half your 44V on each SMU, you could be DC.

Your end pulse action is to go to idle level.  I don’t see where you set that.  If zero volts, you are pulling Isc in between each pulse.  Try setting the smuX.source.levelv to 20V so that you move to a low current state in between each pulse.

 

Hello!

Thanks for the response. 

I confirm that I am doing a tsplink reset before these calls, and that the armed event on the first SMU is triggering both instruments. 

Your question about why pulsed mode is interesting. I choose pulsed mode based on the manual text on page 2-52, which I understand to mean that if you are combining the outputs of two instruments, you have to stay pulsed. You raise a really interesting point - my power levels on each instrument are well within the DC sinking capability. I will investigate this further. 

I'll also look at the end pulse action idle level as well. I don't set it, so that could be the issue. 

Many thanks,

Mike T.

Additional experiments and findings. 

1) I've looked at the end pulse action idle level, and set it 40 V, and don't see any difference in the lock up behaviour. 

2) I've improved my handling of the error log, and there are no errors thrown prior to my attempt to turn off the outputs and read the data. 

3) I've adjusted the measurement timing to avoid the edges of the pulse, on the theory that the measurement is overrunning the pulse width and failing. No luck here. 

4) I've captured scope traces of the two cases: successful sweep completion with the resistor, and failed sweep with the solar cell. They are attached as a composite image - the top is the resistor and the bottom is the solar cell. Based on the shape of the second trace my conclusion is that one of the nodes is not completing its turn off action in phase, while the other one continues. The overall sweep is about the same duration. 






 

First, a clarification - I am seeing the failure when attempting a dark curve, when the cell is not illuminated. In these conditions acts as a diode.

Additional experiments and findings:

1) I can get a successful sweep with a gently illuminated solar cell

2) I've replicated the lockup behaviour with a schottkey diode

3) I've replicated the lockup behaviour with a 470k and 10k resistor; my test resistor that is successful is 101 ohms. 

I'm now thinking that this has something to do with the low current in the initial conditions of the sweep. I've got the ranges set quite high, so I think they should be fixed. Would there be a failure mode for the sweep in cases of very low values?

I failed to notice in my first post that you have auto range for the current measure still turned on.
You are setting fixed source range and fixed measure range v, but the measure range i is not set, so will default to auto range on.  Is that correct?

That is most likely the reason for loss of synchronization and the one SMU getting stuck in the trigger model awaiting a trigger that it missed due to taking extra time during a range change that maybe other SMU did not do.

Are your two 2651A at the same firmware level?  If not, please do that.

For pulsing, it is generally not feasible to also have auto range enabled.  Need a time budget on pulse width vs time for range changes and repeated measurements.

For low measure ranges in effect and large capacitive loads such as a solar device, there can sometimes be source stability issues.
In that case, try restricting the measure range by using fixed range or use of smuX.measure.lowrangei = XX

There is a high capacitance mode you can turn on.
Sometimes, just going to higher ranges fixes things up without the use of high C mode.

If you do not need pulse mode, have long pulses or otherwise want to use current measure auto range, you can maintain synchronization by making sure both SMU have completed a measurement before sourcing next value.  To do it, use the meas complete event from node[2] as stimulus for a tsplink trigger.  Then on node[1], use an event blender to logically AND the node[1] measure complete event with the node[2] meas complete relayed over the tsplink trigger.
The event_id of the blender can then be used to influence when sourcing occurs.
In this case, typically use a second event blender to do logical OR of the armed event id (first src value) or the blender id serving up the combined meas complete events (subsequent src values).
Make this OR blender to be the stimulus for the sourcing action.

 

That is a great catch, thank you! I will test the autoranging and the lower measurement bound with the instrument and report back. 

Thanks for the suggestion of the trigger blender - I will look at that in more detail next. 

Update! 

It looks like not turning off the autorange for both current and voltage was the difficulty. I have the system working on dark curves now, and will be extending to the full test on production devices here shortly. 

For future people who find this:

- I also verified the firmware was the same version number
- I looked at smuA.measure.lowrangei, and it is only active if the autoranging is on, so I did not try that. 
- I have not upgraded the trigger model, so that was not tested here. 

Andrea - thanks for all of your help!