Andrea C

Hello,

Seems you are attempting to use NI VISA from multiple threads in C#.

Can you clarify which exact model of instrument you have?
Also, can you give us an idea of the operation you are attempting with that instrument.

Sometimes a multi-point sweep can take a long time to run and in that case it would be expected that attempts to read the information would not be processed until after the sweep operation completes.

This NI forum post seems to have some good info about using VISA from threads:
https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/What-is-the-difference-between-doing-a-VISA-read-asyncronous-vs/m-p/60673?requireLogin=False

As for speed of the source-measure sweep, pg 30 in the 2600B series datasheet gives an idea.

Max expected rate for source and measure operations into memory is 12000 per second.

The 2600A series will have similar capability.

In your pulse mode Python code, the pulse period would need changed to 83.3usec to attempt that 12K rate.

This is fairly common issue to coordinate the state of the Python code with the state of the instrument.

For the 200 point sweep, it clearly requires more time to conduct the sweep vs. the 100 point case.

The VISA session has a timeout parameter, in msec.  Default value is 10 seconds for most VISA versions.

If your 200 point sweep needs more than 10 seconds to complete, then is very possible to receive a VISA timeout from the VISA read following your printbuffer() command.

There are a number of strategies to deal with this.

One would be simply to set the VISA session timeout to a larger number.  Default is 10000 msec.
Downside of longer VISA timeout is that for real error conditions, it will take longer to raise the error.

Or introduce a time.sleep(seconds) on the PC side before asking for the data.

Alternately, it is possible to have the instrument assert an SRQ when the sweep completes and your Python can do status polling and ask for data only when the instrument signals that is has some ready for you.

Really depends on how fancy you want to get in the code.

From old forum:  https://forum.tek.com/viewtopic.php?f=263&t=143187

In general, the problem in the code was how the voltage sourcing SMU at input to the DC-DC converter was programmed.

Revised Python code for two 2450 attached.



 

Looks like this one found a work around:  https://forum.tek.com/viewtopic.php?f=617&t=142379

In addition to checking your firmware level, also take note that when you edit the Timer settings, an Enable Timer button is displayed.
After the new delay value is entered, Press the Enable Timer button to apply those new settings to the timer.
The Enable Timer button then disappears until you again have changed one of the timer settings.

If you were operating from software control and using the timers, setting or editing timer values requires disabling the timer, set the various parameters and then enable it.

Seems the touch screen GUI is detecting a change is made and awaiting for you to apply them with the Enable Timer button.

Over GPIB, a program can send abort command to halt an executing script.
For this older non-A and non-B model, the manual leaves me a little unclear on exact syntax.
Try:  abort or abort() or smuX.abort()
For the A and B versions, the smuX.abort() is the proper syntax.

Curious which test freq does your 590 have?  100KHz or 1MHz or both?
Which freq do you use?

For the calibration capacitor topic, do you have the 5907 standard caps?  Or supplying your own caps?

Are you connected through the switch when doing the cable compensation with the standard caps?
You should be if you want the method to correct for it.

You mention an unwanted offset of up to 20pF when connected through a switch.  Have you tried the zero method from section 3.10?

Your 590 is likely to be quite old.  When was last time it was calibrated?
How are you determining the value of the reference caps?

In general, I’d try evaluating just the 590 with minimal cabling to the standard caps.  If successful, then start adding in the other aspects such as the switch, etc.

For your finding1 topic:  when blue light is off, if the SMU is in default output off config, then it is behaving as a 0V source with ability to source or sink 1mA.
This should result in 0V starting point.
When you say the voltage was jumping around 0 to 2V, what was the condition of the SMU then?

Any chance there was an open circuit due to probing issue?

NOTE:  for PN junction, if using SMU to force current and forward bias the diode, it is very much possible to trap charge on the PN junction when the SMU returns to 0Amps and the blue light is still on, especially if using a low source range.
Suppose you force current with a 3V limit.  When you return to 0Amps, the SMU has no trouble to allow as much as +/-3V.
This should be fairly steady, but could decay due to leakage in the device, cables or allowed offset of the source range.
You can bleed off the trapped charge by turning output off OR by temporarily setting the voltage limit to smaller value.

the sync_in and sync_out parameters of the Config functions will need to be used.

Wondering if you can just config each SMU to make use of digital line 1.  And then use the digio.trigger[1].assert() to satisfy the digital event.

Also, check your firmware and update to the final release (1.4.2) for these non-A and non-B vintage models.
firmware for 2600 nonA and nonB