Synchronize DI & DO of NI 9401

[angelmcdoggie]

Hello Everyone,

I have two NI 9401 modules and I want to configure an input and output in each module.  The output will generate a command while the input receives data from the user.  How do I achieve synchronization of the DI and DO modules?

Regards and thanks!!!!

[mallorim]

Hi Angel,

There is a shipping example called "Multi-Function-Synch Dig Read write With Counter.vi" That has three parallel tasks.  There is a Counter Output Task, a Digital Input Task, and a Digital Output Task.  The counter generates the "Sample Clock" and you will notice that Dev1/Ctr0/InternalOutput is used as the timing source for the digital I/O tasks.  It sounds like this example would work for your customer with little modification. 

Just change your digital output channels to say:
cDAQ1ModXXXXX/port0/line0:7  Where X is the slot of the 9401

And change your digital input channels to say:
cDAQ1ModYYYYY/port0/line0:7  Where Y is the slot of the 9401

Then of course change your counter to say:
cDAQ1/_ctr0 (you will need to enable internal channels in the "I/O Name Filtering")

The tutorial below also discusses how to do this with LabVIEW.

NI-DAQmx: Correlated Digital I/O with NI CompactDAQ and LabVIEW

http://zone.ni.com/devzone/cda/epd/p/id/5256

Regards,

          Mallori M.

[angelmcdoggie]

Hello M,

Thanks for sharing this information.  However I am using VC++ and it doesn't come with a shipping example of that title.

Is it possible to use two DIOs only for synchronization?  I don't want to use extra resource of NI 9401 to create a counter task.

Best regards,

A

[mallorim]

Hi A,

The problem is that, unlike analog input, when a digital input task is configured and started, a sample clock is not generated. This means that in order to synchronize the two tasks, in  order to even have hardware timed digital input or output, an external clock has to be provided. The most efficient and easiet way to do this is to use the chassis's counter to generate a sample clock.

The Solution's third paragraph in the Knowledge Base 4CM6E5T3 Can I Use Different Sample Clocks for Correlated DI and DO? and the related links User Guide do a great job of explaining the sources for this external clock and its necessity.

Is there a reason you don't want to use one of the chassis's onboard counters?

Regards,

Mallori

[angelmcdoggie]

Thanks again M,

Yes I can use the onboard counter.  I just didnt have a clear understanding that's why I didn't thought of that before. 

I'll keep you posted with my progress. 

Regards,

A

[angelmcdoggie]

HI again,

I ran my clock source using "cDAQ1/_ctr0" for synchronization.  However, there are items that are unclear to me and with that I have some follow-up questions.

1.  I wrote a timing for my digital input and output tasks.  Do I need both timing or only a DI or DO timing will suffice?

2.  When I used the "cDAQ1/_ctr0" clock source in this API called,

[angelmcdoggie]

..oooopsss sorry for the repeat post....

where clock = "cDAQ1/_ctr0"

m_DITask->Timing.ConfigureSampleClock(clock, 1000, DAQmxSampleClockActiveEdgeRising, DAQmxSampleQuantityModeFiniteSamples, samples);

m_DOTask->Timing.ConfigureSampleClock(clock, 1000, DAQmxSampleClockActiveEdgeRising, DAQmxSampleQuantityModeFiniteSamples, samples);

If I use that API for both timings, I encounter this status error: -8190.  See attachment please.  However, if I use separate APIs for the parameters, I did not encounter any status error.

m_DITask->Timing.SampleClockSource = clock;

m_DITask->Timing.SampleClockActiveEdge = DAQmxSampleClockActiveEdgeRising;

m_DITask->Timing.SampleClockRate = 1000; m_DITask->Timing.SampleQuantityMode = DAQmxSampleQuantityModeFiniteSamples; m_DITask->Timing.SamplesPerChannel = samples; m_DOTask->Timing.SampleClockSource = clock; m_DOTask->Timing.SampleClockActiveEdge = DAQmxSampleClockActiveEdgeRising; m_DOTask->Timing.SampleClockRate = 1000; m_DOTask->Timing.SampleQuantityMode = DAQmxSampleQuantityModeFiniteSamples; m_DOTask->Timing.SamplesPerChannel = samples;

The 1st and 2nd timing snippets looks the same to me so I feel weird getting a status error in the 1st snippet. 

3.  What is the difference between these two signals? 

     "cDAQ1/_ctrX"   vs  "/cDAQ1/CtrXInternalOutput"

    I use them on a trial and error basis but I have no clear idea regarding their usage, pros and cons (if any).

Thanks for being patient with my inquiries. 

Best regards,

A

Message Edited by angelmcdoggie on 06-19-2008 07:00 PM

[mallorim]

Hi A,

1. Yes, you will need to configure timing for both DI and DO since they are separate tasks and each will need a sample clock.

2. and 3. I apologize, the reference I had originally posted was a string that no longer works. "cDAQ1/_ctr0" is no longer a valid input option. You will need to use the "cDAQ1/Ctr0InternalOutput" in order to get the application to run. Thank you for posting the image of your error. This let me spot the problem right off because the text was available, where as just the number was meaningless. You will notice that the error text says that cDAQ1/_ctr0 is not a valid input.

In summary, I'm sorry for not catching the wrong string earlier. Use the cDAQ1/Ctr0InternalOutput option and you should be good to go.

Regards,

          Mallori M

[angelmcdoggie]

Hi there M,

"cDAQx/_ctr0", "cDAQx/_ctr1" are in the Internal Channels for C Series topic of the NI-DAQmx Help.  Is the "cDAQx/_freqout" signal also invalid?

This time, I shifted to "cDAQ1/Ctr0InternalOutput" as my clock source.  I encountered the same error when I used "cDAQ1/_ctr0".  That status error was generated when I used the 1st API (based from above thread).  However, if I used the 2nd API, no errors were generated.

Super thanks again,

[mallorim]

Hi A,

Ok, so I have tested this in LabVIEW a number of different ways. LabVIEW is the only environment I have on my computer, and I can get both cDAQ1/_ctr0 and cDAQ1/crt0InternalOutput to work. So, that means that both names are correct and the DAQmx help is not, in fact, wrong. In order for the _ctr0 to work, you just have to go into the IO name filtering option and enable internal outputs, which was not done on my earlier test system.

So now I guess the only question is why does configuring the sample clock in one function result in an error that is avoided by using separate lines to configure each sample clock setting? I am not sure as to the cause of this. It might be something similar to the fact that in LabVIEW you have to enable the I/O Name Filtering to make the internal connections visible. Maybe in this text based environment individually configuring each setting allows access to options that are not available when you try and configure it in one. Like I said, I am not sure though. You are able to get the program to run without errors by calling each setting separately though, correct?

Regards,

Mallori M.