Triggering MATLAB Script Externally Using NI-USB 6008

I'm currently trying to make a flash detector using MATLAB and a NI-USB 6008. When my sensor detects a flash I want it to trigger MATLAB to run a script as quickly as possible. Currently I am able to do this at around 100Hz using inputSingleScan within a loop. The 6008 however is capable of sampling at 10kHz, which is closer to what my application requires.

Does anyone have any ideas on how to speed this up? I'm currently using an analog input, I was thinking if I switched to the digital counter I could run it in trigger mode, but all I can get it to do is log the voltage data. Is there any way to get it to run a function instead of logging the data?

Here is sample code for reference:

s = daq.createSession('ni');
s.addAnalogInputChannel('Dev1','ai0','voltage')
s.Rate = 10000;

while 1
tic;
if inputSingleScan(s) > 0.05
    disp(' ')
    disp('%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%')
    disp('%%%%%%%%%%  TRIGGERED!!!!! %%%%%%%%%%%')
    disp('%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%')
    break
end
toc
end

Answer 1

[Walter Roberson]

Add a trigger. Then add a listener on DataAvailable; see http://www.mathworks.com/help/daq/ref/dataavailable.html. Then start data acquisition.

The session will sit not recording anything until the trigger condition is met, at which time data acquisition will start. That will trigger the DataAvailable event callback.

I do not know what rate you will be able to run at; in part it is going to depend upon how close together you might get triggered.

I seem to remember that people have a lot of trouble getting more than 3 or 4 kHz from the NI USB devices, but thinking back that have to do with transfer rates. If the NI device itself does not send anything until the trigger level is reached you might be able to set the sample rate high if you do not spend much computation time reacting to each of the triggers, but if the information has to be sent to MATLAB to evaluate whether a trigger occurred then you might not do nearly as well.

[Randall Hanna]

Good suggestion. I ended up trying it and it turned out to be the latter case unfortunately, much slower.

I fed a 1kHz square wave into the digital input to see if it could keep up, and logged the time of each trigger using:

function TriggerFunction()
    global time ;
    time = [time; clock];
 end

It was only able to trigger at around 10Hz.

[Walter Roberson]

global is slow. It would be faster to use nested functions and a variable defined in the outer context, perhaps together with a second function that could return the accumulated values. For example,

function retrieve_routine = setup_trigger
  time = [];                       %shared variable

    addlistener(... @TriggerFunction );
    retrieve_routine = @Return_times;

    function TriggerFunction(src, event)    %nested
      time = [time, clock];
    end

    function times = Return_times           %nested
      times = time;
    end
  end

and then run. When you stop somehow, call the retrieve routine to get the accumulated data.

The 'end' matching the 'function' are required in this context, and you will not be able to store this code in the same .m file that has functions that do not have 'end' matching their 'function'.