Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Use Clocks, Triggers Etc from CDaq -9174 in Digital Input Task using NI 9421

Apparently the cDAQ chasis concept is lost on me, because I cannot get any of the triggers/sample clocks or other fancy features on the cDAQ-9174 to work with my simple Digital Input Module NI9421. I have three digital sigals created by Hall sensors coming into the Front of the Module. I know they work, because the LEDs all toggle when I run my magnets over them. 

However when I try to create a Digital In task, and then connect a start Trigger, or Reference Trigger , the only options available are other Ports on the Module.

cDAQMod2 is the Digital Module NI9421, PFI0-PFI7 are ???? I think the ports on the board. 

tmcneil_0-1666303486177.png

 

Whether it is the Sample Trigger or the Reference Trigger, I get the same options for cDAQ2Mod2/PFI0-7 as triggers. 

tmcneil_1-1666303560899.png

 

According to the cDAQ Manual, there a re multiple Triggers available on the Chassis, why can't I see or use them? 

tmcneil_2-1666303692437.png

 

The manual also says I can route these to ANY PFI Terminal, which may be(or Not) the PFI0-7 entries I see in the dropdown lists on the Max application. Unfortunately, I cannot find information on how to route these to anything. 

If I look at the Device Routes for the cDAQ-9174, it has lots of green entries, but all of them tie back to another port on teh cDAQ-9174, there are no entries for any of the modules . 

tmcneil_3-1666303882620.png

If I look at the device table for the NI9421 DI Module, it shows no possible connections to anything, anywhere. 

tmcneil_4-1666303959256.png

 

 

If I try to use the DI Sample Clock of the cDAQ to run the Digital Input Task 

tmcneil_5-1666304080417.png

 

I get an error that tells me I have routed the cDAQ DI SampleClock, to the cDAQ DI Sample Clock

tmcneil_6-1666304159687.png

 

Which does not make sense, because the cDAQ DI Sample clock is supposed to be used by the NI 9421 Digital Input Module to read the Digital input at that rate. Eventually, I would like to use a single sample rate and trigger to synchronize reads of a Digital Input Module NI 9421 and an Analog Input Module NI9229. 

From the looks of the MAX application, it will not be possible to make a single task that would do both of these, and I can only run one task at a time . 

The Eureka moment will be to have a Labview application that can read all these signals, using the same sample clock and same sample trigger so the measurements are synchronized. That data would then be dumped into a single array to write out to a file. 

The last attempt I made, the deviation in sampling between the Analog and digital signals was 20% ( with a signal frequency of 100 Hz and sampling frequency of 10KHz)

Is it possible to run two tasks in Max at once? Can I have a single task in Max that reads both on the same task? 

0 Kudos
Message 1 of 6
(217 Views)

A couple things to get you started:

 

1. Terminology: what you mainly need is a shared sample clock.  Under DAQmx, a sample clock is what's used to capture samples, with each cycle of the clock causing one more sample to be captured.   On the other hand a trigger is a one-time event for the duration of the task, often used to start it.

 

2. Your 9229 module uses a Delta Sigma converter, which complicates things a little bit.  See this article for more info.

    To make a long story short, you're going to need to configure your DI task to "borrow" the AI task's sample clock as its own.  And then it will be important to start the DI task first so it will be ready to sample when you later start the AI task and it starts producing a sample clock signal.

 

3. In LabVIEW, you can right click the 'source' terminal in the call to DAQmx Timing for your DI task and select "Create Control".  Then look in the drop down list for a terminal that includes ".../ai/SampleClock" in its name.  That's what you'll need to use so that DI sampling is driven by the AI task's sample clock.

    (Note: It's possible you'll first need to right-click the control, select "I/O Name Filtering...", and then check the box to include advanced terminals.)

 

4. Even after all this, you still need to deal with the AI module's time delay as described in the linked article.  The simple way is to read and discard the right # of initial samples from the AI task, b/c they represent voltages from the past that had to work their way through digital filtering before the first sample clock was issued to capture them.  The first several AI samples are all voltages from a time before the first DI sample was taken, that's why they should be discarded.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 2 of 6
(169 Views)

Kevin , Thanks very much for the help. That is starting to clear things up. 

 

If I already know the signals are being generated, do I need a trigger or can I start capturing input data as soon as the Run button is pressed? 

 

I Used the DAQmx timing node to read the SampClk.SRC property from the Analog channel, then tried to Write that to the Digital Read task, however I get the following error

tmcneil_2-1668792544433.png

 

I am assuming that the error is in Writing the property from the Analog In Task to the Digital In Task, but since the Task Name doesn't show, I will never know

I attached the VI I am trying to build. Forgive all the extraneous array and graph indicators. I use them for troubleshooting

 

 

 

 

0 Kudos
Message 3 of 6
(112 Views)

There's a subtle distinction in DAQmx terminal terminology.  Picture the sample clock timing circuitry as a black box.  The sample clock Source is an input to the black box, while the sample clock Terminal is the output from it.

 

So you generally have to route FROM a terminal TO a source.  Like this:

 

Kevin_Price_1-1668802340311.png

 

Dunno where to point anyone to learn about this, I learned it from the school of hard knocks.

 

 

-Kevin P

 

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 4 of 6
(101 Views)

Kevin,

Thanks again for your help with this. I am able to get the properties routed from one Task(Channel) to another.

I believe I have the AI sampleclock now running the DI Sampleclock

tmcneil_0-1669224345422.png

 

I included a section of code to take X number of presamples 

tmcneil_1-1669224396453.png

 

In this case 500

 

tmcneil_2-1669224500346.png

 

First item of interest is that the Presampled Data Indicator, does not accurately reflect the desired Presamples, In this case , there are only ever three values . No matter what I do, it is always a 1D Array of 3. 

tmcneil_3-1669224769909.png

 

 

I also notice that my final data sizes, although set to 1000 for both Analog and Digital are different. The Analog In output is 2D array  500x4, the Digital is 1000x3. This is after I break the Waveforms down to their component Peices and Build a new Array for Analog and Digital .

Prior to that, I display the two waveforms in an Mixed Signal Output Graph. It is obvious from the graph , that the digital In was sampled/measured many more times.

tmcneil_6-1669225196615.png

 

I thought this would be taken care of by the pre-sampling. 

What is frustrating though, is that data output isn't synchronized at all. 

THe Analog data starts recording well after the digital data is recording

 

tmcneil_5-1669225162494.png

 

If you zoom into the Start of the waveform(Analog) . THe Analog values in the table look correct, but the Digital Values are not (Index 0 is 011, but the value on the graph shows 010). If I zoom to the front of the Digital Waveform, then the values 011 are correct. 

tmcneil_7-1669225425065.png

So now I am guessing that the Digital Reads and Analog reads, although using the same SampleClock, still aren't synchronized, so that index 0 off all the Input (AI and DI)reads starts at the same point in Time. 

I did read in this article https://www.ni.com/en-us/support/documentation/supplemental/21/signal-based-synchronization-of-analo... , that SampleClock Synchronization does not work the same for Delta Sigma modules. 

I can't use the method of putting two Measurement Tasks  in the same channel, because they are different types(Analog and Digital) and all the examples only show Analog In tasks. 

I am at a loss now, I tried using the AI/StartTrigger for the Digital In task, but that doesn't appear to make a difference. 

 

I attached the present state of the VI , please disregard the crudeness. I hate to keep bothering you, but you have been the only person answering. NI support appears to nly support if you pay them lots of $$$. 

 

Thanks for any help on this continuing issue

 

0 Kudos
Message 5 of 6
(70 Views)

I made some minimal changes with focus on issues of sync.   There's probably more to be done, but this should get you closer.  Of note:

 

1. Define the # samples to collect in the calls to DAQmx Timing when setting up a Finite Sampling task.

 

2. Define the # samples to read in the calls to DAQmx Read.  Your front panel had default values of -1, a value which carries special meaning in DAQmx.  Safest to define the # samples you want to read.

    I changed the default values on the front panel to be positive integers.  I did not try to make them the *right* integers. I'll leave that for you.   (The right value for presamples depends on the "input delay" or "filter delay" specs for your AI device.  The right value for 2nd reading is whatever your app needs it to be.)

 

3. I slightly tweaked the method for sharing the AI sample clock, exporting from the SampClk Terminal rather than SampClk Source.   This was the terminology thing I mentioned in a previous reply.

 

4. I disabled the code that sets up triggering for the DI task.  I suspect it was part of a further attempt to force sync.  I figured that once I helped get the sample clock shared correctly, there'd be no need to rely on a trigger.

 

 

-Kevin P

 

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 6 of 6
(55 Views)