LabVIEW Idea Exchange

The creation method for Polymorphic VIs is too cumbersome. It is a lot of work to go through each field and manually enter the information; especially if there are lots of data to create. It would be much more time-saving to be able to enter it all in a spreadsheet, and have the creator read from this spreadsheet. People would be much less intimidated to use the creator. 

Incorporate NI Batch Installer Builder into the general application builder suite.

This tool has a lot of potential for end-user use if it is incorporated into the app builder API and suite.  Batch installers can be used for much more than just installing selected sets of NI software (Which this tool is obviously designed specifically to do).  It could be used for creating installers of multiple, cross-project user installers comprising a complete system.  To do this though, the current batch installer builder needs to be made more generic to be of use.

Specifically:

• Add configuration options to control or disable license dialogs when non-NI provided installers are added
• Add configuration options to control or disable the user/company license dialogs when non-NI provided installers are added
• Add configuration options to control or disable the check for NI updates dialogs when non-NI provided installers are added
• Add batch installer version properties to allow end users to create system versions
• Add support for 3rd party installer inclusion (Dup from another idea, but I had to repeat it here)

Including this in the app builder would be even better since that should allow project based configuration and control of the batch configurations and potentially even programmatic control.

Ok this idea would be trivial for NI to include in 2011.Heck I could do it.

The idea is simply to include the JKI state machine in File/New/Design Patterns. It is BSD code and I am sure that JKI wouldn't mind anyway.

I must admit that I have an ulterior motive. If this were included in the NI distributed templates then I could use the JKI state machine for my CLD exam. And so could you!

Now let the kudos start rolling in so NI will take notice.

Motivation: in my recent project I have got a request from the end user that it would be nice to store configuration data in the same TDMS file where we store measurement results. Of course, we can create this feature programmatically, like we parse through the typdef cluster, using label names and different data types, we can create a kind of API for a TDMS Cluster read/write. However, it is difficult to make it generic, and this is an extra work anyway.

So it would be nice to save my complex Typdef cluster into TDMS, where I store measurement results in a user readable manner (via the Excel plugin) inside different groups and channels. The stored configuration cluster does NOT need to be user readable!

Since TDMS does not have this feature, as a dirty and simple workaround, I will always produce two files during measurement/data processing sequences: a TDMS, and an INI file (via the OpenG Write INI Cluster), then programmatically ZIP them into a single file for data backup (for future reference, it is safer this way).

Would not be nice if we could just write a Typdef cluster to and read from a TDMS file directly?

Like what we can do with the OpenG Read/Write INI Cluster VIs. I understand there is a strong reason why TDMS files limit the data types we can write to them, and it is not allowed to use undefined data sizes, like Variants, strings. Well, we can write strings to TDMS files, but there are some issues/difficulties with this approach if we want to go through a Typedef Cluster->String->TDMS file storing route. Hoovahh had a post about these challenges 2 years ago, where he mentioned he might make it into an Idea, but I could not find it in this forum board, so I make it an Idea: https://forums.ni.com/t5/LabVIEW/Read-Write-Variant-to-TDMS/m-p/3334203 

I imagine, NI could implement such feature into TDMS in a similar way, like there would be an "internal part" of the TDMS file where the Cluster is stored as a Variant in binary format. I do not know how the internal things work in a TDMS file, but I imagine such new feature implemented as an extra data type for the TDMS Set Properties would not hurt the speed performance of the Group/Channel level things...?

Support LabVIEW-UML integration.  Integration means supporting code generation from models and reverse engineering to models.  The UML tool must support the latest UML specification from OMG.  (This includes the specifications for interoperability.)

Other considerations when selecting a UML tool should include:

UML features and ease of use of the tool.

Support of SysML.

Integration with version control.

Additional features of the tool.

Cost of a license.

Size of user base.

When I want to insert a line of text in the Enhanced Icon Editor of an existing VI it usually means I have to overwrite my existing text or cut and paste it.

I.e. If I simply want to go from this:

To this:

It's not that easy and it could be much quicker.

I would like to be able to Right Click (or a similar method) on the Lines Cluster and select "Insert". 

This would insert a blank line and move the Line Text and Line Colors accordingly, preserving existing settings thus allowing me to easily edit the above icon's Lines quickly and easily.

This was issue number 7737579.

I wanted to be able to export and fill in the fields of a PDF Form.

There is already the ability to work with Word, Excel, and various other data bases, but a PDF Form is not supported.

I know there are other ways to skin this cat, but in my case, we have many PDF Forms already made that are test reports.

To have Labview run the test and insert values into the named fields of an existing PDF Form seemed like a no-brainer to me.

Anyway, that is my suggestion for you guys to chew on.

Thank you,

Michael