Student struggling with LabVIEW and cRIO

[atokad]

Background:
      I'm an undergraduate mechanical engineering student, minoring in computer science. I've been working in this lab for almost a year now. In that time I have been learning LabVIEW, but more specifically learning how to operate a myRIO and a cRIO. My job has been to recreate the VIs that they have been running on NI-DAQ systems on the cRIO. I have learned a lot, but I am also struggling a lot because I am the only one in the lab learning about the RIO devices. Therefore no one in the lab is really able to help me, so I have to turn to the forums because I am at a point where I am not sure what to do.

About the project:
      I am trying to take the three main VIs they are using (the camera, the mass flow controller, and the microphone) and combine them to run simultaneously. I attached the original VIs that I have been given in case that is any help. I am using shared variables (I know it isn't the best method, but it is the one I understand the most) to communicate data between devices. Right now the VIs aren't very neat, I'm self taught in LabVIEW, so I apologize if it is hard to read/understand any tips on better organization/style would also be greatly appreciated.

Equipment:
      cRIO-9035
      NI 9264 (Analog out)
      NI 9213 (Thermocouple, currently not using in the project)
      NI 9205 (Analog in)
      NI 9344 (On/Off switches)
      NI 9401 (currently not using in the project)

Issues:

(1) FFT:

      I'm not sure if my fast Fourier transform is done properly on the cRIO. I haven't been able to test, but I am pretty doubtfula about it. I am trying to have it operate exactly like the FFT-DAQ image attached, but I had to get creative with it for the cRIO since I couldn't use the DAQ assistant module in LabVIEW. I'm sure there has to be an easier way to do what I did, but I am not able to figure it out/find one.
      Basically I need to read the voltage from the analog input (aquisition mode: N samples, Samples to read: 60k, rate(Hz) 12k, and a range +-10 Volts) of the microphone and then use that to calculate the voltage, pressure, and the sound pressure level (using subVI that was created for the DAQ systems project, but works for this one as well) along with the FFT calculations.

(2) Creating Files:

      The professor I work for wants me to add a way for us to send a file of the data acquired from the last X seconds, where X is an inputted value up to the users discretion, from the cRIO to the PC. I am completely stumped for this. I'm working on it now, that's why the host.vi is broken. I think I understand how I would do something like this, but I'm not sure how I would go about doing it in LabVIEW (if that makes sense).
      I think all I need to do is create an array of the values and have each value correlate with a time. Then when the user is ready to take the data, just read the values stored from the time requested. There might be an easier way, but that is all I can think of right now.

(3) Syncroniztion:

      A big part of the project that I haven't looked much into, but need to start working on is syncronization. All the data readings on the devices have to be done at exactly the same time for this to be succesful. Would I need to do that on the real-time VI or the FPGA VI? What would be the easiest/best way to go about doing this?

I'm stuck on these three things and can use as much help as possible, because at this point it just seems like I am beating my head against a wall on a day-to-day basis trying to work through all of this.

Note* The main project is the "MFC Calibration FPGA"

[Bob_Schor]

In Programming, as in many other things, "Divide and Conquer".  So here are some comments about various aspects:

• Stop using the Dreaded DAQ Assistant!  Do a Web search for "Learn 10 Functions in NI-DAQmx", read the paper, and learn how to do what you need with about 4-5 DAQmx functions.  Much simpler (trust me).
• Be sure to develop in the context of LabVIEW Project.  In particular, you can create DAQmx Tasks in Project, which will handle a lot of the details for setting up your DAQ devices (like naming them, defining the Channels, the Ranges, the sampling rates, number of samples, sampling mode, triggering, etc.).
• Your picture of the FFT "demo" can be recreated on your desktop.  Do you know about the Waveform Generator on the Waveform Palette?  You can generate a "noisy sinusoid" of know frequency, leave off the cosine window (do you know why you'd use a window when doing an FFT?), and play with the FFT functions until you get a Gain and Phase plot looking like your example.  Feel free to read about (from the LabVIEW Help, if no place else) what an FFT is, what the various plots mean, etc.
• Don't worry (yet) about doing three instruments simultaneously.  Let's just do one and get a clear understanding of that (see first line of this Post).
• You say "Right now the VIs aren't very neat".  Make them neat.  I prefer to "code neat", but there's also the clean-up tool (looks like a broom) on the Block Diagram window's Tool Bar (last one).  Keep your wires straight, always use the Error Line.
• Let's worry about analog input, 60K at 12KHz (I presume continuously), so you get a bunch of points every 5 seconds.
• Let's put all of the DAQmx stuff out on the cRIO. which is nice and fast, but has no Controls and Indicators.  You tell it "Go", and it starts spitting out 60K points every 5 seconds.  Where do you want these points to go?
  • My suggestion is "Stream them to the Host PC".  From there, you can stream them to disk (satisfying the "Save the data"), display them (not all 60K, of course, but maybe 4% of the points, i.e. point 0, 25, 50, etc.).
  • Since you get points at 5 second intervals, you should have plenty of time to compute and display an FFT "on the fly", if you wish.
• How do you get points from the cRIO to the Host?  How do you get "commands" from the Host to the cRIO?  The answer, of course, is not Network Shared Variables.  My recommendation is to use Network Streams, which are designed for TCP/IP transmission (one-way) of data.
  • In a LabVIEW RT Project of mine, I had 4 Streams running.  Two were "Message" Streams, from Host to Remote, and Remote to Host, where "commands" were sent back and forth (the Host said "Start", the Remote said "I'm running", "Here's some Data", "I'm ready to stop", etc.).  One was analog streamed data, in my case, 50 msec of 1KHz sampled from 24 channels, while the other was "Event Data", things such as TTL Level changes and button pushes, that can occur at any time, so need a Time Stamp.  Note that streamed Analog data does not, in general, need a Time Stamp, as the DAQ clock is much more precise than the Windows Time Stamp clock -- at most, you need to know when sampling started.
• Synchronization requires either the Host or the Remote to be the "Clock Master".  I recommend using the Remote, as it has the accurate (DAQ) clock and is closest to the "time-critical" operations.  There are various ways to synchronize multiple DAQ Tasks, but that is a problem to be tackled once you know how to get each Task working in isolation.  In some cases, you may use hardware signals, in others, you might use software flags.
• My guess (and I admit having little direct experience with this) is you can do a lot directly with the cRIO itself without needing to dive into FPGA.  At least at the beginning, when you are working on one Task at a time, "KISS" (which means Keep It Simple ...) -- you can always make it more complicated and harder to understand/debug once you know it works!

Bob Schor

[natasftw]

I'll start by confessing DAQ isn't my strength.  Some of your requirements are listed in the way they're measured by DAQ so some of my implementation may need to be tweaked.

That said, let's take a look at what you're trying to do on the cRIO and eliminate some of the "noise."

Let's start by removing the modules you're not using.  That gets us down to:
cRIO-9035

NI 9264 (AO)

NI 9205 (AI)

NI 9344 (Switches)

Analog input needs to be read: 60k samples, 12kHz sample rate, +/- 10V.  Here's the first place you'll want to get yourself out of the DAQ mentality.  You're working with the RIO here.  You're sampling at faster than 1kHz, so I'd move to the FPGA rather than the RT.  (Scan engine goes at 1kHz.)  Place a FPGA I/O node onto your Block Diagram and set it to read at 12kHz.  Read a sample each time and send it to a FIFO.  Read from that FIFO in your RT VI.  This handles your sample rate requirements with a trivial FPGA VI.

Once on RT, you can run the FFT to your heart's desire and see the results to verify if that looks right.  Send some known test vectors and you can easily verify this.

Synchronization is easy on the FPGA.  Pull down on the FPGA I/O node.  Now, each thing you're reading is read at the same time.

For sending the file, is this a task that should be continuous or only happen when you push a button?  Do you wish to keep track of ALL the history or do you only care about these N seconds worth of data?  For creation of a file, it'll really depend on what your goal is.  But, you're likely to only want a file to exist on the Host or on the RIO and never transfer that file between the two.  We can look at that soon enough.

[atokad]

Thanks for responding!

I only care about the past N seconds of data. I want the data to be stored on the computer.

[natasftw]

If you only care about the last N seconds and want the file creation to take place on your PC, you'll want to setup a couple of VIs.

On the cRIO, you'll want a VI that maintains the last N seconds at all times (and drops values as they become stale).  You'll also want a loop that regularly listens for connection attempts from the host.  If there's a connection, it works with it.  If there's not, it tries to listen.  This will require error handling so that you can clear the error and restart the listening if it's ever broken.  The idea here is this VI can run autonomously and won't quit if you lack the connection.

On the host, you'll create the connection.  At that point, you can ask the cRIO to send you all of its data in a FIFO.  You'll get all the data and be able to create a file then.

[atokad]

How would I setup the VI to maintain the last N seconds at all times? I'm trying to figure it out, but I'm not sure how that would be setup

[crossrulz]

---

@atokad wrote:

How would I setup the VI to maintain the last N seconds at all times? I'm trying to figure it out, but I'm not sure how that would be setup

---

Look up the Lossy Enqueue function.  Use that with a fixed sized queue to create your buffer.  You can then flush the queue when you want to send all of the data in it.

[atokad]

I understand why I should use a lossy enqueue, but I am confused on how I go from creating the queue to creating a queue based on time