LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Idea Exchange for NXG!

NXG needs an Idea Exchange. The feedback button is a lame excuse for a replacement. Why?

I can't tell if my idea has been suggested before. (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
Many ideas start out as unfocused concepts that are honed razor sharp by the community.
This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

View All (2)

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)

Permanent Knight License

View All (3)

Hello forum

Wouldn't it be nice if we can add W10 IoT Enterprise PCs as Embedded Targets, where we can create VI executable and set it as startup programs and once deployed, the target will be automatically configured to: launch the startup programs with Embedded Enabling Features (EEF), Enhanced Write Filter (EWF), Hibernate Once, Resume Many (HORM) and File Based Write Filter (FBWF) but on different volume; as presented in NI Week TS2361 & TS8562 slides.

Thanks

When installing recent updates for LabVIEW 2018 an error message came up that said the installer needs access to "My Documents". However this location "file path" is not available. My company has a drive mapping package that has the my documents located on the server as well as my favorites so it is automatically backed up for recovery purposes. The installer keeps getting this error and forums state that the IT admins need to get involved every time to update & set my documents to local temporarily to install, then back to the server for automatic backups. This is very tedious and takes a lot of manpower. My colleague has the same issue with DIAdem 2018 as well. Looking to possibly have a fix where it gives the user a browse option to find the file path it needs for the install.

View All (4)

Version Control

hello forum

what do you think about a "feature" where developers can enforce version control on applications deployed into end-user systems? it may sound something like some feature of a certain OS, but it may be beneficial in a way or two...

the most obvious being for version enforcement, some members may not like this, but often time newer versions of application are developed to address certain issues of the previous version, and it would be pointless if the end user kept sticking to the old version for certain feature they may have grown to like

it can also be extended to subscription based or trial version deployments, a more friendly way for developers to present their systems for customers for in-situ system trial

one way to deploy this feature, is to minimally trace the execution instances of the RTE in deployed systems, across newer and older version, log them for follow-up actions, that can range from friendly popup reminders for update to application execution prevention.

what do you think?

LabView Linux Installation

We like to keep the OS installation clean/stock. That is, install RHEL and any packages required for the engineering applications and try to keep the installation packages to the minimum that are required. Typically the EDA vendors will have a script that checks that all of the Linux package required the application. If we find any dependencies we install on all machines. The LabView Linux installation script wants to be run as root and install packages. Would rather see a dependency check script so that we can install the dependencies ourselves and know what is being installed.

For the application tool itself we don't want to install in /usr/local on all machines but rather install into a NFS mounted file server so that we only need to install once and not install on each machine individually. The current Linux installation script doesn't take an argument to specify an installation directory other than /usr/local.

View All (2)

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

Suggestion:

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

View All (1)

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 😉

It might be worth exploring the feasibility of having an online vi upgrade/downgrade service, where you could submit your vi, and receive back the new vi.

I realize this wold be a huge undertaking, however, a reasonable fee could be charged. It could be a second option, in case the customer:

Has tried to do this on their own and failed

Does not have the intermediate versions to perform the required jumps

Isn't worth their time considering the cost of the service

In the case of upgrading a vi, this could serve as an added incentive to invest in the latest version of Labview, especially if the customer is several versions behind.

I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".

I know there are others out there like me, I HATE upgrading Labview. All the time required to update your custom configuration takes weeks. Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.

Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software. For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.

My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV. Making the upgrade process easier with a single tool.

Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade. If it was more seamless to upgrade, I'd probably upgrade every release!

Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.

Perhaps NI should accumulate all of these requests to Upgrade and total them as one. Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.

Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.

Morning forum

Propose to have RAD utility to include a "Snapshot/Clone" function that snap the image "exactly as is" the state of the cRIO/PAC at that image creation instance; that would include the entire drive structure, configurations, bit files, network settings, etc. Restoring from such type of image onto the cRIO will, without fail, guarantees its functionality (at least back to the state the image is created).

This come after the 2nd time of suspected corruption, when I deployed with error in LV causing irreversible/permanent impairment to my deployed RT application. First time being without a backup, that led me to reformat, reinstall and redeploy for one mistake in deployment. Second time being with a backup, apparently incomplete image using the RAD16 (http://www.ni.com/example/30986/en/), upon deployment failure and image restoration, the damage has not been reversed.

Hopefully to see this option developed soon, as the conventionally advised method of reformatting, reinstalling and redeploying cRIO, is not really practical.

Thanks and have a great day...

View All (1)

NXG home edition

View All (1)

NI's code should be excluded! Many VIs are installed as part of LabVIEW in the C:\Program Files (x86)\National Instruments\LabVIEW folder. These should NEVER be modified outside of installs/upgrades. I started a Mass Compile and, whoa, it did much more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I didn’t think to back that up. Now I fear my LabVIEW installation is dirty. NI SR#7722650 says "It does go outside of the specific folder if the VIs in the specific folder depend on another VI outside of the folder. When it goes outside, it is just opening the VI and resaving it in the current version of LabVIEW. Because your VIs depend on some VIs in the ... vi.lib it went and resaved them. But, they are already in LabVIEW 2015 SP1, so it will not change anything in them. It does this to ensure the VI is looking at the current version of LabVIEW and not an older version." If that is true, why would installation of a version of LabVIEW install VIs of older versions? Make sure all vi.lib VIs are already compiled for that version.

I found https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Force-Recompile-option-in-Mass-Compile/idi-p/2659839 which discusses whether or not LabVIEW Mass Compile changes files that are already up-to-date.

View All (1)

LabVIEW Idea Exchange

Idea Exchange for NXG!

LabVIEW Core Edition

Permanent Knight License

Installer automatically 'Force Re-install' if the software already exists

LabVIEWCLI: Add Refresh Palettes Operation

LabVIEWCLI: Add ignore errors to MassCompile

LV/PDE for Windows 10 IoT Enterprise targets

Stop using removable drives as a temporary location for installation

Version Control

LabView Linux Installation

Improved error message when missing runtime

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

Fix the Horrendous Licensing/Activation issues in LabVIEW 2018

Online service to convert Labview vi to different Labview version

Upgrading Labview From Old to New Versions - Not Easy!

Snapshot option flash image for RAD utility

App Builder should support file splitting

NXG home edition

Mass Compile should not change other folders

Mass Compile should NOT change Program Files