LabVIEW Idea Exchange

Currently, the TDMS File api does not offer a way to get the TDMS file size.

Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too).  To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).

It would be useful to have a node that could be fed any wire and return the size (in bytes) of the data on that wire. In other words, the node would return the number of bytes that the wire occupies in memory.

For example, the node would return a value of:

• 1 byte when fed a U8 wire
• 2 bytes when fed a U16
• 4 bytes when fed a I32
• 8 bytes when fed a DBL
• 800 bytes when fed a 1D array that contains 100 DBL elements
• 9 bytes when fed a cluster that contains a DBL and a U8
• 9 bytes when fed an object that contains a DBL and a U8
• 18 bytes when fed an object that contains two other objects that occupy 9 bytes each
• and so on

Notes

• The node would would enhance LabVIEW programmers' ability to monitor and audit memory usage.
• The node may serve as an additional tool to detect memory leaks (by repeatedly calling the VI on the same wire and checking whether the size is going up).
• The node would simply be interesting to programmers interested in performance and would enable programmers to learn more about LabVIEW internals.
• The node would be useful especially to query the size of complex data structures, such as objects that contains other objects that themselves contain objects, or clusters that contain arrays, or arrays that contain clusters, or objects that contain DVRs.
• I would be happy if the node had a second input named "Mode" (or similar). This input may be a typedef enum with items named "Shallow Measurement" and "Deep Measurement" (or similar). This input could be required, recommended, or optional.
  • When "Shallow Measurement" mode is selected, the node would return the size of all the by-value data fields in the main input wire, but would not add up the size of data referenced by DVRs or other references. For example, a wire that contains a cluster that contains a DBL, a U8, and a DVR would return perhaps 13 bytes (8 + 1 + presumably 4 bytes for the DVR reference itself). It would not add to the result the size of the data referenced by the DVR.
  • When "Deep Measurement" is selected, the node would recursively scan all data structures, including DVRs and other references.
• In both "Shallow Measurement" and "Deep Measurement" modes there should be no limit to the scanning depth. In other words, if a cluster contains a cluster that contains a cluster and so on, they should all be measured regardless of the nesting depth. Similarly, if "Deep Measurement" is selected, and a DVR contains a DVR that contains a DVR and so on, the data behind all these DVRs should be added to the total.
• When in "Deep Measurement" mode and fed a Queue reference wire, the node could perhaps return the size of all the data in the queue. In other words, the size of all the elements present in the queue.
• Perhaps the LabVIEW compiler already uses a "Get Data Size" function internally? If such a function already exists, perhaps it would be relatively straight forward to expose it as a node in the palettes?
• Perhaps the best location for this node would be in the Programming >> Application Control >> Memory Control palette.

Thanks!

The array "Startup/Always Included" carries these Vi's into pre/post build action VI's.

The order of the vi's in this array depends on the order they have been added to/created in the project when, not the order they can be seen on the project window itself.

Here's the project window:

Here's the order within prebuild vi:

The order is NOT the same. "startup" is the first but if you delete from the project and then re-add it, it will become the last.

I suggest that the order in pre/post build VI should be:

first - startup.vi

following: always included vi's in the same order they appear in the project window.

Also, the always included list should have a 'mechanism' to change the order of the vi's in the list - be it up/down arrow buttons on the side that would move the selected vi or a similar command in a "right click" drop down menu.

In this way, any pre/post build action that may involve any of these vi's can be clearly defined and remain stable during the lifetime of the project without running into the risk of getting the wrong vi to "work" on or having to edit the pre/post build vi to add or edit the vi's names every time there is a change in the startup/always included list.