LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

For all of us not running an english OS but want to install plain english versions of NI products:

Please give us an option or a documented method to install LabVIEW and MAX and driver, etc. in plain english.

While it is possible to install LabVIEW in ENG, the MAX and the driver installer lookup the OS language and install the localized versions 😞 (just tried with a new PC, W10 and LV2018 full dev suite, even set my language setting to ENG, however I have to install the localized W10) That is not helpfull if you want to look up the big commuinty help or knowledge base entries and can result in 'funny' error messages.

For the driver DVD I think I found a hack in the setup.ini

[Localization]
Languages=9,7,12,17,18,2052
#ForceLanguage = 9
CustomRes0009=SupportFiles\resourceEng.dll
CustomRes0007=SupportFiles\resourceDeu.dll
CustomRes0012=SupportFiles\resourceFra.dll
CustomRes0017=SupportFiles\resourceJpn.dll
CustomRes0018=SupportFiles\resourceKor.dll
CustomRes2052=SupportFiles\resourceChs.dll
StandardRes0007=SupportFiles\niresdeu.dll
...

by uncommenting the red part. But editing the setup.ini ??

OK, in this case the hint was there (or forgotten to remove :D)

The actual suite installer comes with a .xml configuration file where that hint was missing or overseen.

I suggest something like:

Installer found local language version: <OsLang> ,

Install (where possible) in language: <ListOfSupportedLanguages>

That setting is hopefully stored for future automatic updates 😉

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.

View All (1)

free label format

How often do you find the need to orginize data into a table format while documenting your vi? I for one, could & would use it all the time! Creating a resizable table free label we all use in word & excel seems like a simple task and would aid in organizing and documenting data into a more readable format. A ctrl+double-click or shift+double-click could serve as an easy access method, tab through the contents, and resize rows and colulmns vis a cursor change while hovering at the specific borders. Free Label, New type, table format, organize data, rows, columns.

View All (2)

Upgrade LV Project RT targets

I've had a look around and can't see anything in here like this already (which surprises me so I'm suspicious that it's just the search algorithm failing) but I'd like to see options in the LabVIEW Project tree for changing target hardware.

For example, I have a development underway using a cRIO-9114 chassis with a 9024 controller, and a 9144 EtherCAT expansion chassis. The primary chassis is about to be upgraded to a 9116, as we need a bigger FPGA, and although the hardware upgrade process is straightforward, upgrading the chassis in the LabVIEW Project is not a possibility. Instread, I need to create a whole new target, and copy and paste every VI, node, FIFO, DMA etc. across. There's quite the possibility that I'll miss something, or the new target won't have all the same settings (Scan Mode period and priority settings for example), leaving me with that niggling feeling that something under the hood will be wrong. It would be much neater if this was an automated migration.

Furthermore, as the hardware is not here yet, I need to create the new target and all it's modules manually, which will take me quite some time. An automated migration would save me that trouble.

I would like to be able to specify an autrorun.inf, an autorun.ico file and a copyright file in the Build properties for the LabView (or CVI) installer properties to be copied to the ..\Volume directory for the built installer. I can then simply build a DVD from the installer's ..\Volume directory and the DVD will autorun on insertion (if autorun is enabled). Of course, I can manually add these files to the DVD build, which I do, but if it is simple fix to the installer, well, Ithe next person who takes over my projects is less likely to make a mistake.

We are a site that use multiple NI software products(LabView, Realtime, Vision, sound & Vibration, etc.) and multiple copies of each so we use the Volume License Manager.

My idea is to simplify installation, maintenance, and updates for folks that have a large usage base by:

Stop needing to keep a record of all my S/N's of products and type them in when I need to do an install by:

Allowing the install CD to query the License Manager for licensed products on the target and then automatically select them for installation without needing S/N's since the LM has that info.

Make the NI Update Utility configurable to allow it to update all software available(service packs, and new software releases like LabView 2012) not just bug fixes.

The current system is pretty abusive to admins who need to maintain 50+ systems...how about a little help out here 😛

LabVIEW 64bit french version

Currently we can only get the code from NI if we've purchased the stand alone license and it's double secret zipped & passworded. The object is to select the DSC-RTE "additional" installer at "Installer build time" and build one clean package. Our work around was to buy the customers license, download the code, and add the DSC-RTE installer as a pre or post command (or manually install before running our DSC app.) Vision products are setup for clean Installer builds...follow their model.

Hi,

I have several Labview versions, and some files are in 2010, others in 2011.

I often work with both version launched, and when I want to open a file, I have to do File=>Open and choose the file (with the good Labview version). Opening a 2010 file with both version 2010 and 2011 launched open my file with 2011, whereas it has been saved in 2010... (maybe a bug ?)

I would appreciate if I could drag and drop the file I want to open on the LV icon on taskbar (+1000 to the following idea : here)

Best regards,

Make LabVIEW a web based application

Using Google Apps and similar products I've come to really love the access I get to all that functionality regardsless of which computer I'm on. Imagine how great it would be if you could have LabVIEW available in the same way!

All the work, your VI libs, the compilation etc. would be on the hosting server (sharing VI libs, source code control and collaboration in general could be made very flexible indeed). There would be a few challenges to overcome, e.g. when you are writing code for different targets, but nothing unsolvable I think...(if there are any show stoppers we could have both...a web based editor as well as the traditional solution).

And the host could offer you to work in previous versions of LabVIEW...and new versions would be available as soon as they are launched, and you could build apps for different operative systems in one go.... no volume license manager headaches...the list of possibilities and improvements is endless

Treat WSL like a RT Target

One thing I love with LabVIEW is to be able to execute the same source code on multiple targets (Win, Linux, NI Linux RT, etc)

I use Linux more and more to deploy my LabVIEW built apps and now instead of VM I use Windows Subsystem for Linux (WSL) on Windows 11, in very few steps I can create an Ubuntu instance, add a desktop and xrdp and then remote desktop into it.

What would be fantastic is to not event need a desktop and xrdp but just install LabVIEW in the WSL instance via terminal and then run LabVIEW on Windows and select the WSL instance as execution target as I would do for an RT target.

View All (2)

Having sold applications that use functionality from the OPC UA Toolkit we run into an issue if we upgrade our LabVIEW version and continue to develop those applications beceause the OPC UA deployment license will then stop working if we upgrade the software we have delivered to them to one developed in a newer version. So, even though the customer has an OPC UA deployment license and we have an updated developer license it is not enough because the deployment licenses have to be updated as well (and it does not help that deployment licenses are not something we can bunde with the upgrade of the software either). From what I understand new deployment licenses will not actually cost anything, they are provided by NI as long as you already had a deplyment license for the previous version - but the logistics of this is a nightmare for us. Instead of just delivering a new installer with an updated version of our software we have to get involved in upgrading the dpeloyment license for all of their systems each time we have gone to a new version of LabVIEW.

View All (4)

View All (1)

LabVIEW Core Edition

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

And so on and so forth.

Please consider it, okay? 🙂

View All (6)

It should be easier to change the default copyright company in Application Builder.

I got the following from NI support to change the name of the company that is copyrighting the software.

1. To show the desired hidden folder, you must select Tools>> Folder Options >> View >> Under 'Files and Folders'>> 'Hidden files and folders' >> check the 'Show hidden files, folders, or drives' >> Select 'ok'

2. Navigate to C:\ProgramData

3. Open ProgramData >> National Instruments >> LVProductDLLInfo >> 12.0.0 >>LabVIEW_ADE_120000.ini ***Please note that the folder 12.0.0 may instead be 14.1.0 or another numeric value based on which version of LabVIEW you are using***

4. Change the RegisteredOrganization and RegisteredOwner to the appropriate organization and owner respectively.

The fix NI support sent me was to change the name of the current software owner.

The company that owns the software is usually writing the program for another company that is paying to have it developed. If the software owner is not careful they may assign the copyright to their company or to the company that they developed software for last. I am sure that the company that had software developed will be surprised if their name is not listed as the legal copyright owner.

Stan

The addition (in 2013) of the ability to use tags in the directory names of the builders struck me as really useful - normally I build to a ...\MYPROJ\... set of directories (each of the ) then rename ..\MYPROJ\... to ...\MYPROJ x.x.x.x\.... as required. When I read of the ability to use [VersionNumber] and [ProductVersion] tags I thought wahooh - at last an automated mechanism. However when I played with the tags it became clear that each builder (app; Installer; Source) used its own version and did not have access to any other builds' version info. Hence I could not use a single version in all builders. Especially as the Product version is one digit shorter than the others.

Given the principle that the builds now accept tags (akin to macros in my opinion) it would be really useful to have a global version tag (that could be set automatically or manually as present versions) accessible from all builders in a project for use in directory name creation and ---- to go even further ---- to have this global version available from inside the project VIs so I can use it in my window titles and About boxes (I currently use App Info VIs to get a version, date etc to do this).

Currently the only want to back up an entire lvproj and all the vis is with Save to Previous Version. Otherwise you need to create a source distribution or zip file for each system (my computer, crio, FPGA). Could we add a project build spec that would allow you preserve the project structure like in Save to Previous Version but allow you to customize the output folders to help users reorganize their projects when moving from computer to computer.

It could feel very similar to a source distrbution but for the entire project. So any dependencies are also pulled for their respective

Ideally everyone would have they project nicely organized in a folder with perfect subfolders but when you're given a project written by someone else, sometimes files are scattered everywhere and we end up missing dependencies when moving.

View All (5)

LabVIEW Idea Exchange

NI software installer should allow a plain english installation (not only for LabVIEW)

Option to migrate VIs installed in a previous version LabVIEW folder to new LabVIEW installation

free label format

Improvements to the "NI Update Service" (shut down the system, when you finish the download.)

Upgrade LV Project RT targets

Specify installer "..\volume" files - such as autorun.inf and autorun.ico

Help folks that use the Volume License Manager

LabVIEW 64bit french version

Include DSC-RTE software in LV Professional Development System so one can build deployable DSC apps.

drag vi, llb, ctl, lvproj... on getting started window

Make LabVIEW a web based application

Treat WSL like a RT Target

OPC UA deployment licenses should be version agnostic

Linux flavors for Labview & related software

LabVIEW Core Edition

It should be easier to change the default copyright company in Application Builder

Global version TAG in Build spec directory creation

NI must go to monthly or yearly subscription model for software licenses

Remove optical illusions from NI Activation Wizard progress bar of mystery

Export Entire project with restructuring