LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Improve that damn Licence manager!

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.

How Can I Change the Hardware Used for Activation of NI Software?

PS :

and now that we're talking about improving that damn licence manager, you can refactor it to include other ideas such as :

- Smartphone application to activate NI Software

- Add a QR Code (2D Bar Code) Option To NI Product Activation Dialog

[admin edit]

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

View All (1)

As software versioning becomes more and more popular also the automatic building of source code becomes more and more interesting.

Right now in our company we are using GIT and JENKINS for C-code material as our versioning and automatic build tool. As soon there is something being checked in and pushed to the main repository the builder gets notified and tries to build your source code having the output available somewhere.

As we are having many users around the globe these tools obviously run on a virtual machine or server somewhere.

Right now there is no option in buying the application builder seperatley and control it via command line. The only option is to put a complete development environment on there which is useless and a waste of money.

My request would be to sell the application builder seperatley for these purposes OR figure out an alternative way for doing this in a professional and neat way.

some usefull links:

http://jenkins-ci.org/

http://git-scm.com/

View All (4)

Right now in labVIEW the plots can be exported into excel and can be saved into different image formats (*.png,*.jpeg,*.eps,etc,.). In addition to the other properties it would really a very cool and excellent option to save the plot data as a LabVIEW figure with an extension "vifig" (*.vifig). The idea here is when the plot is saved as LabVIEW figure the tester with the help of an interactive tool or some thing like this reload the *.vifig to view, change the graphic object properties , maipulate legend, xaxis label, yaxis label so on... and finally save.

Let's assume a situation where the user wants to analyse the data (zoom in, zoom out, find delay etc.,) and change few properties the the data who doesn't know LabVIEW and he needs to use another programs like origin, excel etc. This could be done very easily witht he help of an interactive tool. Unlike LabVIEW, the softwares like MATLAB, Origin has such a pretty useful option.

Thank you.

Cloud LV version Migration Service

Hi !

Often dealing with old code it's always a pain to install old versions of LabVIEW to get the code compiled the newest LV version.

For example, porting code made in LV 5.0 implies converting first to LV 7, then convert to LV 2009, and finally convert to LV 2013.

You then have to install these version, licences, ...

It would be nice to have a service on NI.com website from which we could send a zip archive containing the project to convert.

Then selecting the target LV version, a could service could unzip and compile the code across all versions of LV to have the code matching the requested version.

View All (4)

Problem:

As much bug as suggestion, but since it's been this way for a bunch of years i assume it's a "feature"

I just had a project in which i defined some DAQmx tasks in the project, but in order to get them installed on the target i need to:

1. Export the tasks from the project

2. Select import MAX tasks in the installer which starts and forces me to run a new export.

3. Re-export the tasks from the project to overwrite the max export ...

(yes i could have skipped step 1 had i known the cumbersome mess)

Why cant i simply select a configuration file to include in the installer?

Why cant i select/choose tasks defined in the project?

If i want to avoid the exporter i need to edit the project xml, that's not acceptable.

Solution:

Allow to simply select a configuration file to include in the installer

Allow select/choose tasks defined in the project

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)

View All (9)

Right now, we can build an installer which embeds other installers (e.g. the LVRTE). So we can distribute the installer and allow our customers to install everything they need using one installer. This is great. But I find that it sometimes disturbs my customers when they see that my application is also installing other things (i.e. LVRTE, DAQmx, etc). They are curious about the "3rd Party Components". I totally understand this. When I download an installer, and see things like "Click here to also install Google Chrome" or Google Earth or some other spyware garbage, I am immediately suspicious. Or worse, when I am not even warned about. Bundling other installers is a common way to spread adware.

Problem:

- Bundling third party componenets into an installer is suspicious to many users.

- Bunlding extra installers also makes the un-intall process more complex (you have to uninstall things the extra stuff in a different step).

- Current method of bundling extra installers does not inform the user about all of the components being installed

So my suggestion: Allow these components to be bundled (i.e. hidden) in the application directory. I believe this is already possible with other run-time engines like the Java Runtime Engime. And I see that something similar is possible with LabWindows/CVI (see here), though I have never used LabWindows.

I guess another way to do this is just to somehow hide the extra stuff from the user. Do a silent install of all the 3rd party componenets. But I feel like that is a bit devious, and might piss off some customers.

Change uninstall script for OS X

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

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.

Smart DAQmx/MAX

So, having a new computer and installing the 4 versions i currently need i ofcourse missed to reinstall DaqMx after the last and most important LV install. After alot of time i managed to get hold of a disc, ofc slightly lower version so i first have to uninstall my current DaqMx ... this cost alot unnessecary time, when e.g. MAX should be able to add/complement itself to installs.

When i run the installer, it feels which versions of LV has Daq and which doesn't, it'd be great if you could add/complement Daq to LV's without having to reinstall it!

If this is best handled by MAX or some DAQ-installer i dont know, but as MAX feels like a hub it sounds logical to add some Update/Add/Attach DAQ-function to that.

This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.

To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.

Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. They don't even care what was used to develop the program. There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.

My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.

Typical phone exchange yesterday:

me: "just click my installer and install the program"

him: "OK, done."

me: "now run it."

him: "OK, ...... error about 2013 run-time engine".

me: "OK, install the run-time engine using the link I sent you in the same e-mail".

him: "clicking the link to go to the run time engine page....

(..30 second discussion to decide between downloader and direct download...)"

him: "click..(wait for it!)... .it wants me to register..."

me: "OK, let's forget about that. come down to the lab and I will do it for you."

End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.

While gazillions (:D) of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.

I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to "[] I don't want to register at this time, just download the run-time!".

Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers. 😄

View All (2)

MyLabVIEW

Yup, Upgrading LabVIEW versions takes a day.

The "Process" today is:

Install from media
Configure the new LabVIEW.ini
install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
Mass Compile all them......
Fix palatte views... and import and mass compile User.lib\ for here.....
Sync glyphs on the icon editor (If the link works......)
Add VIT's
Add Project Templates
Mass compileVIt's and Templates
fix "Metadata.xml"...

Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!

View All (1)

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.

Create two versions of the LabVIEW Run-Time Engine - 1 with dependencies (vi.lib, etc.) and 1 without dependencies. If a LabVIEW Run-Time Engine with dependencies were to be created, it would allow you to bypass the TestStand Deployment Utility when deploying test software created using TestStand. It would also simplify Application Builder because any native dependencies (code shipping with LabVIEW) wouldn't have to be packaged with a LabVIEW executable (only the user-created dependencies).

If maintaining two versions of the LabVIEW Run-Time Engine isn't acceptable, it would be nice to just include the dependencies in the LabVIEW Run-Time Engine. Disk space and broadband Internet connections have almost virtually eliminated the necessity for a LabVIEW Run-Time Engine with a small disk or installer footprint, particulalry when NI hardwire driver installers take up 100s or even 1000s of MB on disk.

Base and Full Evaluation Package

According to the LabVIEW 2013 readme file (see attached image), NI installs a so called NI Launcher to work around serious shortcoming in the Windows 8 start menu.

This is an essential tool because the Windows 8 start menu is flat (non-hierarchical) and if there are many NI products installed, the "all apps" screen shows pages and pages of tiles of e.g pdf help documents and it is impossible to find anything without scrolling forever.

Unfortunately, the NI Launcher functionality is quite limited to what we were used to be able to do in e.g. the Windows 7 start menu. All we can do is browse and launch a NI application.

While the readme suggest to pin often used program to the desktop, taskbar, or start screen, we can only do this by finding the icon on the Windows 8 "all apps" start screen first, where we can easily get lost if many NI products are installed! Yes, believe me, it is very tedious!!!

I suggest to add several right-click options to each entry directly in the NI launcher (similar to what we see in the windows 7 start menu):

open
pin to task bar (very important!)
open file location
troubleshoot compatibility
run as administrator
pin to start menu
...
(anything that is easily possible to implement)

Idea summary: NI Launcher should have right-click options for each entry similar to the Windows 7 start menu.

LabVIEW Idea Exchange

Improve that damn Licence manager!

Labview application builder should be seperatley available for automatic building tools like JENKINS.

Save LabVIEW Graphs, Charts, XY Graphs, Instensity Graphs as LabVIEW figure(*.vifig).

Cloud LV version Migration Service

Improve hardware configuration in installation

EXE build spec's dependent files locations should be included in Installer build spec

Allow installer to embed the LVRTE into the application directory

Change uninstall script for OS X

Streamline product registration web page

Smart DAQmx/MAX

Downloading the LabVIEW run-time engine should not require a NI profile

MyLabVIEW

Allow Same Quick Drop Short Cuts...

Make it possible to change the folder for My Documents during installation of LabVIEW

Auto-detect and install required add-on software automatically

Create RT system Image from Component Definition

Create Another Version of the LabVIEW Run-Time Engine That Contains All Dependencies (vi.lib, etc).

Base and Full Evaluation Package

NI Launcher improvements (Windows 8 only)

Bit Bit windows detection