Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Frequency problems when trying to output digital byte serially with 9401 and cDAQ-9172

I am trying to design a 3 line serial communication interface.  There is a clock, data, and enable line.  Ideally, I would like the clock to operate at 10 MHz and the data line at half of that.  I have the clock working properly with a DAQ assistant.  I was able to verify the output of the 9401 using a oscilloscope.  Next, I would like to send an 8-bit sequence upon command.  Everything seems to be working fine in LabView.  I am using a Digital Waveform Graph to monitor the data output, and the bits and frequency are correct.  However, when I attach the scope to the 9401 output, the bits appear to be correct, but the frequency is around 500 Hz.  How can this be?  I am taking the same line that is going into the Digital Waveform Graph and feeding it into a Digital Wfm 1Chan NSamp DAQmx vi.  Am I dealing with some sort of hardware limitation, or is there something else I'm not thinking of here?

 

Thanks,

 

Eric 

0 Kudos
Message 1 of 4
(3,800 Views)

Hi Eric,

 

Thanks for posting.  It looks like the code you posted is using software timing for your digital output.  The 500 Hz rate that you are experiencing is the rate that your computer is processing the while loop.  In order to get into the MHz range, you will need to implement hardware timing.  For Digital Output, this means you need to first write the data to the buffer on your 9401, then start the task.  The following code is one of the DAQmx examples showing a basic continuous digital output.  You can find the example through the Example Finder under Hardware Input and Output>>DAQmx>>Digital Generation>>Cont Write Dig Port-Ext Clk.vi

 

Continuous Digital Output 

 

This code should be a good starting point for performing continuous digital output.  If you need to change the data that is being sent while the code is running, you would need to stop the task to rewrite to the buffer on your card.  Thanks again for posting, let me know if you have any questions.

 

-John 

Message Edited by John P on 10-02-2008 03:48 PM
John Passiak
Message 2 of 4
(3,756 Views)
I have looked through examples similar to that in the past.  The reason I chose not to use that particular one is because it says "Ext Clk" in the title.  I do not want to use an external clock.  If I had that capability, I wouldn't be using the DAQ euipment at all.  Also, a lot of the examples are for outputting continuous digital signals.  I only want one continuous signal (clock), which I have already, and then I want to send 8 bits on command.  When trying to get that example to fit my need, I ran into the same problem I usually run into when using the DAQ equipment:  selecting a clock source.  I have worked on a few projects where I needed to select a clock source, but it never works.  Seems like I get a different error for every different clock I try.  I can't find any real helpful documentation on what all of these clocks are, or why I cannot use them.  Why wouldn't "On-board Clock" work in my case?
0 Kudos
Message 3 of 4
(3,720 Views)

The cDAQ-9172 does not have a dedicated digital timing engine.  That's why you see it error when you select Onboard Clock.  NI calls this "correlated digital" since users tend to correlate their digital data to an analog acquisition/generation.

 

Ok, so you can't automatically generate your own clock by using Onboard, but you can generate one from other resources on the chassis.  The easiest way to do this is to use a counter to create a pulse train generation. Select one of the two internal counters for the pulse train generation (such as cDAQ1/_ctr0 where cDAQ1 is the name of your chassis).  On your digital task, set the sample clock source to cDAQ1/Ctr0InternalOutput.

 

An alternative to using a counter is to actually create an AI/AO task and use that as your sample clock source.

 

The cDAQ-9172 user guide explains some of the possibilities on page 36 under the heading "DI Sample Clock Signal".

Message 4 of 4
(3,703 Views)