Can cDAQ 9361 and NI 9361 perform order analysis?

[Matt_AM]

Hey Fancy Folk,

Background:

I am using a cDAQ 9174 with modules NI 9220 and NI 9361.  The NI 9361 will be hooked up to an encoder and I wanted to use the A channel from the counter as a clock for the NI 9220.  I am trying to perform some order analysis with the cDAQ hardware.  I’m familiar with PCI with a RTSI cable and PXI so I assumed that there was going to be a back plane to pass the counter signal to the analog module.  I wrote a quick program to test my idea and it returns error -89136 stating that there is no routing available (see image below). 

After some googling, it makes sense that I’m seeing that error.  From my understanding (and a very high level overview) the cDAQ chassis is the one controlling the sampling once all the tasks are started. 

What I’ve tried:

I figured that if the chassis was doing the sampling, I could route the CTR A signal to the chassis’ ai sample clock.  When I tried this, I was getting the same -89136 error.  At this point, I am viewing each NI card as a signal conditioning module that converts whatever signal I want to read into one that the cDAQ device can read.

I was looking into syncing multiple chassis together, my logic being that I could try and physically route CTR A to the external clock on the chassis the same way syncing chassis together would work.  However, it looks like only the 8 and 14 slot chassis have external clocks and the cDAQ 9174 is a 4 slot, thus no external clock.  

Question:

Is there any way I can use the cDAQ 9174 and NI 9361 together to perform order analysis?

Thanks,

Matt

[Matt_AM]

Hey Fancy Folk,

Forgot to add this in the previous post, I am currently simulating the cDAQ hardware and I don’t physically have it yet.  I add this because I will be referencing faux chassis and cards in this post and faux just means that its simulated.

I was looking through the cDAQ 9174’s device routes in NI MAX and it appears that there is a direct route between the chassis’ CTR0A and the ai sample clock, see image below.  My logic is that the chassis’ CTR0A will become the NI 9361’s CTRA via the task created to read the counter.  Therefore, if I link the chassis’ CTR0A to the ai sample clock, then I should be able to sample the NI 9220’s analog signal based on the encoder which would allow me to do order analysis. EDIT: The main difference between the original post and this is that I am not using the NI 9361 as my source terminal, but the chassis' CTR0A channel as the input terminal for the DAQmx Connect Vi.

I wrote a quick VI to pull the CTR0A terminal and route it to ai sample clock but it is still erroring out with a -89136 saying routing isn’t available, see image below. 

Can someone shed light as to why I can’t route the chassis’ CTR0A to the chassis’ ai sample clock?

Thanks,

Matt

[santo_13]

Simulated DAQ is limited in features, especially the triggers and any signals outside of a DAQ card domain.

If your issue is about a simulated device, there is no point in discussing why it does not work as it is "simulated" and not "emulated", it is not perfect, it is what it is.

[Matt_AM]

Santhosh,

I understand that simulation does not mean a direct representation of the physical hardware.  In my experience, PXI simulated devices and PCI with RTSI simulated devices allow you to route signals that are directly connected in NI MAX.  I am assuming that the cDAQ architecture is the same if the routing is available.

Let's assume that I have the physical hardware here, can I route the the chassis' CTR0A to the chassis' ai sample clock?

Matt

[santo_13]

Looks like you misinterpreted the routing table, the one you pointed out is sampleclock->ctr0A and not the other way around.

CTR0A cannot be a source for anything, it can only be a destination.

[Kevin_Price]

I haven't used the 9361 myself, but seem to recall that isn't a "pure win" module.  It gives you lots more counters, but I think it's somewhat limited in its ability to share timing signals with other modules in the chassis.   Sorry, no details, just a sorta vague memory.   For example, I think I recall that you can't pass signals through to the chassis counters, you have to use the ones in the module.

Consequently, you may end up finding that a very simple DIO module will be easier to work with b/c it may provide a lot more "routeability".  Unless you need more counters than the 4 in the chassis, the 9361 may not be the best choice after all.

Caveat: this is all hearsay.  Trying to help, but definitely listen to second opinions.

-Kevin P

[Matt_AM]

According to the PXI 6251’s datasheet I have on hand, the source for the counters appear to be A.  I am assuming that all counter sources will become counter A's regardless of the card.  I say this because there is a direct link between counter 0 source and the ai sampling clock.

According to my Vi to pull out the correct terminal, this doesn’t present an error when i use the DAQmx Connect Terminal Vi.

I assumed that LabVIEW would have interpreted the A line and source to be the same terminal, but I was wrong in that assumption.  I'll pass the info along and report back if this solves the problem.

Thanks all for your input, it is much appreciated! 

Matt

[Matt_AM · Accepted solution]

Bad news fancy folk,

ends up that the NI 9361 can't access the chassis' on board counters, since it's the only module with build in counters itself. https://www.ni.com/en-us/support/documentation/supplemental/18/cdaq-module-support-for-accessing-on-... the note at the bottom of the page explicitly says the above statement.  

That being said, I think that if we used a different counter card, that this theory could work.

Matt