Problems with HwDigital Triggering in Matlab with the USB 6221

[DavidGarner16]

I'm having some problems with triggering the USB 6221 using the Matlab Data Aquisition Toolbox. I'm using TriggerType = HwDigital and I have hard-wired one of the two AO channels to PFI5 and am using this as my HwDigitalTriggerSource. Following triggering, I am gathering 50 samples from only one of the analog inputs using the other analog output as my convert & sample clock, again hard-wired to PFI6 and PFI7 which are my ExternalSampleClockSource and my ExternalScanClockSource, respectively.

My desired triggering rate is 1 kHz. The problem is that at this rate the DAQ only triggers on two consecutive triggering cycles, and then cannot be re-triggered until approximately 20 ms has elapsed. The first attachment below shows this - the yellow trace is my trigger signal (I have set TriggerCondition=NegativeEdge as I want to trigger on the negative edge of this signal), the blue trace is my sample/convert clock, and the purple trace is the trigger output from the 6221 (obtained by setting ExternalTriggerDriveLine=PFI8 and connecting the 'scope to this line). You can clearly see that the box triggers on two consecutive edges on the yellow signal and then waits for a while before retriggering.

The second attachment just zooms in on this ... another question I have is that I don't understand why the generated trigger signal (the pink trace) goes high on the first rising edge of the sample/convert clock rather than when the trigger signal goes low ... but I'm not really bothered about this as long as I can get the thing to trigger on EVERY negative going edge of the yellow signal.

I have copied and pasted the results of get(ai) in matlab below. I'd be grateful for any help or advice. David.

        BufferingConfig = [4096 384]
        BufferingMode = Auto
        Channel = [1x1 aichannel]
        ChannelSkew = 4e-006
        ChannelSkewMode = Minimum
        ClockSource = ExternalSampleAndScanCtrl
        DataMissedFcn = @daqcallback
        EventLog = [1x374 struct]
        InitialTriggerTime = [2009 7 16 14 9 10.0642]
        InputOverRangeFcn = []
        InputType = SingleEnded
        LogFileName = D:\MATLAB\test.daq
        Logging = Off
        LoggingMode = Disk&Memory
        LogToDiskMode = Overwrite
        ManualTriggerHwOn = Start
        Name = nidaqmxDev2-AI
        Running = On
        RuntimeErrorFcn = @daqcallback
        SampleRate = 52356
        SamplesAcquired = 18650
        SamplesAcquiredFcn = []
        SamplesAcquiredFcnCount = 1024
        SamplesAvailable = 18650
        SamplesPerTrigger = 50
        StartFcn = []
        StopFcn = []
        Tag =
        Timeout = 1
        TimerFcn = []
        TimerPeriod = 0.1
        TriggerChannel = [1x0 aichannel]
        TriggerCondition = NegativeEdge
        TriggerConditionValue = 0
        TriggerDelay = 0
        TriggerDelayUnits = Seconds
        TriggerFcn = []
        TriggerRepeat = Inf
        TriggersExecuted = 373
        TriggerType = HwDigital
        Type = Analog Input
        UserData = []

        NIDAQMX specific properties:
        ExternalSampleClockDriveLine = PFI9
        ExternalSampleClockSource = PFI6
        ExternalScanClockDriveLine = PFI10
        ExternalScanClockSource = PFI7
        ExternalTriggerDriveLine = PFI8
        HwDigitalTriggerSource = PFI5

[DavidGarner16]

After nearly a week trying to debug this issue, I have found that there seems to be some latency following an aquisition before the 6221 will allow another trigger event to take place. That latency appears to be around 90ms - i.e., you can't retrigger the box within the 90ms following an aquisition.

Can this really be the case? Or do I have some settings wrong somewhere?

Any advice gratefully received.

[sahpe]

Hello David,

I apologise that your question was not picked up earlier.

I would advise having a look at this KB and the examples it refers to:

http://digital.ni.com/public.nsf/allkb/82DAECADE90CC56F8625659200675B2A 

Can you check whether you get the same latency with these pieces of code?

I hope this helps,

Kind Regards,

Michael S.
Applications Engineer
NI UK & Ireland

[miskoL]

Hi,

Report Date: 01/20/1998

i've read the suggested KB, however i noticed the report date is old. does this issue still occurs to NI hardwares?

TQ.

[sahpe]

Hello miskoL,

There is no issue that occurs with NI hardware at all. The user that originally posted on this forum described what they were seeing and this KB explains ways to avoid that behaviour. The date is irrelevant. These KBs most of the times are articles that help users out of caveats and pitfalls from incorrect coding or configuration of our software and hardware. If there is a true issue with our products, you will find that this will be mentioned specifically in the article along with what upgrades or changes you will need to your software or hardware to avoid it.

Is there a specific problem that you are seeing yourself? I would advise searching and reading through all of our online content to find if there is a solution to what you are seeing, and if there isn't then it would be better to create a new thread instead of replying to older threads. You are lucky that I kept myseld subscribed to this one! Alternatively, if you have an active contract with NI, you can call or email us directly and we will be more than happy to help!

Kind Regards,

Michael S.
Applications Engineer
NI UK & Ireland

[miskoL]

Hi sahpe,

i thank you for replying to my post. i have the problem with the original OP. apparently there need to be some delay before each acquisition.

i didnt configure my counter to produce a pulse train as the KB suggested, but i used a microcontroller to produce the pulse for start trigger:

ai = analoginput('nidaq','Dev2');

set(ai,'InputType','SingleEnded');

addchannel(ai, 0:15); 

dio = digitalio('nidaq','Dev2');

dout = addline(dio,8:9,'out');

set(ai,'SampleRate',15625)

ActualRate = get(ai,'SampleRate');

set(ai,'SamplesPerTrigger',2)

set(ai,'TriggerType','HwDigital')

set(ai,'TriggerCondition','PositiveEdge')

set(ai,'TriggerRepeat',16)

set(ai,'HwDigitalTriggerSource','PFI2')

so i hard-wired a port from PIC to PFI2. i noticed that if the delay between each start trigger(from PIC) is short (eg. 1ms), if i checked the available samples after 16 triggers have been sent using 'ai.SamplesAvailable', most of the supposed data to be acquired is missing. usually 10-12 samples will be available from supposedly 32 samples.

but if i increased the delay significantly around > 80ms between each start trigger(from PIC), calling the 'ai.SamplesAvailable' will give results of 32.

this result is not desirable, i need the delay to be as short as possible.

i've even used these setting:

set(ai,'SamplesPerTrigger',2)

set(ai','ClockSource','ExternalScanCtrl');

set(ai,'ExternalScanClockSource','PFI3')

for this setting, i needed to manually produce 2 pulses for each acquisition since the minimum value for samples per trigger is set to 2, so 2 pulse for each SamplesPerTrigger. unfortunately, same latency problem occurs. is this hardware limitation, can this problem be avoided or not?

Thank you.