LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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. 

Can I have a API for the "Profile Performance and Memory " tool Jürgen

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.

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

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.

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

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:

 

21203i5E96ED314B36205F

 

To this:

 

21205i0BA9C1C27BE039D4

 

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 is in addition to New LabVIEW Installation Retains Options

 

During LabVIEW installation if it detects a previous version of LabVIEW has been installed it should present the user with the option (or have a flag when running the installation to allow this to be done silently) to import all VIs which are not installed by default that are present in the following folders:

  • vi.lib (VI Package Manager installs packages to this location by default)
  • instr.lib
  • user.lib

Upon importing the VIs to the new LabVIEW installation it should also mass compile them to the new LabVIEW version so the user is not faced with having to save loads of VI dependencies each time the user opens a VI which uses them.

 

This would make the getting started with the new version of LabVIEW a lot more seamless when just upgrading from a previous version.

I have several LabVIEW applications that I work on, and each of them has a Perforce workspace associated. Every time I switch to a project that is in a new workspace, I have to dig through the SCC configuration menu to switch workspaces, which takes a while.

 

It would be really sweet if LabVIEW recognized that a project file was in source control, and associated the workspace with the project file. (Especially because I could have two application projects open, each in its own workspace.)

Title pretty much says it all.  It would be a fine companion for the proposed Noncommercial Hobby/Home license for LabVIEW.

When Creating a LabVIEW Development Tool and Integrating into the LabVIEW Menus, placing items in the LabVIEW\wizard folder causes them to appear in the File>> menu of LabVIEW. However, there's a known issue that custom menu items in the wizard directory will be displayed in the "File" menu for VIs, but not for projects or in the Getting Started window.  IMO, this is a bug. However, I'm guessing that to get this fixed, we should call it an "idea" that needs implementing 🙂  Either way, it would improve the ability of add-on developers to extend LabVIEW.

 

My "idea":

 

Item's placed in LabVIEW\wizard folder should show in File>> menu of LabVIEW Project Explorer and Getting Started windows (just like it does for VIs).

So I've recently discovered Darren's original post regarding the App Builder API (http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-02-15-2010/td-p/1072575) and used it to fully automate my build process.  I can't tell you how much time this saves me!  I work primarily on a good sized app that depends on an ever shifting array of plugins and 3rd party installers, and having the ability to programmatically add or remove them from a build is a lifesaver.  But because the API doesn't extend to the installer, I still have to do that last part by hand.  I'd really like to see an installer API that would allow me to add build specs to an installer on the fly.  It would be especially handy to have the ability to add other files, specify their location, and (if they are executables) set them to run them following the install. 

 

Thanks,

JasonP

If we can have instrument simulator VIs, we can test our codes prior to the actual hardware acquisition

 

The idea proposes device driver packages from IDNet to include a vendor instrument simulator VI that can be run prior to code testing. The VI can be configurable (VISA based on virtual ports created during runtime, file paths to read from to simulate measurements and responses to messages, etc) and started asynchronously (call & forget) at the start of the program and terminates when the caller terminates.

 

or as a template from the "New > Simulated Instrument" where user can modify according to the instrument that they are going to use.

 

...and that it covers NI and 3rd party instruments

The above mentioned toolkit provides great support for S3 and SQS.  For DynamoDb, however, one has to buy a 3rd party driver (ie. Cdata) to provide labview access to DynamoDb.  It would be great to include this support in the toolkit

As part of the base package in the LabVIEW Developer Suite, include an integrated SCC in the IDE. We are using a third party SCC program right now, and it has it's quirks when integrating with LabVIEW. Our group is comfortable with the quirks now, but for a new group starting a new project, the hurdles might be big enough to nix SCC. If a LabVIEW-specific package was maintained with the IDE, those quirks could be reconciled for the LabVIEW-specific style (i.e., a file is "modified" when compiled, diffing two VI's, ...)

 

NI has been really promoting SCC recently, and I think they should officially develop (or adopt) an integrated package with the LabVIEW IDE.

 

  • I like to make plugin tools that work on items in the project e.g. Libraries/Classes.
  • I like implementing these plugins using the Quick Drop plugin framework.
  • And I normally always work with the LabVIEW Project in my standard workflow. 

 

 

If I want to act on a Library, obviously I can just open a Member VI and get a reference to the Parent Library to do this.

However, I feel it would be more natural to Quick Drop on the Library in the Project itself!!

I also feel that it would be faster...

...And isn't that what Quick Drop was invented for?

 

I don't know if native options would ever exist, I am looking to call my own shortcuts - but there is alot of scope to implement custom plugins.

I have only given one example above.

 

Cheers

 

-JG 

 

Quick Drop on Project Window.png 

If I create abstract messages for the calling actor, I often have to write a wrapper function so the child classes can use the abstract message.

 

This is a repetitive task that would be a prime candidate for scripting. Images below is an example of the type of wrapper I'm referring to.

 

Send Abstract Message WrapperSend Abstract Message Wrapper

 

 

 

Quick Drop plugin VIs can currently be assigned to Ctrl-Key shortcuts.  This is a great way to quickly invoke the plugins that I use most.  However, it effectively limits the number of available plugins to 26, and it makes it fairly difficult to remember which Ctrl keys correspond to which plugins when there are a lot of custom plugins to choose from.  I would like the option to invoke Quick Drop plugins with multicharacter shortcut strings, the same way I can drop common panel and diagram objects with shortcut strings.  One possible way to do this could be to allow plugins to be included with the other shortcut objects in the Front Panel or Block Diagram shortcuts:

 

QD Shortcuts.png

This Idea applies to all Libraries but my main Use Case relates to Class Libraries

 

I am not sure how everyone arranges there Classes, from trolling online it seems common that non-publically scoped methods tend to get placed in their own Virtual Folder and public methods are at the top-level. 

 For example:

 

21672i8DF9E7B8B93A8490

 

Unless my Class only has a few methods I would take a similar approach however, most of the time I like to categorize them in more detail. The reason being this is my palette from where I choose my methods, and I like to group them using the following logic so that I can get as much information visually out of the organisation / layout of the Class. I like to have the only top-level method as the constructor if there is one (so I can see that there is one or not for that Class).

I only create the Virtual Folders I need, but usually there are a mix from the follow example:

 

21674iC695C8CF5C268BEE

 

The problem I have with the current design is that I don't know whether I have scoped my public methods correctly, as I could have forgotten and they are still left not specified - which is the default when you create a new Virtual Folder

 

21676iAB6ED5F8E26BA877

 

Currently there is no way to tell the difference from the above two Virtual Folders unless you right click on them or possibly look at the contents.

This is not great as there is potential that I could have scoped things wrong which normally leads to me having to check or recheck the scope is correct.

 

21678iF61DE0BD73C6A4AD

 

As LabVIEW is graphical by nature, it would be much nicer if I could visually see a public scope glyph to differentiate it from a not specified Virtual Folder.

I selected the color green as it is a natural opposite to red (private) and has not been used yet.

For example:

 

21680iDEBCDA19ED6B9DB4

 

Therefore, my original implementation would look like the below, and I can straight away see if I have scoped the public folders correctly.

 

21682iC59F6703EC013513

 

I am sure there was a reason not to include it originally.

I am interested to why and if there is a good reason not to show this too.