LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Two different sampling rates

Solved!
Go to solution
Solution
Accepted by topic author Jani777

Dang it, sorry, forgot about that.

 

To fix your error, I added a call to DAQmx Control Task.vi to "commit" the task before querying for SampClk.Term.  (And added an optional similar commit to the counter task just in case, but I don't think that one will be needed.  But these are "better safe than sorry times we're in, so why not?).   Search for "DAQmx Task State Model" to learn more.

 

As to the counter, the attached vi filled in a guess.  I first had to right-click the front panel control 'counter', choose "I/O Name Filtering...", and then turn ON the checkbox for "Internal Channels".   Then I was able to select an internal counter on a cDAQ chassis.  I also made a simulated cDAQ chassis in MAX to give me something to select.  Now that I enabled the "internal channels" on that GUI control, you should be able to find some kind of counter channel like "cDAQ_chassis_alias/_ctr0" in the list.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 11 of 19
(998 Views)

Thank you very much, it's almost there where it should be ^_^ 

Now i'm getting the data, not having any error. 
But - the voltage measurement on 9227 is slower (ca about 120 ms) than it should be. 
As I used two modules with the same sampling rate, voltage and current started to change at the same time, when motors turned on), but now the difference is about 120-140 ms. (see delay.png) Could you please give me a hint how I could fixed that? 

Thank you, Jani

Download All
0 Kudos
Message 12 of 19
(984 Views)

Bad news, it appears I had some wrong assumptions after doing a brief search for cDAQ delta sigma modules.  The 9225 and 9227 were listed, but not the 9219.   So I figured (wrongly) that the 9219 would have flexible timing options like the SAR-based desktop MIO boards I'm most familiar with.

 

I took a closer look at your modules' specs when you mentioned the fairly large 120 msec delay, and I *then* found that the 9219 is known as a "slow sampling" module, a designation I have no prior experience with.  I tried making a simulated device to look for timing and signal routing options, and there weren't any, i.e., no apparent way to bring in a sample clock from outside.

 

So I'm afraid I'm out of my depth with your particular devices.  I don't deal with cDAQ all that much.  Many of the things I've learned from NI's desktop DAQ devices carry over into the cDAQ realm (sometimes with a few adjustments and limitations), but not everything.

 

The only other thing I can think to suggest now is to look into the DAQmx feature known as channel expansion.  I don't know whether it'll help for your particular situation, but it's probably worth a try.  Again, it isn't something I've got any real experience with though I'm aware that it's often worked well for others around here.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 13 of 19
(960 Views)

That's bad news indeed… 
Thanks for the article about channel expansion, but as I understood, I would need a NI 9469 to synchronize delta-sigma and slow sampled (or have deep knowledge to synchronize this modules on my own…). Luckily, I have plan B for my project, so I am hoping another one will work. 🙂 

Thank you very much for your help, Kevin. 
Jani

0 Kudos
Message 14 of 19
(937 Views)

Don't give up on channel expansion just yet.  By my reading the 9469 is only for when you need to sync up 2 distinct cDAQ chassis.  (I've asked before, I'll ask again.   Can't we just pretend that the plural of chassis is chassises?  😊)

 

At least give it a try by putting all the channels across both modules into a single common task.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 15 of 19
(935 Views)

I've tried it already, but i doesn't work - min. sampling rate of 9227 is 1613 S/s, max. sampling rate of 9219 is 50 100S/s...

0 Kudos
Message 16 of 19
(933 Views)

I am sorry for being impulsive. I read the article once again and i found my case. It's in 6 - multirate synchronization, Figure 10. 
I made it the way They have it. But for me it's a little bit confusing. 
If my DSM is the first channel, the case is always going to be true. But i don't know what to fill in the case TRUE that i am going to use... I tried several things, but i eather get error 89136 or it runs, but it isn't synchronized at all… 
Do you know if I am missing anything? 
Thank you very much! 
Jani

Download All
0 Kudos
Message 17 of 19
(917 Views)

Caveat: I don't have any experience trying to sync a Delta-Sigma with a "Slow Sampling" module, so no guarantees here.

 

The main thing I see different in your code is that you query your 9227 task for "SampleClock.Timebase.Source" when the linked document queries for "SampleClock.Terminal".  Try changing that.

 

For another option, section 5 of the linked document talks about a method involving channel expansion.  I know you've tried it in *some* manner, but are you sure you tried it in the *right* manner?  The key is that you should only define 1 single AI task that includes channels from both modules.  The snippets in section 5 show two different ways to do it.

   I would recommend you choose a valid rate for the 9227 that's an integer multiple of a valid rate for the 9219, probably 2500 and 50 respectively again.

 

As I read that linked doc, it sure *sounds* like these techniques are expected to work across devices where the max sample rate of one is less than the min for the other.

 

However, getting all the way back to the big picture, due to its slow sampling the 9219 really isn't the right device to pair up with a 9227.  It really would be better to purchase another device that can sample at the same rate as the 9227, probably a second 9227.  

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 18 of 19
(888 Views)

 

 


@Kevin_Price wrote

 

The main thing I see different in your code is that you query your 9227 task for "SampleClock.Timebase.Source" when the linked document queries for "SampleClock.Terminal".  Try changing that.

 


That was it! It's working now. 😊😊Thank you!!! 

 

For another option, section 5 of the linked document talks about a method involving channel expansion.  I know you've tried it in *some* manner, but are you sure you tried it in the *right* manner?  The key is that you should only define 1 single AI task that includes channels from both modules.  The snippets in section 5 show two different ways to do it.

 


I tried this even before i posted this question. But as I understood, it's only possible if minimum of the first is not bigger than maximum of the second channel. 

Kevin, thank you very much for you help and patience. I am happy it's working now. 
Jani

0 Kudos
Message 19 of 19
(878 Views)