From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

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

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.

Mass Compile changes files that do not have a LabVIEW code extension such as ".ctl" and ".vi"! Why is it trying to load, check, and save files with extensions such as ".bak" and “.err”? The following example shows files that a prior mass compile found problems with and I renamed them and removed them from source code control.

 

  ### Bad VI:    "EditString.ctl.err"              Path="C:\cvs\r8000\labview\app\editor\controls\EditString.ctl.err"

  ### Bad VI:    "MCNavigate_old.vi.err" Path="C:\cvs\r8000\labview\app\remote_control\MCNavigate_old.vi.err"

 

Another example of this is described in https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Mass-Compile-should-not-touch-Subversion-files/idi-p/1081483 which says files with ".svn-base" are changes. Yes, there was a specific improvement made to ignore those, but really, that wouldn't be necessary if Mass Compile stuck to known LabVIEW file types.

Hi,

We are developing an custom LabVIEW based test application where installed in different customer's location. Infact we do multiple releases when each task or sprint is completed.

Idea or Query: Do we have any options in labVIEW for auto update whenever there is latest build available in server. A like mobile SW update.

If no, any chances that NI can add them into upcoming releases?

 

Regards,

Venkateswaran.K

It would be nice, if during installation of LabVIEW, installer will configure Firewall as needed for LabVIEW. For example, Network Streams - is standard LabVIEW feature, but to use it, one should manually configure Firewall (as described in this KB article). I'm sure, that there are other cases when similar should be done.

Of course, then exe anyway should be added to Firewall exclusions list, but at least one could use and test Network Streams out of the box, without googling out why it does not work...

This feature could be optional during LabVIEW installation, but if it is possible to automate something - then better to have it automated, then refer to some manuals and KB articles...

To generate a VI or set of VIs with a general driver to get low-end FPGA boards to work with LabView FPGA. Parameters will only come from the users to make this dynamic, this would be the total count of I/Os FPGA type, location of I/O items (eg. buttons) in the FPGA board, etc. It would be a bit of work, but also would pay off at the end. Doing such is no more than an extension of LabView if done well, let's say written in an xml file plus it would be a very powerful tool for researchers, and would generate more sales to use LabView FPGA for more researchers, university students, and engineers who want to test a few things without full initial commitment to NI tools.

 

 

Unbelievably NI has introduced a bug into LV 2016 whereas the "Open/Create/Replace File" function does not display the input prompt to the user.  In fact no File I/O functions will display the inputed prompt.  Worse yet there are no prompts for finding or opening files within LabView itself.  Try opening a vi, there is no prompt whatsoever.  In previous versions of LabView there is a prompt telling the user what to do.  e.g. "Select File to Open"

 

This is very bothersome when you open a vi that cannot find a called vi.  Prior to 2016 there would be a prompt telling the user what vi it is looking for.  Now you are left to guess what vi Labview cannot find.

 

This is a huge problem for me as I prompt the user to find files and folders in a  great deal of my code.  If I were to upgrade to 2016 I would have to go through 100's of vi's and add dialogs telling the user what to do prior to calling any File I/O functions.

 

The most disturbing aspect of this issue is that NI did not fix this bug prior to releasing 2017.  It is beyond me how this bug could have made it to another version.  This bug alone requires a fix and an upgrade for both 2016 and 2017 immediately.

Hi, 

If we got an option to auto upgrade all the deployed executables in the network. In case of new version is getting released. Like the update features avaliable in all mobile applications.

 

This will be very useful in case same application is being deployed in many places and needs to get upgraded after the new release.

 

Thanks,

Badri

Would it be great to have free labview license that would allow to read VIs and save them to the previous version you have?

Immediate upgrade to new version does not happen in my case. I can not justify it for my boss, it adds a lot of work to upgrade all customers to new version, I hate idea of supporting multiple versions of code.

The main reason I need later version(s) is forum posts, other solutions that I would be able to open, save to the full one for real use. May be I will see the beauty of VIs in new versions and agree to upgrade 😃

Hi

 

Is it possible that the contents within the instr.lib to be defaulted to read-only every time LabVIEW launches? VIs that is drag-drop from the pallet onto block diagram is currently modifiable and may cause unintentional code modifications, especially due to the 'save all' function and hasty/improper shutdown. The extend of the damage may be inherited over time.

 

Also propose to default modified instr.lib VIs saves to be in active project folder instead of the instr.lib.

 

Hope to see these features in future versions.

The purpose of this is the user saves time creating installers  that have the same application but theirs configuration files are different.

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

Delete option in Context Menu.png

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is non comfortable.

 

So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past...:smileyhappy: He! He! He!

To make easier the distribution of .lvclass, it would be interesting to create packed lvclass (.lvclassp) like lvlibp for lvlib. A second idea is the possibility to call lvclassp 's Methods in Teststand.

The NI Volume License Manager has a tool to create a volume license installer.

 

If you want to include Drivers you have to copy them to the installer folder _src\DriverDVD and then modify the nisuite.xml file (depending on license server you run)

 

There needs to be a simple way to say add NI disc to installer folder. Or at the end of creating the installer it could ask if you want to include other discs.

 

This should work for adding the driver disc and other extras like the Xilinx Compilation Tools, etc...

 

That way you can easily put together a full LabView Development install location for users.

 

This is a real pain for me and I think this should not be considered expected behaviour of LabVIEW. But since I have been told it is I am posting this as an idea for the Idea Exchange. Let me explain:

 

Imagine you build an application which makes use of a large number of files (images, text files, etc) and you would like to include these in the build specification of your application. Imagine you want the files to go to various different custom locations on the computer (some in documents, some in a folder on your desktop, some in another location... the list goes on). I have such an application and it includes about 25 different folder locations I had to insert manually as destinations for the files. This is fine, I expect to do such a thing and it was simple enough (although time consuming).

 

Now comes the pain:

 

I now want to build an installer which uses this EXE build spec. If I use the EXE build spec in my installer build spec the result is to place all of these dependent files in the same folder as the installed executable, not the locations I defined in the EXE build! This means I have had to go back and create a new EXE build spec which contains no dependent files (so that it compiles without placing files everywhere) and then back to the installer to use that EXE build and then define all the location yet again! This has been super time consuming.

 

Upon discussion this is apparently expected behaviour as installer build specs are seperate to the exe build specs....... except am I not right in thinking the installer build spec relies on you having an EXE build spec???

 

So currently the situation is this: I have to have to have an EXE build spec containing the custom destinations which I can build and use to test my application. I then also have to have an EXE build containing no custom locations which when built is useless since it is missing dependent files, but purely there to then create the installer build specification which I have to define all custom locations in again.

 

My proposal is simple: When you create an installer that uses an EXE build spec with custom locations for files it should replicate those locations in the instaler. Simples!

 

Note: If this was super confusing download the attached project and see for yourself. (LabVIEW 2013)

Hi,

 

I have some suggestions for the Uninstall.sh script that comes with the OS X installer:

 

1) Copy it on installation into the main LabView application folder so that users don't need to find (or redownload, in my case) the original installer just to remove a seven-day evaluation copy (grrrr....).

 

2) Lines 85-88 need modification. They read:

 

[from the file Uninstall.sh]

echo "pid=\$( ps -axww | grep nisvcloc | grep -v grep | awk '{print \$2}')"
echo "if [ \$pid ]; then"
echo "sudo kill -6 $pid"
echo "fi"

 

When I ran the script, the $pid was omitted in the screen output:

 

[from the screen output of Uninstall.sh]

pid=$( ps -axww | grep nisvcloc | grep -v grep | awk '{print $2}')

if [ $pid ]; then

sudo kill -6 

fi

 

It looks like the "$" should be changed to "\$' on line 87:

 

[Corrected line 87 for the file Uninstall.sh]

echo "sudo kill -6 \$pid"

 

3) For my OS, there is an error in both the documentation lines 85-88 and the associated code on lines 189-193: the process ID is associated with the first variable of the grep expression, not the second. The second variable returns the TTY for the process, which for nisvcloc is given as "??".

 

[from the file Uninstall.sh]

echo "Stopping the NI Service Locator..."
pid=$( ps -axww | grep nisvcloc | grep -v grep | awk '{print $2}')
if [ $pid ]; then
sudo kill -6 $pid
fi

 

[from the screen output of Uninstall.sh]

Stopping the NI Service Locator...

kill: illegal process id: ??

 

[Corrected line 190 for the file Uninstall.sh]

pid=$( ps -axww | grep nisvcloc | grep -v grep | awk '{print $1}')

 

[Corrected line 85 for the file Uninstall.sh]

echo "pid=\$( ps -axww | grep nisvcloc | grep -v grep | awk '{print \$1}')"

I have LabVIEW installed on two computers - a desktop computer and a notebook computer. Neither computer can access the internet. When activating my products, I must select the product to activate and then enter several pieces of information (name, s/n, computer ID, ...) for every product. Repeat for 2nd machine. I would like for the web interface to retain the above information so I don't have to enter it many times in order to collect the keys for all of my products.

 

Another option would be for the web interface to return licence keys for all products registered (or give me check boxes to select products to register) to the given s/n so that I can copy/paste them to a file. I can then move that file to the target computer and activate everything.

 

It would be very useful if we could have same QuickDrop PlugIn with the same shortcut depending of the selection object that we have made in "Block Diagram" or in "Front Panel".

 

For example:

- Imagine "Ctrl+C" short cut, this would be useful for lots of QuickDrops that comes to my mind.

  • Copying to clipboard a bundle by name text.
  • Copying to clipboard a unbundle by name text
  • Copying to clipboard a selected case.
  • etc....

When installing LabVIEW or and Executable with the RunTime-Engine, the installer needs Access to the My Documents folder. If the installer didn't find these folder (e.g. the folder is redirechted to a server path), the installation fails. Please make it possible to change the used folder for My Documents during the installation. 

We have the ability to create a "Component Definition" when we build a Real Time application. This is useful for pushing an application to several identical systems, as long as that system is sitting on your desk (or at least on the same network). This is great to be able to ensure you get all the same/correct driver and needed modules on to the systems.

 

But what if you need to update a deployed RT system? If you're just updating the application, it's fairly easy. I have tools to take care of that and make it painless for the customer to do it themselves. If you need to update the operating system, it's a completely different task.

 

Since we can create this component definition, why can't we go one step futhure and create a complete system image (application, OS, drivers, everything...) from that definition? This system image could then be imaged to the RT system using the system configuration API.

We can try LabVIEW as Evaluation.
But the package we can use is only Professional Development System.

Why is there no Base or Full package ?


If ni makes these package, we can try LabVIEW more easily.
And more engineer can use it!

 

 

Thanks,

Tepig