Help with Datalogging

Hi there!

I was wondering if anyone has had experience with datalogging sensors.

Our team wants to be able to watch graphs of motor speed, voltage, and amperage as well as accelerometer data and encoder data.

I tried to give it a go (code attached), but nothing was working. I tried moving the motors using that “set” button, but they wouldn’t move. I have never programed with graphs before. Should I put everything in one loop? Should I keep the separated? Any help would be appreciated!

Thanks!

The posted code is missing the Driver Station Start COM.
While running on the cRIO the project will need to have a Driver Station app to Enable the cRIO before the Jags will be allowed to react.

You can find an example of this call under the Support Examples for I2C/ADXL345

Ahhh…it always seems to be the simple answer. I’ll try that next time I get out to our shop.

I’ll try to take a look at your code when I get home.

We use TDMS to log to the RIO and review afterwards. The logging loop runs in Periodic Tasks and stores data to a buffer. Once per second the buffer is flushed to storage.

You can see how we did this in 2013 here: http://www.chiefdelphi.com/media/papers/2876?

Where did you guys learn how to use TDMS? I’m trying to follow the code, but it’s a little challenging. Did you guys find a website or Youtube video explaining it?

Thanks for the reply!

Hi Joe - We picked up on TDMS when researching practical ways to store data using the National Instruments online documentation on LabVIEW. Practical for robotics means collecting data quickly without affecting the operation of the rest of your code.

Check out http://www.ni.com/white-paper/3727/en/ for a general discussion on TDMS ( Technical Data Management Streaming ). I ended up trying many different approaches before discovering that the TDMS capability was designed for high speed and high density storage. The other features like compatibility with Excel (for post match analysis) are a nice bonus.

When accomplishing this kind of data logging, it’s important to understand software design requirements for what’s called a ‘real-time’ system - which essentially means to ensure that your code operations reliably occur on schedule. There are some nasty things like ‘priority inversions’ that will impact how your code runs and creates unplanned results. To review these concepts see http://www.ni.com/white-paper/3938/en/ and http://www.ni.com/white-paper/3898/en/. There are other papers on the web that you can locate with Google (also try LabVIEW determinism).

Also study the Consumer / Producer design pattern, see http://www.ni.com/white-paper/3023/en/. This enables one to communicate effectively between loops, i.e. producing data in one loop and then sending the data to another loop that is responsible for moving it into storage (consuming). Separating these functions allow them to operate without one slowing down the other.

Once the concepts were understood, learning TDMS was kind of like how the Wright Brothers learned aeronautics … experiments! (lots of them). You can do this yourself without a robot by just setting up a blank LV Project and trying out the VI’s on the TDMS pallet. You can also study how we designed our logging algorithm in the published code - it is a stable / proven approach.

As ‘adciv’ said above, the logging loop should run within Periodic Tasks and be buffered via a Real Time FIFO, where a separate loop or process manages storing the data. Using a ‘burst transmission’ approach makes it time-efficient … like waiting until a commercial plane is full of people before flying to the destination.

All this may sound complicated but with a bit of research it will come together. Experimenting really helps the learning process.

I can walk you through the code when you’re ready with specific questions.

Richard / The RoboBees FRC Team 836

Thanks so much Richard! I will definitely look into TDMS! While I was waiting for more replies, I did some more research and found the “Datalog Blocks”. They are in File I/O>Advanced File Functions>Datalog. Basically, it receives an array of data that it can output through a *.dat file. It seems to be easier to setup, but I haven’t confirmed that yet.

We’re having a drive train meeting today, and I need to figure something out for this datalogging pretty soon, so I will keep this thread updated.

Thanks again!