Can NI 9174 execute tasks by itself?

[xiaoyux]

Hello guys.

I am using NI 9401 module plugged into NI 9174 chassis to read the signal from a trigger wheel with 58 teeth and 2 missing teeth. In order to detect missing teeth, I need to compare the pulse ticks/duration.

However, due to usb lateness, this can't be done in software level. Someone has done this before by using FPGA which my device doesn't support. (http://www.drivven.com/visitor_download/Manuals/EPT_VI_UM_RevB.pdf)

I am wondering if I can achieve the goal with these devices. Is NI 9401 programmable like a PLC?

Thanks.

[GerdW]

Hi xiaoyux,

no, the NI9401 is just a "dumb" IO module. And your cDAQ9174 is also "just" a DAQ chassis.

When you want to program on FPGA level you need to use the cRIO platform…

However, due to usb lateness, this can't be done in software level.

Why not?

You could read the digital signal and analyze it afterwards…

[Hooovahh]

I did some Cam/Crank simulation stuff on an FPGA years ago.  We picked the FPGA for a good reason.  It has deterministic, real time, fast, responses.

What isn't clear from your setup is what do you need it to do?  So you need to read the Cam/Crank and find the missing teeth and determine the speed right?  How much time can you have to determine the speed?  Is this going on a UI being shown to the user?  If so you likely need to be able to tell them the speed within 1 second.  Is this being logged?  Then maybe you can do some post processing on the readings to find the rate of change.  Are you trying to react quickly?  Like if you see the speed go above some number do you need to halt immediately?  Or send out a CAN message reporting what the current speed is?

Because the hardware you have can do plenty of work for you in a post processing sort of way when attached to a computer.  If you setup a DAQ task to take continuous sampling, then you can do something like read 0.5s of data, go through some data processing and determine the speed, then show it to the UI, then take another 0.5s of data.  It isn't deterministic, and you will have jitter but measuring speed, and measuring every data point is possible.  It looks like the hardware can sample on the order of MHz, so speed isn't the issue, it is processing time.  And on a non RT system expect it to be inconsistent.

[xiaoyux]

Hello Hooovahh,

I not only need to read the speed but also to know when the missing tooth come and then counter tooth in order to further trigger something else. It is a little similar to ignition system in SI engines. But I don't have cam sensor so I don't have another reference signal every revolution. From oscilloscope, the frequency of signal is about 1.7 kHz. The motor rotary speed is about 2000rpm.

This is just a research project and will be used by students.

Thank you.

[xiaoyux]

Hello GerdW,

Sorry I didn't make it clear enough at the very beginning. 

I need to know where the missing tooth is and label other teeth in order based on this missing tooth position. Then I could trigger something else, in my case pump valve, when a certain tooth comes.

And yes, I can read the frequency of signal by setting up built-in counter as well as pulse width. Thus, I can compare the pulse width and find out missing tooth in labview theoretically.

But I have two concerns, the first one is that the comparison is done by shift registers in while loop. From tests, I find the while loop frequency is much lower than signal frequency which is 1.7kHZ. I am afraid that some samples were lost.

Another is usb lateness. In this forum, some says usually there is 1~10 ms lateness over usb. This is nonnegligible compared to my signal frequency/period.  As a result, I can't track the exact position of the trigger wheel or trigger something else at a certain tooth.

Thank you.

Thank you. 

[GerdW]

Hi xiaoyux,

as you now explained your requirement somewhat better I can only suggest to use a cRIO target and its FPGA capabilities to reach your goal!

[JÞB]

---

@GerdW wrote:

Hi xiaoyux,

as you now explained your requirement somewhat better I can only suggest to use a cRIO target and its FPGA capabilities to reach your goal!

---

Absolutely!  you can do a lot of things with software but, you still need hardware!  Some form of hardware to detect the missing teeth and output a trigger.  A properly configured FPGA is one such example but any sort of resettable monostable FF would do.

[Hooovahh · Accepted solution]

---

@xiaoyux wrote:

Then I could trigger something else, in my case pump valve, when a certain tooth comes.  

---

This is that tight timing requirement I mentioned earlier.  You have no hope other than to use a dedicated piece of hardware that takes the readings and reacts on its own.  You mentioned students so I'd recommend the myRIO.  For $500 you get an embedded ARM processor running RT Linux, and an embedded FPGA, USB host for USB logging or other devices, various AIO, DIO, I2C, SPI, UART, Wifi, and the software to program the thing.  This means you can write up to three applications, one for the Windows PC, one for the ARM processor, and one for the FPGA all programmed with the same LabVIEW IDE and common tools (for the most part).  If you're unfamiliar with LabVIEW at all then it might be a steep learning curve.  NI provides tons of examples, ExpressVIs for common tasks, an Essentials Guide which shows various sensor connectivity, and several Youtube videos, but learning all of this on top of the whole graphical paradigm is probably alot to take in, but is probably the right choice in the NI ecosystem.