Error when creating a counter pulse output as source for sample clock

[Alice_C]

Greetings everyone,

I am new in the Labview community and have looked in several related topics in the forum or in the NI documentation. Unfortunately, I am still struggling with making my program working properly.

I am using a chassis cDAQ9174 with 2 modules : NI 9401 and NI 9223. Three analog voltage inputs that I want to sample are connected to the module 9223. The sampling begins with an external trigger that is connected to the 9401 module in PFI0 (cDAQ1Mod2/PFI0) and that will send only one pulse.

When the trigger is activated, I'd like to use a Sample Clock to ask a sampling of the three analog inputs during 10 ms every 1 s. To do so, I've thought about creating a counter output (CO Pulse Time) on the 9401 module (cDAQ1Mod2/Ctr3) and use the output (cDAQ1Mod2/PFI5) as a source for the sample clock of my analog inputs. You can find attached a picture of the program.

By doing so I get the following error "Specified route cannot be satisfied, because it requires resources that are currently in use by another route."

I tried several others wiring but I still have errors. I have the impression that this error is caused by the port PFI5, used as a digital output created by me, and as a source for my other task (analog inputs). Do I have to change the name of the terminal for the sample clock source?

I'm pretty sure I'm doing something wrong but I have no clues...

Thank your for your help,

[Kevin_Price]

Though I'm as big a fan of counters as anybody, I don't think you need to use one here for your sample clock.  The default behavior if you don't wire anything to the 'source' input of DAQmx Timing is for the chassis to provide the sample clock signal.  That's probably gonna work out better for you.

Now, onto the error you get.  I don't know the cDAQ family nearly as well as I know desktop boards, so these are guesses.  Fairly educated guesses, but guesses nonetheless.

I see references to "Mod2" for PFI pins and for a counter.  I don't think either of your modules *has* a counter on board.  I'm not sure what's considered a PFI pin in your setup, but if it's on your digital module and you're trying to reference it for your analog task, DAQmx will probably be trying to make a route for the signal through the chassis.   Some such routes need to be made indirectly by using a chassis counter.

The error text makes it sound like 1 route is in place but a 2nd one throws an error due to the 1st one using resources the 2nd one needed.  My guess is that both those routes are indirect and want to use the same chassis counter.

My advice: delete the terminal and wire for "...PFI5".  This will let the chassis generate the AI sample clock.  It may also allow the routing for the PFI0 trigger to succeed.   (You can then also delete everything related to the counter task, which would likely start throwing its own errors b/c as far as I can tell, your modules don't *have* a Ctr3 on them.)

-Kevin P

[Alice_C]

Hi Kevin,

Thank you for your reply. The sampling effectively works if I use the on-board sample clock and I have no issues by doing so.

However, I didn't precise that the 3 analog inputs are continuous sinusoidal waveforms with a 20 kHz frequency. 

I want to sample them with a sampling rate of 500 kHz to get the shape and then do some harmonic calculations on it to study the evolution of these waveforms.

As 500 kHz is a high sampling rate and to avoid to full the memory, I'd like to sample these analog inputs every 1 s during 10 ms. If I use the on-board clock I have only the first 10 ms signal with "finite sample", or maybe I am still missing something?

I was also thinking of using a timed-loop structure but I am not sure I will resolve my problem with that. I think that the best way would be to create a digital output as a trigger source, and this digital output should be continuous and triggered by the external pulse I get at the beginning of the test. 

Thank you,

Alice_C

[Kevin_Price]

There are very many possible paths forward, let's aim for a simple one unless you have some very strict and not-yet-revealed timing requirements.

1. Make a subvi out of your data acq code that successfully acquires 10 msec of data when it gets triggered.   Then from your main application, call this subvi every time you can expect another trigger to be coming in the next second.

2. See if your AI module supports hardware retriggering.  If so, set the DAQmx Trigger property in your task to make it retriggerable.  Then, once you start the task the first time, you just need to loop over DAQmx Read calls.  They won't return with data until the next trigger comes in to initiate the next chunk of finite acquisition.

There's a bunch of other ways to approach this, but if one of these two work out they're probably about the simplest.

Note: you might be artificially constraining yourself by looking at only 10 msec per second.  DAQmx can keep up with continuous acquisition at 500 kHz on 3 channels if you would *want* to.  You're right that you wouldn't want to accumulate that data in PC memory indefinitely, but there are various ways to avoid *that* part of the problem while still having access to *all* the data.

-Kevin P

[Alice_C · Accepted solution]

Dear Kevin_Price,

Thank you for your help and comments.

I managed to use a counter output of my cdaq chassis to create a continuous digital pulse used to trigger finite samplings of my 4 AI.

In fact, I had these errors before because I was enabled to find the InternalOutput of the chassis, it worked when I included "advanced terminals" in the I/O filtering.

And as you advised me, I used the property "retrigger" to sample several times in a finite mode. I just need to integrate in the while loop a Start/Stop task, otherwise it doesn't work with software retriggering as specified here  https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9KaSAK&l=en-US 

I've attached the VI.

Regards,

Alice_C

[Kevin_Price]

Let's give the hardware retriggering another try, shall we?

The default sample rate on your GUI was 0, so I don't know what you actually used.  I'm thinking perhaps you picked a value that wasn't compatible with the combo of 5000 finite samples, 10 msec acquisition time, and 1 sec re-trigger interval.

I made a few small mods to your vi, some functional, some more trivial.   From left to right, top to bottom:

- changed the default value of Rate on the GUI to be 500 kHz.  This will let you capture your 5000 samples in 10 msec.

- changed the trigger polarity from a plain magic # to the corresponding ring constant.  (By right clicking the 'edge' terminal and creating a constant.).   This is not a functional change, but the ring constant is more self-explanatory.

- I start the AI task first before starting to generate the triggering pulses, and before entering the loop

- I removed the explicit DAQmx Start and Stop from inside the loop.  If your devices support the Retriggerable property, you shouldn't need them.

- I wired up the # of samples to read in the call to DAQmx Read.  The default behavior for a finite task is to retrieve the same # you set up in DAQmx Timing, so this isn't a functional change.  I'm just an advocate for the habit of doing these things explicitly to show intent (and because it makes you pause, think, and actually *decide* whether you want the default behavior or not).

-Kevin P