Trying to collect output data from an accelerometer...

[B_baggins]

I am reading the voltage output from an accelerometer (only the z-axis).  I've placed some conditions in the VI so that data is only recorded when the output level is beyond a certain (low) threshold. 

While messing with the setup at my desk, something seems to be amiss.  Touching the case of the accelerometer with what should be enough force to trigger the output (the graph in the U.I. spikes, and the level is higher than the trigger to start saving data) doesn't always cause LabView to create an output Excel file. 

I am wondering if I need to implement some sort of buffer within the VI...seems like triggering events are being missed with the way I have things wired at the moment. 

The the VI (Labview 2016 file) and datasheet for the accelerometer are attached.  Model number is CXL04GP3.

Thanks in advance for suggestions/thoughts.

[LandJBelenky]

I'm not quite sure what's wrong, but I can tell you're not going to need a buffer.  If you're seeing the data on the chart, the data exists for all intents and purposes and so you don't have to do anything special to capture or save it.

If you check out the help file for Write to Measurement File Express.VI, there area couple of things that concern me.  One is the "Flush" input. NI says you should set this to FALSE if you are writing iteratively, and then change it to true for the last iteration.

The other is that there is also a "saving data" output. This makes me think that maybe this VI takes a while to complete and is locked up during that time, so that it needs to inform the program when it is ready to continue.

I think I would avoid this altogether and just use one of the traditional VIs to save data, rather than an Express VI. It would be easier if you can wait until after the While Loop is complete and then just save it all at once. 

Let me know if this works for you:

If you need to save data during the run, we can do that too.

[Bob_Schor]

I suspect you haven't thought through the problem, or else you really don't understand what LabVIEW is doing.  One problem is that you are using the Dreaded DAQ Assistant and its Evil Twin, the Dynamic Data Wire, both of which largely obscure what is happening, and are subtle traps for beginners.  [Really, all Express VIs should be forbidden until one learns enough to pass the CLAD Exam].

You are collecting 200 points/second, and are using one of these points (which one?  I'm unsure ...) to decide if you are going to start recording.  Given you have a very narrow window for starting, I'd say you have a few % chance of having your single chosen point every second hit your "Go" condition.

Here's a suggestion:  write a description of what you want to do.  Talk about the sampling rate, the number of samples, what you want to do with the data (do you want to make a decision about only 0.5% of the data you are collecting, i.e. 1 point in 200, or analyze all the points?).  Talk about what you want to save, and don't worry about how you want to save it (you'll have a much easier time saving to a text file, as this is something you should be able to understand).

We have some students who've never encountered either LabVIEW or a triaxial accelerometer.  They have a project where they are using the Accelerometer to record the vibrations of a probe used in orthopedic surgery.  They've been forbidden to use the DAQ Assistant, but were encouraged to "play" with their Accelerometer in MAX, to get MAX to collect some data for them, use MAX to design a Task that collected data for them, then use this task along with 3 DAQ functions (Start Task, Read DAQ, and Stop Task) to collect all their data.  They are streaming the data to Excel (real Excel, not a "Delimited Spreadsheet"), and are having a lot of fun in the process.  It helps that they work together, learning from each other, and have a local LabVIEW Guru for when they "get stuck" ...

Look to your fellow students, and instructors.

Bob Schor

[B_baggins]

Hello, and thank you for the reply.  I will try the design that you have posted.  I am a Labview neophyte, so I need to figure out how the designers of the software intended it to work.  🙂   I will look for some tutorials and work through those to get a better handle on things. 

[B_baggins]

Hi Bob,

Thank you as well for your reply.  I am trying to do the following:

- Monitor the accelerometer for a 24 hour period, and only record voltage levels showing positive or negative acceleration along the z-axis that exceeds small thresholds.  Basically I'm trying to minimize the subsequent data file, and eliminate all of the voltage outputs when nothing is happening.

-The bandwidth of the accelerometer is DC to 100 Hz, so I selected a sampling rate of 200.  I selected 100 for the number of samples with the understanding that each time a voltage level above the threshold was detected, LabView would write 100 subsequent sample values to an Excel file.  The number of samples recorded should probably be increased, to fully capture an impulse and its decay over a second or two...

-My intention is to monitor the voltage of all 200 samples each second, and once a limit is exceeded, start recording.  I think in your post you were pointing out that I have implemented my intent incorrectly within LabView, in that the "window" set up in the program isn't going to consistently detect values above the upper and lower voltage limits.  That is what I am seeing when I tap on the accelerometer; the change in output always shows up on the graph within the UI, but I don't always see the new Excel file appear on my desktop (reflecting that something is wrong with the attempt to capture the output).  I sometimes have to touch the sensor several times for the program to notice the output change, and then create a new Excel file that contains the first set of recorded values. 

I will begin to study LabView MAX in greater detail. 

[Bob_Schor]

Before I forget, here's a Reading Assignment that will show you (a) how simple and logical DAQmx can be, (b) how to leverage your MAX experience to your LabVIEW Code, and (c) how to avoid the Dreaded DAQ Assistant.  Do a Web Search for "Learn 10 Functions in NI-DAQmx" (the title is longer, but that should get it for you), download and read it, then apply it to your problem.

I'll get you started.  I assume you have a USB-6009 or something similar to take Analog readings from your Accelerometer (which you have hooked up in Differential recording mode -- very important!).

• Open MAX.  Find your device connected to the Accelerometer.  Open a Test Panel for Analog Input.
• You want to input Volts from whatever channel(s) you are using.  We recorded all three channels, but there's nothing wrong with recording just the Z channel.
• Set up the Sampling for Continuous, 200 Hz, 200 samples (so every second you get more points).  Push Start -- you should see a trace (of 200 points) refreshing every second.  Push Stop.
• Now click Create Task (right next to Test Panels).  You're going to do just the same as you did with the Test Panel, but you'll create a MAX Task that DAQmx can use to do just what you ask (i.e. take 1 channel of Analog Input from your device using continuous sampling, 200 points at 200 Hz).  When you have configured the Task (please choose a better name than "MyVoltageTask"), test it by pushing Run.  Be sure you choose Continuous Samples.
• Now Save the Task.  You can now close MAX.

Open LabVIEW and create a new, blank, VI.  Put the following three DAQmx functions on the Block Diagram:  Start Task, Read, and Stop Task.  Wire them together (Task and Error lines), put a While loop around the Read, put a Chart on the Front Panel and wire the output from the Read to the input to the Chart (the Chart has to be inside the While loop -- do you know why?).

Oops, the VI is broken because Start Task has an unwired, required input.  Right-click the Task input node, choose Create Constant, and admire your blank I/O Constant.  Right-click the little selector Triangle -- what do you see?  Select it.  No more broken arrows.  Run it and watch your data scroll (once a second) across the chart.

Notice how this code "auto-times" itself -- once a second, it appears to "wake up and do something", namely give you 200 points to plot.  In a second, you can do a lot of computation.  What might you do?  How about finding the first point that meets your "threshold" criterion?  Maybe there are none -- no matter, there may be one in the next second's sample.  The point is, you now have all the data, and time to do something with it all.

Play around with this code, your DAQ device, and your Accelerometer.  Maybe experiment with stopping the loop when you get a trace that crosses threshold (note -- this will probably not work the first time you try it, but if you think about Data Flow and how LabVIEW does "everything it can at the same time in parallel", you can not only make this work, but will learn something in the process).

Bob Schor

P.S. -- I deliberately did not attach any code because I want you to try to do this by yourself.  The steps are easy, and you'll learn a lot better by "doing" rather than by "copying".  Do read the NI White Paper that I mentioned first ...

[B_baggins]

Hi Bob,

I wanted to say thank you for your detailed response.  I will do as you suggested. 

I also think I (finally) realized why my program with DAQ Assistant wasn't working as I expected.  I needed to reduce the number of samples.  Too many desired samples caused the the time for each loop to lengthen, and I missed output from the accelerometer.  I've set the number of samples to 1, and it's working.

[Henrik_Volkers]

Well the output bandwidth is 500Hz ... no need to sample faster than 1k . Have a look at the producer consumer architecture to seperate reading the sensor and processing the data.

Just another hint: Your accelerometer goes down to DC, means orientation matters 🙂

So if you want to apply a very small (sensitive) trigger and your sensor will tilt slowly a static threshold migth not what you are looking for.

One common solution of such a problem is to apply a highpass filter to the raw data .

[Bob_Schor]

You should never miss data from your accelerometer (unless you are doing a prodigious amount of calculation for each data point).  I routinely sample at 1KHz from a triaxial accelerometer, scaling it as I sample (so that each channel's output is in units of "1g", correcting for Accelerometer offset and gain) and calculating a "total acceleration" (the length of the 3D Acceleration vector).  If I sample 100 points at a time, I estimate (actually, this is a "guesstimate", as I never measured this) that of the 100 msec period between samples, I probably have 99 left over to do other things -- I certainly have at least 90 ...

Bob Schor