Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
If someone would have asked if there was a setting to run a VI after an installer was build I would have said yes, until today when I realized I needed it and couldn't find it. When building an EXE there is a Pre/Post Build Actions section where you can specify a VI to be ran before the build or after it. But this appears to be limited to building EXEs and not installers. There are several limitations to the NI building process, and I'd like to improve them by having functions get ran after a build of an installer is complete.
<bakground>So i just had a silly thing happen to me, i compiled a program and deployed it to the target computer, just like i did yesterday. Then it started complaining about a missing LV 2017 Runtime ... How? Why?
I reinstalled, repaired and it didn't help, both program and RT, several times and it didn't help.
I tested another program which started just fine, so what's missing? Is it some sub-package that my custom RT-installer didn't include?
I called NI and the support technician couldn't see anything wrong either, so with him on the phone i went to the development computer to look at some installer settings he had dug up. That's when i noticed i was in LV2017 64 bit! The messages said nothing about that! </background>
Improve error messaging when missing RunTime. Include the bitness that's missing, now it only said "Missing LabVIEW RunTime 2017", if it had said "Missing LabVIEW RunTime 2017 (64 bit)" i would have reacted and understood directly, now it cost way too much time to admit. 😕
Also, isn't it time to scrap the 32 bit version and go only 64? 🙂
I am a big fan of LabView! This idea is meant to be a positive suggestion, and I hope it will be taken as such.
I almost wish this post was in jest; it is not. This is a serious suggestion that, in my opinion would improve the NI LabView program, save cost, and be much better for the environment.
I recently purchased Application Builder for LabView (both Great products). I received my Application Builder via FedEx. It comes in a very nice looking heavy mailing package with the bold label "NI LabVIEW 2010 Add-On Software. I think there must have been a FedEx overwrap with the following forms:
-Printed shipping manager page with the FedEx Bar Code
-Printed packing Pick Slip (two pages) with a certificate of conformance on page 1 of 2 and a signed page 2 of 2 by the Vice President of Quality and Continuous Improvement (I am not making this up)
Now, inside of the envelope is
-The standard folded yellow installation instruction page
-A certificate of ownership! (same serial number as is printed on the outside of the heavy mailing envelope)
-A card which says (really!) "Where is my Media?" The card says: "In an effort to reduce the impact on the environment, National Instruments no longer ships media with these kits.
Now, I assume by this point everyone sees the irony here, and where I am going with this New Idea for LabView!
IDEA: Upon successful purchase and proper payment of a LabView Add-On Software package: Email the serial number to the authorized user.
Optionally (if required by legal), send the paper Certificate of Ownership (one page!) to the authorized user, or if allowed by legal, Email a PDF of the Certificate of Ownership to the authorized user.
Beautiful outer envelope and stack of printed pages made in Ireland - Well, not needed (Give them other work, I don't want to see lost jobs)
Shipping cost and impact on the environment (Ireland to Austin) SAVED
Storage cost and space at NI Austin SAVED
Shipping cost and Air Freight Austin to end user SAVED (less jet fuel impact on the environment)
Less paper to be recycled by end user SAVED, positive impact on less energy needed for recycling!
Make it easier to find the right product in the uninstaller
If you install a lot of National Instruments developer tools the uninstaller becomes very crowded. You can have 50-100 components, often with similar names and varying name structure. Finding the component you want to uninstall/modify/repair can be difficult.
The fact that things a split into so many separate components is practical, but the components should be organized better:
They could be:
there could be a search/filter function available (that accepts wildcards)
Allow us to specify a new source location
If I want to repair or modify an installation it might turn out that the original source for the installation is gone, or I have a new (identical/compatible) source that I would like to use instead. It would be nice if the uninstaller handled this, instead of insisting on the original.
This suggestion has been made before twice, in 2010 and 2011, in a more or less similar manner, and declined both times, but in light of the recent announcement of LabVIEW Community Edition I thought it might be worth a 3rd shot, so here it is with my own rationale for it (originally posted here).
Consider eventually also making available an (also free) "Core" edition of LabVIEW coupled with a much-reduced-in-size "LabVIEW Core Runtime", with everything hardware- and advanced-math-related removed, but allowing for commercial and academic usage.
There would be many benefits in doing so:
It'd would allow LabVIEW to develop more into general purpose language, suitable for developing generic cross-platform desktop and web applications;
It'd bring all manners of new developers from outside the very specialized field of industrial applications;
These non-industrially-focused developer would develop new libraries and open source packages that'd expand LabVIEW's capabilities in all manners of directions;
And then all these elements -- 3rd party "for core" tools, new developers, new ideas -- would provide a boost to the industrial-related versions, which would become the natural upgrade paths.
Doing this might risk losing a few sales of paid-for versions, and it'd also incur in costs as NI would have to decouple many things, which would require lots of engineering hours to do. But I believe long term it'd boost LabVIEW's usage in significant ways, and result into even more sales down the line.
Typical usage progressions would become something like this:
Core → Community → Base → Full → Pro → Pro + add-ons → Suite(s)
Core → Core + (new, paid for) Advanced Math and similar core-focused add-ons → etc.
Core for entry level generic programming classes → Academic licenses for classes focused on industrial applications → Academic licenses for actual research
NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:
However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:
This inconsistency within LabVIEW is quite frustrating where one part allows invalid characters in the filename and another part will return an error. Since the invalid characters are allowed in VI filenames within LLB files I would suggest that the LabVIEW build tools also handle them graciously.
During the build process it could quite easily rename the file "pi40iv Can Connect Channel?.vi" to "pi40iv Can Connect Channel_.vi" and link the VIs that use it to the newly renamed file. The build tools already contain the ability to rename files by adding prefixes so something like this would not be that difficult.
While people may argue to just rename the filename within the LLB and be done with it, the fact that the LLB is a perfectly valid file in the Development Environment but causes problems when trying to do a build is a problem that should be rectified.
The LLB in question is one that is not developed by us but is part of a Pickering Driver Installation obtained from the following location:
It would help to have an option to ignore Bad VIs errors when calling a mass compile via LabVIEWCLI. This makes the CLI MassCompile unusable for deploying code with NI Package Manager that has API Tree VI. It would help to have an option to ignore those errors so that NI Package custom execute could run successfully. I would think it could be defined as optional argument. My suggestion for the argument is -IgnoreBadVIs true|false with a default of false.
A LabVIEW application installer generated from App Builder creates multiple folders and files in the folders. It is desirable to have a single file installer so that customers see only 1 file to install.
With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number. For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later. Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions. However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:
Changing VI connector panes
Renaming or moving VIs on disk
Adding VIs to a library
If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.
LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs. Consider the case where I make the following changes to a VI from my toolkit:
I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI. This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.
As you can read in the link below the licence manager uses the MAC addresses of a computer to create computer ID used for the activation process.
The trouble is that when you use a NI PCIe 8235 (Quad-Port GigE Vision Frame Grabber) you are adding 4 Ethernet ports to you computer and any change to any of these ports (even a fix IP change of one of the ports) will change the computer ID and therefore you will need to re-activate all your NI products... As day to day users we simply cannot work that way.
The knowledge base article below explains that in such cases we can get the hard drive serial number, send it to NI and they'll give us a computer ID based on that HDD serial instead of the computer ID given by the licence manager and we can then use it for the activation process.
The point of this idea is to ask NI to improve the licence manager so we don't have to go through this issues, I think the licence manager should inform the user about what the computer ID is based on and tell him about the options (MAC address or HDD serial) and let him choose between the 2.
I am copying the workaround posted by crossrulz in the comments to benefit users having these issues who find this idea: "Here is a work around if you want to play around in the Windows registry:
In "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\National Instruments\License Manager" add a string value named "DiskOnly" and set it to "true". The license manager will now only use the HDD serial number."
All service packs should be useable for the version you own, regardless of your SSP status. Currently, service packs are only good if you have a SSP active or had enough forethought to buy it in the middle of the year between versions.
Dealing with fonts in LabVIEW can be a nightmare due to the variations in fonts, types of fonts, rendering variations, resizing, etc. If you are deploying a LabVIEW application on another machine, frequently the fonts or settings on the target machine don't match; creating a very ugly looking panel.
When developing for Windows in the past I have always edited my LabVIEW.ini file to include the following:
appFont="MS Sans Serif" 13 dialogFont="MS Sans Serif" 13 systemFont="MS Sans Serif" 13
And when deploying an application; I include these in the app's ini file also.
This seems to work for most windows targets since MS Sans Serif appears to be a common font. I suspect this will produce unpredictable results in OSX or Vista for that matter.
What I expect as a developer is not having to deal with these font issues. I expect that when I develop an application that it has the same look and functionality; regardless of where it is deployed; even as a VI being edited on another machine with different font settings. This means that the font information must be encoded and stored with the VI itself. I would expect that both the LabVIEW editor and run-time engine would be able to recognize detailed font encoding within the VI and adjust the display accordingly based on the local machines font capabilities. This is what one expects when printing or viewing an Adobe Acrobat PDF file; and the behavior of LabVIEW code; particularly since it is so graphical in nature; should also be similar. I wouldn't expect that the actual font bitmaps be stored within the VI itself; but some detailed metrics about the font should be; height, width, kerning, etc. Thus if a font substitution takes place when being deployed on another machine; at least the text will occupy the exact same extents as the original.
Though I don't know exactly what the detailed implementation would be; it does need to be transparent to the LabVIEW programmer, i.e. zero code; zero hassle; zero worries. It should just work. I hope we can all agree on this.
One thing prevent our company to upgrade to newer labview is that the run-time engine gets too big. Even I really like the features in later version, I still have to save the files back to 7.1 then to 7.0 to build application installer. Under 7.0, the run-time engine is very small, and the installer is less than 10MB and I can easily email the program to customers. In version 8.0, the run-time engine is 65MB and now the latest version is well above 100MB.
What I would like to see is that application builder get smart, only pick what is needed and build slim app.
When the Developer Suite DVD binder arrives, the first thing I do is find a black Sharpie, cross out the name (e.g. 2010) on the binder label, and write the version of the software it contains (e.g. 2009 SP1).
Rarely if ever do I care which year the DVD binder shipped to me -- all I care about is the version of the software (the most important being LabVIEW) it contains.
Now that LabVIEW and most other NI software products are on an annual release cycle and named according to the year and service pack, I would love it if the Dev Suite binders were named the same way.
When installing a new version of LabVIEW, I always find myself resetting all of the options I previously changed from the default settings in the Tools -> Options menu. This means I have to spend my time remembering what options I changed and where in the Options menu I need to change them. It would be nice if a newer installation of LabVIEW looked at the older version's Options settings and then applied those settings to the new installation.
The same idea applies to how I configure the palettes on the block diagram. It would be nice if newer installations looked at how I configure my palettes and then set them up the same way.
With these changes transitioning to a newer version of LabVIEW might be even more seamless for users that change their settings from the default settings.
When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.
Problems with Current Issue Tracking Platform
"Platform" is a generous term for the current reporting and tracking process:
The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
Relies on unreliable methods including email, FTP uploads, phone conversations, forums...
Comparing LabVIEW Issue Tracking and Feature Tracking Platforms
Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into. The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.
I want to see an analogue for Issue Tracking.
A web-based platform with the following capabilities:
Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
Allow embedded video screen captures (such as Jing)
Allow uploaded files that demonstrate reproduceable issues
Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
An email-based alert system, letting you know when the status or content changes in bug reports of interest ()
Same username and logon as the Forums
Bonus: Visible download links to patches and other bug-related minutiae
I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.
(Picture first spotted on Breakpoint)
Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.
My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!