Example Code

Asynchronous Multi File TDMS Data Logger

Products and Environment

This section reflects the products and operating system used to create the example.

To download NI software, including the products shown below, visit ni.com/downloads.

    Software

  • LabVIEW

Code and Documents

Attachment

Overview
This is a library of functions of the asynchronous TDMS logger.


Description
This is a library of functions of the asynchronous TDMS logger. It allows you to dynamically run an asynchronous thread for data logging with additional functionality of seperating the data into multiple files based on size or date and time. It also implements functions to delete old files that would normally overflow your hard drive.

 

Requirements

Software:

  1. LabVIEW 2012 (or compatible)
  2. VI Package Manager 2014


Steps to Implement or Execute Code

  1. Check that your VI Package Manager is in the version 14 or higher.
  2. Install the package.
  3. Run the tester VIs from the palette

 

Additional Information or References

VI Snippet
DAQmx Example.png

 Tester.png

Throughput Tester.png

 

**This document has been updated to meet the current required format for the NI Code Exchange.**

Piotr Kruczkowski
Certified TestStand Architect
Certified LabVIEW Architect

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
Stkn
Member
Member
on

Hi Piotr, nice work.

I have one suggestion to add to the library VI to create the properties for a file, group or channel of TDMS.

PrimaryKey
NI Employee (retired)
on

Thats a really good idea. I will probably do it next time I rework the toolkit a little bit, because its a little bigger modification.

Thanks!

Piotr Kruczkowski
Certified TestStand Architect
Certified LabVIEW Architect
WillToth
Member
Member
on

Have you considered the use case for parallel datalogging of different data streams to the same tdms file?


As you have it now it is highly likely to have a race condition occur in the case where two loops are running in parallel call the same log type. Why not use the variant type in the log command queue directly, instead of setting up a new queue for each supported data type? The only race condition left would be if you try to write to the same group and channel in the tdms.

PrimaryKey
NI Employee (retired)
on

Hejka, the secutrity of data transfer is just by the way the queues are used. I always use them in pairs, so I always dequeue and enqueue the samples in the same VIs.

If you find any bug thout please let me know

Piotr Kruczkowski
Certified TestStand Architect
Certified LabVIEW Architect
WillToth
Member
Member
on

Thanks for the response. To clarify, the condition I am referring to is below, where I split the logger wire and write two different groups at the same time.

Ansychronous Datalogger Parallel Bug.png

The tdms file itself should support it, however the race condition is present in the log VI based on the two queue actions being seperate and the VI being reentrant. So in the above example my output for the 'Foo' group may look like the data below with items being logged to the wrong group.

TimeEvent
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMBar
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMFoo
Wed, Mar 23, 2016, 11:10:57 AMFoo

Is there any concern with removing the data queues all together and using the varient that you have in the command queue instead? I've made this modification in one of my projects already and I haven't noticed any issue.

PrimaryKey
NI Employee (retired)
on

That is true. I might look into that. In the mean time your modification should work without problems

Piotr Kruczkowski
Certified TestStand Architect
Certified LabVIEW Architect
chops88
Member
Member
on

Im bashing my head in a little with this: when I build an exe that uses this class on my dev PC it runs without issue. When I run the same Exe on my production embedded machine (W7, LV Runtime 2015) it can't find Log Data Poly.vi - even though in remote debugging the vi is absolutely located at the expected path. Log Data Poly shows up as question mark in the block diagram. Any obvious "duhs"?

Edit: nevermind - shows up as "not found" on dev PC yet runs anyway. Error 118 on Prod out of Log Data Poly, vs no error on Dev.

Edit: Wow. I was getting invalid path (118) because the time-stamp name was using the short date of the embedded PC, as designed, which was set to YYYY/MM/DD  -- the forward slashes causing the path error.

kosist90
Active Participant
Active Participant
on

Hello Piotr!

 

The library is really nice, but it would be good also to extend it with more options for file naming. Now, to multiply files index is added. But in many cases timestamp is quite enough for it. And now, to change this behaviour for the library, one does not have option for it, and shold modify the code...

Maybe, option for selection of files naming mask would be also useful for the toolkit...

 

Thanks a lot!

 

Sincerely, kosist90.

BGeels
Member
Member
on

Hi Piotr!

I'd like to point out one issue: "Build Time Name.vi" creates file names with "/" characters in the date which causes the tdms open to fail. I changed it to replace the "/" with underscores and everything works well now. Perhaps this is LV 2017 compatibility issue?

 

Thanks for creating this!