Jump to content

TDMS non-contiguous waveforms

Recommended Posts

I have a TDMS file where I would like to log waveform data. But, I am only logging when certain conditions are met. This could result in some condition being met, then the condition going away, then coming back etc. For example, if I want to log when the RPM exceeds a value, I will start on this exceedance. But, maybe RPM drops back below a threshold so I stop logging. Now the RPM comes above the exceedance again, but if I log my waveform to the same channel, it doesn't account for this new t0. Does anyone have any thoughts on work arounds for this? I could make a "timestamp" channel and extrapolate out the timestamps from t0 and dt, but then I need a timestamp channel associated with each DAQ channel. I could have a channel of t0's where a property is the channel it's associated with and the start index of that data from within that channel, but all this is quite in depth. I have also thought about just making a new group or channel for each exceedance, but this could be confusing to the user if using the TDMS viewer. Is there a simpler way?

Link to post
Share on other sites

Are you constantly acquiring data irrespective of RPM? If you are, use the logger to track windows of time which are validate and then "mask out" the data during windows when the logger is disabled. I think that having a separate channel of t0's is unintuitive and potentially awkward to use.

However, I think the correct way is probably to have new groups/channels per instance, unless this adds too much overhead due to event frequency. It also depends on how the data is going to be analyzed. If you're talking about someone using the TDMS viewer to check this data, I would almost think that discrete groups would be more clear, or that writing a custom viewer to tie the waveforms together coherently might be a better solution - you might be trying to solve the problem in the wrong place.

Be sure to consider scenarios where this RPM value could bounce back and forth quickly and the effect the will play in logging.

Link to post
Share on other sites

Thanks for your response. I think I will take the groups approach for each time an exceedance happens because I agree that does make more sense to the end user. Unfortunately it is not exactly as straight forward as just "log when above, don't when not" there are some other conditions like "while exceeding the limit, log x seconds worth of data every x seconds" so there will be time gaps even if the threshold is crossed once and stays above the limit for an extended period of time. I believe I can handle these gaps progammatically with properties, by appending the waveforms in the TDMS file, but writing this time gap and number of samples-per-write as properties. Then when creating a custom viewer, using these properties to split the data back out and put "filler data" of 0's in between, where the gaps were. This keeps the log file smaller, but visually will make sense when displayed to the user.

Link to post
Share on other sites
  • 4 weeks later...

I think all of the ideas you have mentioned are valid but the right decision is going to be based off how you view the data (and how much data there is). If you were going to view it in DIAdem or another tool that can plot non-continuous waveforms based off timestamp channel I would be tempted to add a time channel and keep it in one channel (this will also impact your file size of course). If you did do this though you would also need to be aware of file fragmentation (I wrote an comparision of the affects of TDMS fragmentation here: https://decibel.ni.com/content/docs/DOC-20522)

I would probably agree with asbo though, you can add some nice features then like adding the properties related to the trigger as well. But again if the channels are very short you are going to see a lot of overhead from the headers (which will look like fragmentation although is really an expected consequence of the format).

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Aniket Gadekar
      Hello Network,
      I am writing array of timestamp in TDMS file. "TDMS Write.vi" generates an error after calling this VI as follows.
      Group Name = "DUT T1"
      Channel Names = "DUT T1_Time"
      Please let me know if anyone has any suggestions.
    • By Lipko
      Hi all!
      I'm new to the forum and I have a strange issue with reading TDMS custom properties with Labview.

      Creating user properties is working fine using TDMS Set Properties.vi, but I can't read them with TDMS Get Properties.vi. I can read the "standard" properties, and also I do see the properties in DiAdem (dataportal and using script) and also in Excel when I use TDM(s) importer. The property names are not listed when calling TDMS Set Properties.vi without the property name and data type terminals connected.   
      There is no simultaneous file reading or writing.
      I solved the problem with loading DiAdem and running a script, but that's very slow and also not all target machines have DiAdem installed (and no licence either, obviously).
      I also tried with property names such as User Properties\Device_ID, User_Properties/Device_ID in whatever combinations (I look for the property "Device_ID") without success.
      Thank you for any hints in advance!
    • By cpipkin
      I am trying to save TDMS files that ideally contain the following:
      - 3 xy graphs (each containing two 1d arrays)
      - 1 waveform
      The problem i'm running into is that when I convert the xy graphs to waveforms, the x-axis is converted to time, which isn't real or useful to me. I've attached screenshots of what the XY graph should look like VS what it ends up looking like with the waveform.
      How to I make sure the x-axis is preserved so that I can save to TDMS?
      Edit: VI is included & pictures have been updated to better represent my code.


      TDMS Waveform Example.vi
    • By malocascio
      Hi all,
      I am supporting a legacy application in LV2010, running on a realtime PXI controller. The application is throwing occasional TDMS errors, typically -2505, when I do TDMS Flush or TDMS Close operations. The description of this error is simply "LabVIEW failed to write data to the TDMS file," which doesn't really tell me what happened. Every time I write or flush, the same quantity of data is being written, and most of the time, it operates as expected. After iterating for anywhere between 2 and 14 hours, though, it eventually throws the error.
      Does anyone know in more detail what this error means, and how to deal with it?
    • By Christian Butcher
      Question: I'm trying to determine the 'best' way to structure my data when storing to disk. My data comes from a variety of different sensor types and with quite different rates - e.g. temperature data (currently) as a 1D array of temperatures and a timestamp [time, t1, t2, ..., tn] at maybe 1 Hz and analog waveform data from load cells at data rates ~O(kHz). 
      I also want to be able to read back data from previous experiments and replot on a similar graph. 
      Reading threads on this forum and at NI I'm uncertain if I'll be better pursuing a set of TDMS files, probably one per sensor type stored at the group/channel level, then at the end of an experiment, collating the TDMS files into one master file and defragmenting, or trying instead to write to a SQLite database. (I have nearly no experience using SQL, but no problem learning - drjdpowell's youtube video was already very informative.) An alternative possibility mentioned in a thread somewhere here was to write TDMS files, then store records on which files hold what data in what I understood to be a catalogue-style SQL database.
      Could anyone with a clearer idea/head than me comment on which avenues are dark tracks down which time will be easily lost in failed attempts, and which seem likely to be worth trying?
      Background: I'm currently rewriting some code I wrote last year based on the 'Continuous Measurement and Logging'  template/project. The logging in that case was writing to a single, binary file. Keeping my data format in line as I changed sensor arrangement became increasingly annoying and an ever expanding series of block diagrams lead me to start on the 'Actor Framework' architecture.
      I have some initial progress with setting up actors and generating some simulated data, passing it around and getting it from different formats onto a waveform or XY-graph (can be chosen by choice of child class to insert into a subpanel). I'm now looking to write the logging code such that I have basic implementations of several of the components before I try and write out all of the measurement components and so on - I already have a temperature measurement library for an LTC2983 based PCB and so can use that to test (with hardware) inputting 1D arrays, whilst I'm planning to use just the sine wave VIs to test waveform input.
      I'm not so far into this set of coding that anything is set in stone yet, and so I want to at least try and start off in the right direction. Whilst it seems likely changes to requirements or plans will require modifications to whatever I write, it would be nice if those weren't of the same magnitude as the entire (e.g. logging) codebase.
      Apologies for the somewhat verbose post.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.