Trigger configuration for a NI 6533

[RECrist]

Hi.

I am trying to generate a 32-bit pattern on a Ni 6533 using C++ and NiDaqmx upon the arrival of an external trigger but I've run into some problems.

 I create a channel and trigger with the following function calls:

DAQmxCreateDOChan (taskHandle, "port0:3", "", DAQmx_Val_ChanForAllLines);

DAQmxCfgDigEdgeStartTrig(taskHandle, "PFI6", DAQmx_Val_Falling);

And write some data like so:

DAQmxWriteDigitalU32(taskHandle,nsamp,false,m_timeout,DAQmx_Val_GroupByChannel ,data,&m_numWritten,NULL);

The result is that the data on the first two ports is output when the trigger arrives (as expected), but the data on the second two ports is output immediately when the task is started.

I understand, from the Ni 6533 user manual, that ports 0 and 1 are associated with group 1 timing controllers (like the PFI6 start trigger) and ports 2 and 3 are associated with group 2 timing controllers (like the PFI7 start trigger). However, the manual also indicates that when ports0-3 are combined for 32-bit output, one should use the group 1 timing controls.

Can anyone explain this behavior? I've done a quite a bit of searching through the forum but haven't found a description of a similar problem. Am I misinterpreting the documentation? Or could there be a problem with my card?

Any help would be greatly appreciated.

Thanks.

Roy

[RECrist]

Hi.

Can anyone help? If I need to provide more information, please let me know. I tried to include only the relevant statements from my code but I can certainly post more if it would help.

Thanks again.

Best regards,

Roy

[David L.]

Hi Roy,

The proper nomenclature when writing a 32 bit value is “Dev1/port0_32”. Please try this and post back if your results do not change.

[RECrist]

Hi. I've written a short and simple piece of code which reproduces the problem (pasted in below). When it is run, the data on the first two ports does not get generated until the trigger arrives, but the data on the third port is written out as soon as the task is started. Anyway, any suggestions would be welcome.

Best regards,

Roy

#include

<NIDAQmx.h>

int

main(void)

{

TaskHandle tH=0;

int32 nw = 0;

uInt32 data[15] =

{67808,68064,67808,68320,67808,

67824,68080,67824,68336,67824,

67584,67840,67584,68096,67584};

DAQmxCreateTask(

"",&tH);

DAQmxCreateDOChan(tH,

"/Dev3/port0_32","",DAQmx_Val_ChanForAllLines);

DAQmxCfgSampClkTiming (tH,

"",50,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,150);

DAQmxCfgDigEdgeStartTrig (tH,

"/Dev3/PFI6",DAQmx_Val_Falling);

DAQmxWriteDigitalU32(tH,15,

false,10.0,DAQmx_Val_GroupByChannel,data,&nw,NULL);

DAQmxStartTask(tH);

DAQmxWaitUntilTaskDone(tH,60);

DAQmxStopTask(tH);

DAQmxClearTask (tH);

DAQmxResetDevice (

"Dev3"); return 0;

}

[RECrist]

David:

Thanks for getting back to me. We must have been posting at the same time (see my previous post). In any case, I have tried specify the channel as you suggests, but the results are the same (see the code I just posted). Could there be a problem with my card?

Best regards,

Roy

[David L.]

Roy,

I ran the code that you posted, but was not producing the same results. I used a PXI-6533, and watched all ports. When no trigger happened, then nothing changed, and the card retained the last value which it was given. I then ran your code with the trigger line (DAQmxCfgDigEdgeStartTrig…) commented out, and the DIO lines changed state. If you have another DIO board, I would try that to see if this one may be faulty. I was using DAQmx 8.5 on Windows XP.

[RECrist]

David:

I'm using the PCI card and was using DAQmx 8.1 on XP. Yesterday, I upgraded to DAQmx 8.5 but the problem persists. So, it looks like the problem is the card. I'll try to get my hands on another card and let you know what happens.  In any case, thanks again for your help.

Best regards,

Roy

[RECrist]

David:

I tried running my test program with another PCI 6533. What I have discovered is that the first sample is written as soon as the task is started on all ports (including ports 0 & 1). Only subsequent samples are delayed until the trigger arrives. Is this the expected behavior?

Thanks again for your help.

-Roy

[David L.]

Roy,

Interesting behavior you are seeing. Thanks for the details, as the more information I have, the better I can narrow down the problem. Here are a couple of questions to help out a bit more:

How are you reading the values being output by the 6533? Have you tried this card on another computer? If you have another 6533, does that one exhibit the same problem? Do you get the proper outputs if you comment out the code for the trigger?

How old is the card (what is your serial number), and has it always exhibited this problem?

[RECrist]

David:

Hi.

>How are you reading the values being output by the 6533?

With an oscilloscope.

>Have you tried this card on another computer?

No.

>If you have another 6533, does that one exhibit the same problem?

Yes, both cards behave the same way. The first element in the buffer appears to be output as soon as the task is started. The remaining elements are not written until the trigger arrives.

>Do you get the proper outputs if you comment out the code for the trigger?

Yes.

>How old is the card (what is your serial number), and has it always exhibited this problem?

Card #1: 0x1139D9D

Card#2: 0x103667B

Do I understand correctly that this is not the expected behavior? For the moment, I can work around the problem by making sure that the first element of the data set is always zero. But I would prefer not to have to worry about it.

Thanks again for your help.

-Roy