LabVIEW Idea Exchange

The LabVIEW Icon Editor plays a central role in creating graphical icons for VIs.

Yet, it has some quirks that would be great to address, such as fixing a few issues affecting users on Linux.

Because the Icon Editor is written in LabVIEW, many LabVIEW users could actually help fix issues and suggest improvements more directly, if the Icon Editor source code were hosted on GitHub. This would allow people to submit issues and feature requests (even in the form of Pull Requests with the fixed/improved code).

By transitioning the Icon Editor to GitHub, NI could establish a process that allows for the incorporation of community improvements into the official LabVIEW releases.  This would improve quality and allow for more and better feedback from the community.

Note that NI has historically shared the Icon Editor code with each new LabVIEW release (here in the NI’s LabVIEW discussion forums).  However, there hasn’t ever been an effective mechanism for the community to contribute back their fixes and feature suggestions.  So, hopefully this would only take incremental effort for exponential gains!

Background

The DAQmx apis allow streaming measurements to TDMS. This supports spanning multiple files (by setting the max file size for individual files in the span set), which is very useful.

We need a similar feature for files we're writing to directly (i.e. not using DAQmx) with the TDMS File functions in LabVIEW.

Note: The main reason we wanting this feature, right now, is that our files are growing quite large and when we run the TDMS Defragement function, we get out of memory errors in RT on cRIO (e.g. if we have 512MB RAM on our cRIO and the TDMS file is around the same size).

Alternatives

We're thinking to do this ourselves, however the TDMS file api does not support checking the file size from a TDMS file reference  (and that's a great idea, too).

I'm not totally sure how this would be added to the TDMS file api -- maybe there could be a "TDMS Advanced Spanning" palette with options for configuring and interacting with TDMS spanning.

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).

I haven't tried yet, but this might be already possible by generating C code and then building a Python package from that. It would be nice to have that automated.

I think there's also a commercial potential to sell Vision Assistant as a separate product (to Python developers).

It would be great to be able to configure LVMerge options via the command line as described here

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q0000019c3VCAQ&l=en-US

There was a previous proposal to fix this that was closed

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LVMerge-Configurable-Load-Options/idi-p/1282252

Please kudos this so that that it is considered 😉

Hello,

Actually the LabVIEW project Build Specification allow to create an old style DLL shared Library.

This kind of DLL is not so user friendly to use, because you have to define the DLL function prototypes, when you want to use them  ...  (Import, declare ... )

It would be nice, to be able to create a .Net DLL shared Library which is more easy to interface. (Without declare, import ...)

The DotNet DLLs can be used without having to create Import declaration.

The self documentation of DotNet DLLs don't need to declare all function prototypes when you want to use them.

My need is :

- To create LabVIEW drivers libraries

- To create Packed libraries, from these librairies, to be used by LabVIEW projects or TestStand sequences.

- To create DLL from the same libraries, to be used by dotNet projects

Thanks a lot for reading.

Manu.Net