Need cRIO or cDAQ?

[jawilli91]

I'm not having luck determining if cDAQ can do all that we need, and cRIO real-time might be overkill.

I need to capture a waveform where the y-axis is a 0-5vdc analog input, and the x-axis is a quadrature encoder reporting degrees of rotation.  Similar to voltage/time, this voltage/degree graph is a square wave.  I've attached a screengrab of a similar test, and what I'm trying to replicate.  Note, I have zero access to documentation or programs from this reference system, only that it was done with NI.

The on/off state of the 0-5vdc signal is fast, approximately 4milliseconds on, 4 milliseconds off.  To me and my experience level, this is blazingly fast.  In the attached image there are little boxes attempting to grab the peak of leading edges, and the trough of falling edges.  The goal is to compute distance in degrees of rotation from peak to peak, and trough to trough.  Ultimately, determining if a tooth on a gear is bent/misshapen.

I talked a bit about the application in this post: Hiperface Encoder Signal - NI Community  I'm not trying to be redundant with this question here, I believe it is substantively different.

Test target spins at 150rpm, and the waveform of 58 teeth against 360 degrees of rotation need to be logged within one rotation.  Part begins to spin, finds the gap tooth, and then the data acquisition needs to be completed in the next 360 degrees.

Once the data above is collected, speed isn't as important anymore.  Pick and place controls can come over and grab the part while math/analysis is being done on the waveform.  Hopefully within about a second after acquisition LabView can send a PLC a good/bad status and the pick and place will adjust accordingly.

This post analysis is where I'm getting really lost on speed capabilities of cRIO and cDAQ.  cRIO being real time is faster, can be headless, doesn't need Windows, all good things.  But I don't really know, and can't seem to figure out, if I need it compared to cDAQ.  Not that I actually KNOW anything about either...  Maybe cDAQ is able to collect all the data/samples for 4 millisecond signals while spinning at 150rpm.  But then can it also do the analysis of counting the teeth fast enough?  Telling the PLC good/bad fast enough?

I should also state that my plan was to use NI-9401 for the quadrature encoder signal, and NI-9201 for the 0-5vdc.  I will have three of these tests going on asynchronously.  Which makes me wonder another question, should I have 3 NI racks, one for each tester, or can Labview run multiple VI's with my sampling time requirements asynchronously?

My apologies if this should be in hardware section of the forum.

Thanks.

[crossrulz]

My personal opinion is that I would use a cRIO.  I would even go so far as to do the digital decoding and voltage reading in the FPGA.  The FPGA should easily be able to handle the multiple stations.  The FPGA then passes the data up to the RT who can then create the graph and/or pass the data on to the PC.  In previous programs I have done, tell the PLC a "good" signal was a simple digital signal that I controlled with the FPGA. If other methods are used, then the RT can handle that.

[jawilli91]

Thanks crossrulz.

What little of LV I know is with cDAQ, I have no idea how to control the FPGA. But if I can do the waveform collection with the FPGA, that sounds like an even faster way to get the data in, and probably save cost on c- series DAQ cards?  Actually, I must fundamentally misunderstand what you meant.  There have to be cards on the rack, for the encoder(s) to be wired into.  I've read elsewhere that there are different levels of programming with cRIO, LV RT, FPGA, and Windows?  I think you meant I should run my program at the FPGA programming level, which makes sense to me.

I don't currently understand the difference between cRIO chassis-only, and cRIO controller, fumbling through datasheets now.  This machine will have a PLC from another company that is the parent of the whole machine.  cRIO only needs to handle the test part.  Signal/Waveform collection, signal interpretation, and pass/fail to the PLC (indeed like you said, digital signals would be ok).  However, scope creep might come in and I'd need the LV program/cRIO to speak Ethernet/IP to my PLC.  Not that it's necessarily relevant to this topic, but I'll also need to store some of the waveforms (minimum x/y data points) to a database, probably on the same computer connected to the cRIO (for programming support/troubleshooting).

"The FPGA should easily be able to handle the multiple stations."

1 Station is 1 0-5vdc sensor, and 1 quadrature encoder.  

3 Stations in total, with asynchronous cycle starts, waveform collection, and deterministic judgement.  

it's not clear to me at what point even the FPGA would be bogged down and I could lose samples/data.  I imagine I want to avoid cRIO chassis with DAQmx.  Assumption that DAQmx is slower/more limited in sample memory.  

This document, Specifications Explained: CompactDAQ and CompactRIO Chassis and Controllers - NI mentions how DAQmx with cDAQ sends packets of data because of slot memory limitations. That it sends the samples on in messages to avoid buffer overrun.  It doesn't give a comparable example for cRIO, nor can I find anything to indicate with my desired setup, where I could run into not having enough memory to store all the samples from a test cycle?

[ZYOng]

Due to the limited resources on the hardware, the data are never held in the onboard buffer. Regardless of DAQmx or FPGA, the data are sent to the PC buffer via DMA FIFO. See Understanding and Avoiding NI-DAQmx Overwrite and Overflow Errors

Usually, when choosing between cDAQ and cRIO, my question would be: do you need a fast response between read and write?

• If you are just logging 2 seconds of data, then can wait for a few hundred milliseconds to process the data before writing to PLC, cDAQ is adequate.
• If you need to read + process + write within milliseconds, you need cRIO as data are transferred to the cRIO CPU faster when compared to USB or Ethernet with cDAQ.

When using FPGA, you still need C Series for the IO. If you write the logic in FPGA, you can read + process + write within microseconds time. However, since you are writing to PLC using Ethernet/IP which has to go through the CPU anyway, using FPGA in your case does not help.

[jawilli91]

OK, understood.  Thank you for that link.

cDAQ can do it, cRIO can definitely do it, and I may be wasting some hardware cost if I go with the latter.  Once the money is spent I can't fail, so I'm still leaning towards RIO based on all said here thus far.  Until cost comes up.  And also don't know if cDAQ can handle 3 testers gathering data at the same time, asynchronously.

I'm using the system configurator tool with a couple of assumptions.

-3 systems if cDAQ, may cRIO too.

-Labview Full I think would be enough, not Professional.

-If cDAQ, I think I want to pay for the Real Time Module?

-If cRIO, there are both Real Time AND FPGA module licenses.  These aren't included with paying more for the RIO chassis and controller?  Odd, do I need to pay for them to access the FPGA?

You're correct.  Well, depending on what we mean by "write."  We might have different thoughts on what that means.  I don't think I need to write to anything until, as you said, a while after the data was collected and a judgement was made by the DAQ/RIO.  Well, we do need to "write" the waveform/data to a database after good/reject decision was made (the waveform I mention needing to be similar to the one I attached in the original post).  And about this same time write to the PLC the good/reject decision.

Faster as an option is definitely better.  We have to get this part into the tester, do all the business, and get it out, so that the end of the line has 1 part coming out every 3 seconds.  And that is why there needs to be a minimum of 3 testers.

Thanks again for the input folks, I think I'm slowly getting a better understanding from a 10,000 meter view.

[jawilli91]

Please disregard my last.

I clearly need:

LabView Professional

Real Time Module

FPGA Module (if cRIO)

FlexLogger

Application Builder (maybe)

OPC UA Toolkit

And I need to move to a cRIO 8 slot chassis if I want to run all three testers on one RIO system.  Because it looks like NI-9401 only takes one encoder per card.

It does look like a cRIO system running all three testers is going to com out less expensive than 3 separate cDAQ chassis.  Trusting the kind person above who said RIO can handle 3 tests running at the same time.

[crossrulz]

---

@jawilli91 wrote:

I clearly need:

LabView Professional

Real Time Module

FPGA Module (if cRIO)

FlexLogger

Application Builder (maybe)

OPC UA Toolkit

---

You will not need FlexLogger and Application Builder is included with LabVIEW Professional.

[jawilli91]

It's kind of NI to still allow me to select those options and seemingly pay for them anyway, after selecting LV Pro.

[mcduff]

---

@jawilli91 wrote:

It does look like a cRIO system running all three testers is going to com out less expensive than 3 separate cDAQ chassis.  Trusting the kind person above who said RIO can handle 3 tests running at the same time.

---

I am not familiar with your tests, so take caution with my advice.

An 8 slot cDAQ slot chassis has can handle multiple tasks, see here. I don't have any experience with counters, but your plot in the first post seems well suited for a counter task. I suggest you look into this possibility.

The other cost you should examine is your time. If you have limited experience with LabVIEW, jumping into FPGA, and creating 3 asynchronous tasks is not a beginner's task. DAQmx has a much faster learning curve; my guess is that if you search the forums here for @Kevin_Price's posts, you will find a lot of good information about counters and what they can do.

[jawilli91]

mcduff,

I appreciate your preface, and that you brought up the labor cost of the system.  Nobody in my company, myself included, can do the programming for this.  MAYBE we could muddle our way through with cDAQ (in enough hours...).

Plan A was a third party data acquisition company with proprietary monitoring hard/software would do the test.  But they are falling apart fast on us.  And it's looking more and more like it will HAVE to be NI.

I will look into the links you sent, I cannot at the moment.  I appreciate your, and any/all guidance.

We are waiting for one more piece of the puzzle, and then we will probably invest in a system and begin seeing how bad it will be, or more likely, begin looking for NI contractors/integrators in the northern Detroit, MI area.