DAQ card error -200284

[colibri90]

Hello,

I am using a PCIe-6323 to count TTL signals from a photon detector. I trigger the counter with pulses from a Spincore PulseBlaster card. Normally I don't have a problem with data acquisition, but with longer/more complex pulse sequences, I sometimes get a -200284 error:

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

This happens randomly but most often happens when pulses are close together. When I see this error, my counter shows a much bigger value than otherwise, as if the counter gate is left on at all times. Also, it only shows counts for the first gate, when my pulse sequence has multiple gates. Does anyone have ideas for diagnosing this problem? Is there maybe some timeout option I can edit?

[Kevin_Price]

1. Please post your code.  Be sure that any config parameters on the front panel have their values saved as default.  And it'd be a good idea to "Save for Previous Version..." back to 2016 or so.

2. I've found that not everyone has the same idea of what counter terminology means.  You're using the term "gate", but that term isn't in common use under DAQmx.  (It *used* to be common terminology under the legacy driver, but I've been away from that for > 15 years now.)   So please describe what kind of measurement you're trying to make and what role you expect various signals to play (such as pulse signals, "gate" signals, other clocks, etc.).

Your error is a timeout meaning that the system didn't have enough samples built up in its buffer within the time you allowed in your call to DAQmx Read.   Since you get your errors intermittently, that narrows down the suspects a bit.  But there are still too many possibilities to be worth speculating without code.

-Kevin P

[colibri90]

Thank you for the reply.

I forgot to point out that I use MATLAB to interface with my DAQ card. Below is the main code that executes my pulse sequence. I found that I sometimes get the error after running the line "DATA = RunExperiment(DATA,planSweep,hObject, eventdata, handles);" However, I should also point out that a colleague of mine uses the same code for the same sequence on his computer and does not get an error. 

% The main experiment loop
for ave = 1:planSweep.Average % Outer loop: how many times to repeat the whole thing
counter = 0;
%update the average number on the gui
UpdateAverageIndicator(ave,planSweep.Average,handles, EstimatedTime);
planSweep.IndexAve = ave;
%Loop
for sl = planSweep.Loop(2).IndexV %put in a stop here when doing phase tracking. Track stop line 1. As of 12/3/18, I think this is the correct line for saving the ESR/phase tracking structures
planSweep.Loop(2).Index = sl;
for fl = planSweep.Loop(1).IndexV

% a = planSweep.Loop(1).IndexV;
% a
gRepPara.ESRTracking = get(handles.ESRTracking,'Value');
planSweep.Loop(1).Index = fl;


PrepareSEQandSG(planSweep,hObject, eventdata, handles); % Updates seq or SG based on what you're sweeping

gRepPara.RFfreq = str2num(get(handles.edit29,'String')) * 10^3;

%return
planSweep.IndexRun = planSweep.IndexRun + 1; %Index needed for Fourier data srtucture

% Run experiment and collect data
DATA = RunExperiment(DATA,planSweep,hObject, eventdata, handles);

if get(handles.bPlotUpdate,'Value') == 0
esrflag = [0];
fid = fopen('esrtrack_flag.txt','a');
fprintf(fid,'% d % d % d % d \r \n ',esrflag);
fclose(fid);

PlotDATA(planSweep,DATA,handles);

end

%update progress bar
if get(handles.bPlotUpdate,'Value') == 0
UpdateProgressBar(sl*fl,TotalLoopElements,handles);
end

PhaseTrackN = 500;
iTrackPhase = iTrackPhase + 1;

% if gRepPara.ESRTracking && (iTrackPhase ~= PhaseTrackN)&&(rem(iTrackPhase,PhaseTrackN)==0);
% SetPhase;
% end

................................................

function DATA = RunExperiment(DATA,planSweep,hObject, eventdata, handles)
global gRepPara gbRunGo gmSEQ;

path = 'C:\Dev-Cpp\Examples\pulseblaster\pbesrpro_devc\';
file = 'UniversalPulsedESR_V2.exe';
%%%%%% Get time out %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

R = 1; bPBGo = true;

while bPBGo & R <= gmSEQ.NTimes

if planSweep.Loop(1).bSweepWithPB
%disp('Reseting SG sweep');
Device('SG',['ABOR ']);
end
PBFunctionPool('PreprocessPBSequence',gmSEQ);

global gTimeOut

timeout = gTimeOut;

status = StartCounter(planSweep); % Start the counters
PBFunctionPool('RunPBSequence'); % Run the PB sequence
[A,sCounter1] = ReadCounters(planSweep,timeout); % Read in captured data
StopCounter(planSweep); % Stop counters when done

repeatPoint = 2;
while (sCounter1<0)& repeatPoint < 2 % Hard coded to be inaccessible, ignore?
[status1] = StartCounter(planSweep);
%status = dos([path file]); %Start Pulse Blaster
PBFunctionpausePool('RunPBSequence');

[A,sCounter1II] = ReadCounters(planSweep,timeout);
%[A,sCounterII] = ReadCounter(hCounter,planSweep.N,timeout); %uint32
StopCounter(planSweep);%DAQmxStopTask(hCounter);
%The following line should be uncommented during normal operation
if (sCounter1II < 0), repeatPoint = 0; end
repeatPoint = repeatPoint + 1;
if ~gbRunGo break; end
end

DATA = ProcessData(DATA,A,R,planSweep,handles); % Process the data

R = R + 1;
if ~bPBGo, break; end
if ~gbRunGo break; end

end

After the PusleBlaster outputs a complex pulse sequence which is not relevant to the problem, it outputs another pulse which causes the DAQ card to start counting TTL signals from my photon detector for 700 nanoseconds. By "gate pulse" I meant the pulse which allows my DAQ card to start counting signals from the photon detector. I run my pulse sequence many times (on the order of 100,000 times) and average the data from each run. I've also found that if I lower the number of samples (say, from 100,000 to 1000), the error is less common, but does not always disappear.

[Kevin_Price]

I'm afraid I'm pretty unfamiliar with the Matlab API for DAQmx functions and have been unaccustomed to text language programming in general for a long time.  I tried scanning through your script, and couldn't identify any of the parts I was looking for, namely the specific calls to the DAQmx functions that configure the counter task before starting it, reading from it, and stopping it.

It sounds like your PulseBlaster issues a pulse with a 700 nanosecond pulse width and you want to count photon detector pulses *only* during those 700 nanoseconds.  But you also want to repeat this cycle as many as 100k times.  Is this right?

The natural way to do *this* kind of "gating" is to configure the counter task to use the 700 nanosec pulse as a "pause trigger".  But with the need to 100k cycles, I wouldn't expect you to want to keep stopping and restarting the task.  If the PulseBlaster runs indepenently, you'll likely miss some (maybe many?) cycles of activity due to the overhead of your script loop, part of which is the overhead of stopping and re-starting the task.

A better (but still pretty straightforward) approach would likely be to configure for a continuous measurement while specifying the trailing edge of the 700 nanosec pulse as a sample clock.  Then do a diff() on the array of counts you get.

    Alternately, you might be able to configure for count reset on the leading edge of the 700 nanosec pulse.  I'm not 100% sure it's possible to have both pause triggering and count reset configured at the same time though.

-Kevin P

[colibri90]

Yes, I'm afraid the code for the GUI I use is scattered over dozens of files, so it's hard to diagnose the problem this way.

You are right that I want to count photon detector pulses only during the 700 ns pulses, although there are actually six such pulses in my sequence. And I run this sequence up to 100k times to average my data.

Thanks for your suggestions. Do you happen to know if there are some DAQ options I could change outside of my Matlab code? I find it odd that the pulse sequence with the exact same code works on another computer with the exact same hardware.

[Kevin_Price]

I just had a better idea for you.

Configure the measurement counter to measure pulse width in units of ticks.  Assign the 700 nanosec pulse as your 'input terminal' and your photon pulses as your 'counter timebase'.  This will *directly* measure the # of photon pulses occuring within each 700 nanosec interval, and each sample will automatically restart counting from 0.

There's a way to define DAQmx global channels and tasks in MAX.  If the Matlab scripts depends on such pre-defined channels or tasks, differences in that configuration *could* be a reason why one PC throws errors and one doesn't.  But it's also quite possible (maybe likely) that the tasks are defined from scratch within the scripts, eliminating this possibility.

-Kevin P