Additional NI Software Idea Exchange

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

NI License Manager is a really good tool to check in a visual way in which products are licensed and connecting to the Server License.

 

However, in case you need to request access from NI License Manager to the server through the "Manage" button on the Network License tab, you need to go specifically to each machine physically or set up a remote third party tool to request the access with that button.

 

Therefore, it will be a great solution to create certain options for the NI License Manager and set up some Master License Managers to make these requests from a few selected computers. Adding value to the security of the server as it will not be accessed very often.

 

Thanks.

Currently the Find Systems VI in the system configuration toolkit is great for searching NI hardware on the network to connect to. However for large networks it would be convenient to search specific subnets and IP ranges.

 

IDEA Summary:  Please make a optional input terminal for the Find Systems VI that can search a specific subnet or range of IP addresses.

 

 

With VLM 3.1, a number of default reports are available (License Activity, Client Activity, ...).

Some of the default reports (License Activity, Seat utilization and Seat Utilization (Concurrent)) have a License field that the user need to complete.

 

The issue I have is that we are using different licenses (Dev Suite, Dev Suite with Data Management, Dev Suite with FPGA, ...) and that I cannot generate a report that includes all licenses together.

 

My request is to have the possibility to select "All licenses" in the License field.

 

I am more than willing to validate this feature in an alpha/beta release.

The current situation w/ homebrewn installers is really ugly - see tons of forum posts.

 

We have decent package management technologies like APT, which industry-grade proven for over two decades, that handles all the usual aspects of software deployment - downloads, installations, dependency management, fully automatic upgrades, inventory, clean removal, etc, etc. This also includes post-installation steps like database updates, automatically building OOT kernel modules, etc. Such technology has also been ported to esoteric and very operator-unfriendly platforms like Windows.

 

The key point here is the Distribution: software has to be compiled and packaged for a particular distribution and target architecture, so everything (including ABIs) really fit together and the software is neatly integrated into the ecosystem.

 

There are two major package manager stacks: dpkg/apt and rpm/yum, each used for dozens of different distros/platforms. Once the build process is set up (est. just several man-days initially), dozens of distros can be easily supported w/ neglectable effort. With an CI, the whole build/packaging/deployment process can easily run completely automatically.

 

Once packages are available that way, operators just have to add the vendor's package repository once to their system and then everything - including updates - can run automatically. Operators also can easily mirror repos, eg. for offline deployment, additional QA+approval, etc.

 

Since 20+ years there is no need for homebrewn installers whatsoever. They're just an extreme waste of resources - on both vendor and user side.

 

Properly packaging directly to certain distros and using only the native package managers for deployment would make the tons of operating/deployment problems (as seen here in the forum) go away - they're basically but problems w/ the distro-incompatible homebewn installers.

 

--mtx

Currently, in the RT Utilities - Software palette, we find the Format.VI, but it would be useful to be able to specify which partition/drive to do it for. 

This way, even systems running in (RAM) memory (for example, by taking advantage of the PXE boot) could be formatted easily. 

 

The system configuration API allows a fast check for available hardware using the expert strings as an input for the detect hardware vi.

It would be nice to have a similar option to check if a specific software module or driver is installed.

At the moment only the whole list can be obtained, which takes a very long time to query.

It makes sense to run the Volume License Manager on a server-based environment.

Typically these environments are managed by the IT departments with restricted access to users.

Managing licenses like it needs to be done with the Volume License Manager is sometimes the responsibility of key-users outside of the IT-department.

With the Volume License Manager have to be operated as an application on the server, this often makes it difficult to get the necessary access rights (remote desktop...) granted from the IT department.

It would be much easier to do the license management via a web based interface provided by the Volume License Management Service.

 

see also: https://forums.ni.com/t5/Additional-NI-Software-Idea/Remote-Management-of-the-National-Instruments-Volume-License/idi-p/3108997

 

Hi,

I suggest including TWAIN protocol support in the IMAQ Vision drivers.  

Regards,
Kira T

I've been working with LabVIEW for about 3 years, on the same PC.

All the time I've installed all the NI-Updates.

This time the LV 2016 update couldn’t be done, because of lack of memory space on my PC. I’ve deleted a lot of data, but 48 GB (!!!) still weren’t enough.

Then I’ve made an EXCITING DISCOVERY.

In the directory C:\ProgramData\National Instruments\Update Service\Installers there are several older (up to 2013) folders. Overall data volume of these was 131 GB! This is a half of my hard drive!!!

Why didn’t NI-Updater suggested to remove these old data before I have started to remove some MBs of my old documents?!! Is the data really essential for NI-SW? Is there ANY need for this data on my PC?

I’m really embarrassed by this issue. To overload clients PCs with such a trash data is not a good approach!

And regarding LabVIEW-Updates, I think the installer should ask the user if he/she wants to keep the old version of LV instead of always keeping it on PC.

What is the point on keeping the old version of LabVIEW anyway? Once opened with a new version, no VI can be opened with the older one.

Hallo,

I have detected a small but cumbersome problem witch at the end of the day can grow to a problem with heavy impact related to security updates.

 

In the actual release, the NI Volume License Manager can disable the NI Update Service on the client machines if the Administrator of the Volume License Manager sets the option “Disable NI Update Service on all client machines”.

 

Now, for example, there is a scenario on witch clients get the License for a DIAdem installation from the NI Volume License Server and get the License for a LabVIEW installation from the local License Manager.

 

The problem is, that the user cannot update his LabVIEW application using the NI Update Service because it is blocked by the administrator of the NI Volume License Manager for the DIAdem installations.

 

There should be the possibility to disallow the Updates by Products instead of disallow the whole NI Update Service.

 

With best regards

Franz

I recently handled a service request (SR# 1698819) in which a customer was confused why TestStand was not listed in License Manager (LM) when his admin had generated a disconnected license.   For him, all that was showing up in his LM was the following screen shot:

 

TS.jpg

 

I explained that the Developer Suite with Industrial Monitoring and Automated Test (Disconnected License) includes a disconnected license for TestStand. 

 

The product suggestion I'm making involves being able to expand disconnected suites by clicking a plus button to the left of the suite for example to view all of the software that's available to the client.  This will avoid future confusion on the customer's end and reduce support call volume.

Send the VLA log automatically as notification to the VLM administrator. 

The VLM log can send the logfile automatically to NI, however this is not an option when the server is not connected to the internet. In this case, emails can be send to the administrator. It would be great if the VLA log will be attached to the email, so that the administrator can forward this to NI. 

Here at the University I work at we use a large number of license management software (mainly flexlm).  This past semester I installed a new license management service that would be used to serve licenses to multiple labs in multiple buildings across campus.  Unfortunately after installing it and deploying it to a large number of machines I realized that my Labview license manager had stopped working because both processes were trying to use the default port of 27000.  At this point in time my only option was to change the port on the Labview license manager to a new port (in this case 27006).  Unfortunately due to the current nature of Labview I now have to visit 100+ machines in my building and elsewhere and point them to <SERVER_NAME>:27006.  

 

A peer here had a similar issue with the Autodesk software Autocad, which runs on a similar license manager.  However, Autocad checks a range of ports automatically if their license server isn’t available on the default port.  It would be nice if Labview would do the same.  That is, check port 27000 for a license server, if not found, check 27001…up to 27009 then store the port in the software.  Because of this, we do not have to tell Autocad which port the license server is on and if it changes, nothing needs to be done.

 

What I am suggesting is that users not be required to point to a given port if the default is not used.  Instead, the Labview client look at 27000 on a given server, if not found, it looks to 27001, this continues up to a maximum of say 27009.   

 

Another potential fix for such issues would be to have a registry key that can be updated through group policy.  This existed in Windows XP but in Windows 7 this key was removed an instead an .ini files used.

 

Thank You,

Garret Coffman

Currently, Switch Executive virtual devices can only be imported and exported through Switch Executive itself.  It would be really nice if instead Switch Executive virtual devices were handled through the MAX configuration import and export wizards.  This would simplify test system deployment, particularly since the MAX configuration import wizard can be easily automated through deployment installers.  Importing of Switch Executive devices can currently be automated, but you have to create an executable using the Switch Executive Configuration API and then call that executable using a batch file called by your deployment installer.  It would be so much simpler and more consistent if the MAX configuration wizards supported Switch Executive in addition to other products such as DAQmx and VISA.

Currently, our NILM license daemon doesn't support the TIMEOUTALL function when used with a FlexNet server. The purpose of the timeout is to cause an application to release its license if idle, which is useful in the case that a user doesn't realize LabVIEW or another NI program is still open on the client machine. The TIMEOUTALL command is a standard FlexNet option.

 

It would be useful if we provided this function, or provided a similar function in the Volume License Manager server product.

Hi,

 

NI DAQmx Home Assistant integration would be cool.

 

https://www.home-assistant.io/integrations/

 

BR, Ilkka

I have been using Flexlogger for about 6 months now. 

 

Few issues I would appreciate if could be addressed. 

 

I would highly appreciate if Accelerometer channels can also calculate velocity and displacement. ( Read Dewesoft X another platform that does the same)

 

It would help greatly either if we could move out screens tabs independently out of the window like a web browser or some type of multi-monitor support for display screens

 

We can change background colors or set the system as transparent, it would be good if we could change the transparency value for UI indicators. 

 

It would also be a great feature if we could get configure display settings on the graphs to a higher degree. Graphs could use an aesthetic overhaul. 

 

It would be great to have some graphics feature for P&I which are interactive based on the unit values that are linked. 

 

Few more dial options, and maybe some design resources on the training pages for building better looking dashboards. 

 

Regards

Sandeep Ghosh

Quality Engineer III

101 William White Blvd.

Pueblo, CO, 81001

Phone: +1.719.585.3926

Mobile: +1.719.289.6535
Email: sandeep.ghosh@trane.com
Website: www.trane.com


 

WD HMI.JPG

 

Motor Vibration.JPG

 

Hi,

We try to connect on "EXTERNAL" opc ua server (like injection press, data acquisition systems, ..) that generate custom notifiers.

The weakness on OPC UA toolkit is that it is a closed environment.

I am able to connect the toolkit on the notifier and catch the event with actual tool, but all data of the event (plots, values, ...) are unreachable (UA expert show them).

A very simple Python code is able to retrieve these data, but there are out of the labview environment, and as it has to create a thread on the notifier, I am unable to run such structure through the Python tools in LabView.

 

Some example:

daniel_rudaz_0-1637852870896.png

A shortcut of ENGEL structure

daniel_rudaz_1-1637853101303.png

Event registration need filtering, ENGEL

daniel_rudaz_2-1637853224845.png

Event registration need filtering, Kistler COMO Neo

daniel_rudaz_3-1637853400030.png

 

Data in each event, Kistler COMO Neo

 

Thanks in advance.

Download All

The aim here is be able able to communicate with several Ethercat slaves, and to be able to disconnect and reconnect some of them without affecting communication with orthers. 

 

 There is already a Refresh module vi which is refresh the global system state containing all slaves. The problem with this vi is as follow :

 

- Let's assume we are using 5 Ethercat slaves. If i disconnect 2 of them while program is running, it doesn't affect communication with others. Now if want to reconnect just one of the two i just disconnect (must be as the same place as before), if i use the vi refresh module, it will raise an error because labview won't find the last slave which is still not disconnected so the 4th slave reconnect won't be able to switch to operationnal mode.

 

- If we use the method node which enables to switch Ethercat slave state to operationnal mode, we will be able to switch the reconnected slave to operationnal mode and communicate again with him without an error. This method will raise an error when trying to sitch the 5th slave which is still not connected but you juste have to erase this error.

 

Now you can communicate with the 4 Ethercat slaves without error ( 3 + 1 reconnected).

Hi there,

 

several years ago I wrote an instrument control package for a set of specialized lab equipment controlled from a Linux PC via GPIB (NI PCI card). The need to frequently update the kernel driver turned out to be an issue for the daily work, so we switched over to a GPIB-ENET/100, which at that time came with a lightweight 32bit interface library libgpibenet.so with very little system dependency - so it was portable between different linux systems.

Recently, I was trying to upgrade the package to a more recent 64-bit linux variant, using up-to-date drivers from NI. Unfortunately, the current offering requires me to install some 30 rpm packages including kernel drivers (causing extra problems when the kernel requires signed modules). My GPIB application now crashes in nipalau.so if kernel modules are missing - which I don't need anyway! - or some startup scripts have not been executed. Even worse: the latest packages have sadly dropped support for the GPIB-ENET/100, probably due to too much maintenance overhead, and the GPIB-ENET/1000 is now the only available package that does not required kernel support.

 

However, purchasing a GPIB-ENET/1000 as an upgrade is no option if I cannot get rid of the runtime-dependencies on unneeded software.

 

Currently, my only choices are using an outdated linux system with the full package NI package version 2017, or an even older system with the original 32bit driver library.

 

Question: would it be possible to provide a 64bit-variant of the original GPIB-ENET Linux package to gain full advantage of the very low system requirements? I could even live without the fancy graphical configuration tools...