Jump to content

[CR] Hooovahh's Tremendous TDMS Toolkit

Recommended Posts

I haven't tested everything in there on NI Linux RT but a few of them I have.  The only thing that uses any thing questionable is the Circular buffer has a compression option where it zips the circular buffer before logging it to disk.  I used the native LabVIEW zip API so I suspect it works on Linux RT...but I forgot to test it before posting it.  Everything else is just pure G and I see no reason it wouldn't work.

Link to comment
13 hours ago, bjustice said:

Thanks Hooovahh, I've used your TDMS concatenate VIs in a few places.  Really convenient to see this wrapped in a VIPM with a few other tools.  Will install this right alongside Hooovahh arrays

The VIM Array package is a dependency, and actually included in this VIPC release.  It was just easier for me as a developer than trying to remove the dependency, and easier for you guys if everything is in one file.

Link to comment
  • 1 year later...


What I would like to see (sorry it I missed that and there is a workaround) is to be able to load only data that is relevant for displaying. I don't know how do explain properly, like google maps, for example. Given the width of the graph in pixels, the min and max time value the graph would display only what is relevant (min and max value of the data at a given pixel and only in the given timerange). And of course this should be quite fast, running in the background

I will look into the functions in the toolkit, thanks for posting!

Link to comment

Okay this is possible, but it may need extra work when making the file.  TDMS data in channels by themselves are just 1D data.  They have no way of knowing how much time is between each sample, or the start time.  But you can write to the properties of a TDMS channel, and put in extra information like the start time, and time between samples.  This works great for things like the Waveform data type, and when you write this data type to a channel, these properties are already written.  So you can read the start time property, the dT (time between samples), and the number of samples in a channel (property automatically written), and with this information you could make a slider where the user selects what section of data you want to load.  You would have to convert the sliders input, in the number of samples to read, and the offset of the read, but that can be done based on the sample rate.  

If your data isn't being written at a consistent rate, you can also have a separate channel that is Time.  Then you can read the first sample and know the start time, and read the last and get the end time.  Intelligently grabbing just the data you want would likely take some kind of binary search but would be faster than reading all samples, when the channel contains lots of data.  This requires that when you write the channels samples, that you also are writing the samples time data.  These two channels will need to have the exact same number of samples.  There are a few options, and all of them go outside of this toolkits functionality.

Link to comment

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.

  • Create New...

Important Information

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