06-08-2016 05:58 PM
The 4141 has an onboard buffer that it uses to output sequences of setpoints. If the sequence you want to output is larger than the buffer can hold, the host machine will stream the sequence to the SMU as it outputs. This error occurs when the host is streaming an output sequence to the SMU and the parameters are such that the SMU is outputting the sequence faster than the host can stream the sequence to the buffer. The SMU looks for the next setpoint in the onboard buffer, sees that it isn't there, and returns this error.
The code worked back when Measure When was set to Automatically After Source Completes because the SMU was pausing after every setpoint to take a measurement. This gave the host enough time to stream the sequence to the SMU buffer. Adding more SMU channels into the mix will increase the total amount of bus traffic, slowing down streams and causing the buffer underflow.
The amount of setpoints that the SMUs buffer can contain is variable. It depends on what type of sequence you're outputting. In general, however the maximum is around 350-400 setpoints.
This issue could be avoided by ensuring the length of the output sequence was always less than 350 to prevent the host from ever having to stream the data in the first place.
The FGEN program above dynamically changes how many setpoints are in a sequence based on the input frequency that is requested from the user. Higher frequency = fewer setpoints in the output sequence. This was implemented to try and increase the resolution of the FGEN at lower frequencies. If you output > 1kHz, the output array only has 20 setpoints in it.
What sort of frequencies do you need to use? Do you need the ability to adjust the parameters of the sine wave on the fly? It would greatly simplify things if there were specific frequencies/amplitudes you needed for testing.
I may be able to make some changes to the FGEN code so that it never outputs more than 350 setpoints if you are not able to come to a workable solution with the information provided above.
06-08-2016 06:26 PM
Thanks for the details. It helps quite a bit.
Right, I do not see that error when setting each channel at 1 kHz. In fact, I can run all channels at 250 Hz. Below 250 Hz, I receive the same error. I also tried omitting Fetch Measurements but receive the same error with a different VI called "Power Abort".
In terms of amplitude, 0-100 uA. Frequencies range 0-1000 Hz. On occasion more than that. For long term measurements the frequencies will ranged from 1-100 Hz. The main waveform will be sine, the rest aren't used.
I made another VI that uses single point mode to be able to generate arbitrary waveforms from 0.1 - 5 Hz.
These parameters will need to be changed on the fly since the system is coupled to a SWITCH and I will need to eventually compile the VI into an EXE.
I was looking at FGEN and was wondering if it's possible to just use higher source delays for lower frequencies in order to decrease the setpoints?
srv565
06-09-2016 11:08 AM
Try using this version of the signal calculation VI. It makes sure that the output sequence is never larger than 350 setpoints and should prevent the underflow error.
06-09-2016 05:04 PM
Using Signal Calculation - Update.vi, all channels works as intended. Thanks for the updated VI!
srv565
08-05-2016 02:58 PM
HI Jared,
Would you be willing and able to save those samples as deprecated versions (to LV2010) so that I can open and review on my development system?
Thanks in advance,
--Tom
08-07-2016 07:58 PM - edited 08-07-2016 08:15 PM
Tom,
I did a Save for Previous to LabVIEW 8.6 (but did not test). Make sure you use the updated "Signal Calculation - Update.vi" attached. Please reply if you have any issues.
Edit: Helps if I actually add it as an attachment.
08-19-2016 09:58 AM
Hi
According to your description, I cannot use some of the SMU as the FGEN such as PXI-4130, can you tell me why? because I do not know the detailed difference between them
08-22-2016 10:20 AM
The PXI-4110 and PXI-4130 do not support hardware-timed Sequence Source Mode, so any attempt to produce a precisely-timed pattern would use the software-timed entry points and would be quite variable due to jitter.
All of our PXIe SMUs and Power Supplies to date support Sequence Source Mode.
08-23-2016 09:27 AM
08-23-2016 11:47 AM
Yes, the "intersample delay" is different for different SMUs. It's even different for different voltages / currents within the same SMU depending on the initial and final value. The analog front end on these devices is very comples. Unlike a real Arbitrary Waveform Generator, these aren't time domain instruments. There's no concept of Sample Rate or Frequency at all in the API.
To make things worse, it is possible, albeit unlikely, that a given "intersample delay" change between driver versions if the team finds that we can extract more performance somewhere or should settle something a little longer for some reason.
For these reasons, using SMUs to generate time domain signals such as a sine tone works, but is a little bit hacky. Trial and error, as you did, is as good an approach as any. You are using an instrument for something it wasn't intended to be used.
If you want really solid and deterministic "sample rate", you can use a different device to provide triggers at a known frequency and use that trigger to advance the steps in your SMU sequence.