Additional NI Software Idea Exchange

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

Hi, a few suggestions related to software deployment.

1) Separate out the Volume License Installer from the Volume License Manager. These should be two separate programs. Having the VLI separate allows other admins in other departments to create VL installer files for their own area without having to have an agreement file for the volume license server (which would be running on another machine and one which the other admins may not have access to). 

2) Have the NI License Manager client require elevated (i.e. admin) privileges to change the settings. This will prevent unauthorised users from changing the network license server which affects all users of the system. This is necessary in a classroom environment.

3) Have as an option whether things like the Package Manager/Registration wizard/Update service etc get installed.

  • System Configuration API

NOTE: My role is only IT sysadmin support at my university. I'm not familiar with NI's individual products. I help run the servers supporting the NI-VLM and have previously helped package LabVIEW for automated deployment.

 

I know the NI-VLM tracks usage of the individual "paid" software products like LabVIEW/Multisim that are part of software site licenses. I'm trying to determine if the NI-VLM can tell me if a user has used *any* part the NI solution on a client computer--even if it is a "free" product included with it such DAQmx, MAX, ELVISmx Instrument Launcher, etc. I'm trying to determine NI software usage as a whole to gauge whether or not the usage is enough to justify installing this large software suite into specific locations on our campus, to stop installing it into lesser or non-used locations, move the installations elsewhere, etc.

 

thanks!
Scott

 

  • System Configuration API
0 Kudos

強制ドットは意図的でないデータ型式の変換を警告するが、データ形式が同じでもタイプ定義の有り無しが異なると強制ドットが付く。

これは疑似エラーであり、データ形式が異なる真性エラーをマスクしてしまい、強制ドット警告の品質を劣化させている。

従って単にタイプ定義有り無しの違いに対しては強制ドットの色をオレンジ色にするなどしてエラーレベルを落とす方が良いと思います。

 

また、ブロックダイアグラム中の強制ドットの検索方法が提案されているが、強制ドットは常にバックグラウンドで検索して欲しい。ちなみにプログラム実行に支障が有るときは実行指示のボタンの形が変わり実行出来なくなるが、強制ドットなどがある場合にはボタンの色が変わり、右クリックなどで警告の一覧表が出て、それぞれを確認できる仕組みが欲しい。

特にタイプ定義を使っているとタイプ定義の修正の結果、意図しない場所で、新たな警告が誕生する可能性があり、毎回意図的に強制ドットの探索を掛けるのは非常に煩わしく、失念する要因となる。前記の機能があれば、修正直後に副作用を確認できる。

  • System Configuration API

As of today, the newest version of the NI Volume License Manager 3.1.2 supports following OS; Windows 10, Windows 8.1, Windows 7, Windows Server 2012 R2 64-​bit, Windows Server 2008 R2 64-​bit.

It would be more convenient if it supports Windows Server 2016 or Windows Server 2019.

 

  • System Configuration API
0 Kudos

Hi,

 

For a reason I don't know, NI Softmotion team remove the function "write position setpoint" to all 951x axis. I'm using four (4) 9514 axis right now that all need to use this function at sometime in my code.

 

This function is really useful when design a motion tracking system and also for PID tuning to check step response.

 

I can't upgrade to LabVIEW 2018 for this reason without non-desired work-around.

 

Please work on reenabling this fonction on all 951x axis.

  • System Configuration API
0 Kudos

Hi there,

 

as my volume license manager is not able to handle more than ~850 registered computers, I need the creation date or register date of a computer to run a proper inventory every month (no usage AND present also last month -> deletion of computer).

 

I need this function urgently to have a stable service and license allocation.

 

BR
Lennart

  • System Configuration API

Right now through SystemLink when you go to the server to approve a new system, you get a listing with the Minion IDs of all the systems waiting for approval.  The problem is that the minion ID is made up of the computer type, serial number and MAC address.  As a production line manager person, I don't know the hardware serial numbers of computers, or MAC addresses of systems.  Yes they are great unique identifiers, but it's kinda like having a conversation about people by only using their social security numbers (instead of calling them by Jane, John, Marry or Harry). 

What it comes down to is I've got a list of systems that I don't know what they are, and to be able to make a reasonable decision about the security of my process I need to do a large amount of research to decide whether it is an appropriate system.  I wish the list included the system HostName too.  With that I could decide quicker and easier if it was a valid system to approve.

 

  • System Configuration API
0 Kudos

Systemlink seems unaware of software changes deployed to a Managed System outside of the SystemLink Systems Manager.  If I install a software package using Systems Manager to an RT client, then install something else on the same client directly from LabView, Systems Manager will continue to show the original package as the Installed Software.  Ideally the SystemLink client on the RT target should recognize the difference and report to Systems Manager that an unknown package is installed.  Additionally, Systems Manager should have a Reinstall option on its installed software tab.  The current procedure is to uninstall the currently installed version, then install it from the Available software tab.

  • System Configuration API

Many folks have huge trouble with building extra packages for the cRIOs (that are either missing or outdated), not to mention reproducible deployment and configuration management.

 

In industrial environments, we need a very high degree of customizability and reproducability, which the current nilrt distro just cannot provide. Setting up such an environment from scratch is a huge work for users, which usually aren't Linux embedded expert.

 

Therefore I'd suggest an fully automatized deployment of development environments, which are also easily customizable for the user. Major keypoints are:

 

a) development environment setup:

* container-based solution that can put together an environment automatically, using well-proven standard technology (eg. docker, ansible, ...)

* executable documentation: use declarative approaches, that are easy to understand and allow automatic documentation (eg. for verification / validation)

* use a recent, well-maintained standard distro (inside the container), and use off-the-shelf standard tools where possible

* fully tracable source control via git

* easily customizable: the user can fork off his own configuration from the appropriate upstream release, customize to his needs and later rebase to newer upstream releases if wanted

* automatic setup of package mirrors, binary repositories, product specific local deployment and HIL environments, etc.

b) target build environment:

* highly reproducable - even after very long time (eg. also allows automatic source code mirrors, etc)

* executable documentation - the configuration can be easily understood and used for generating documentation

* based on a Linux embedded experts community

* supports building for several (including customer-specific) target platforms

* supports easy configuration / customization of installed packages, as well as features selection and tuning of individual packages

* supports easily adding own software

* supports maintaining customized system configuration with image building

* fully tracable source control via git

--> the natural choice is using PTXDist (fast, reliable, reproducable, excellent expert community)

 

I'd estimate about 6 man-month (for a lone developer) for the initial stable release of the core system, plus another 6 mm for additional tasks like user documentation, examples, target specific configurations, etc.

 

Costs: about 200k $ (including extra buffer)

Equals sales price of about 25..30 avg. cRIO units. (RIO break even likely at about 50 units).

 

  • System Configuration API

Write clean IIO drivers for the NI DAQ cards and bringt them to mainline.

 

Pro:

* full Linux-support via standard APIs out of the box (without extra sw installations)

* very high quality by community driven maintenance

* directly supporting for standard applications by standard APIs, w/o any hw-specific modifications

* easy integration in / customization for complex scenarios

 

* increased sales volume by opening a completely new market (Linux/FOSS world)

 

Costs:

* avg. 4..8 man-weeks per device type

* usually less than 1kLOC per device

 

For example, the - currently completely unsupported NI-600x - can be easily integrated into IIO as well as GPIO and PWM subsystems (driver can provide several interfaces in parallel, so users can pick the appropriate one for their applications).

 

NI could open up a new market - the Linux/FOSS world - which is currently completely unavailable to them right no, due to lack of usable drivers.

  • System Configuration API

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

  • System Configuration API
0 Kudos

I frequently switch between developing at my desk, and debugging in the lab. After I switch work areas, I sometimes find that LabVIEW is still open on the other machine (usually just the annoying splash screen for LabVIEW projects). It would be nice if the NI License Manager allowed a force-check-in of remote Network Licenses so I could reclaim my seat without walking back to close an application.

  • System Configuration API
0 Kudos

We have VLA Named-User licenses hosted from our NI VLM server. If there are no Network License seats available, LabVIEW should notify the user. Instead, it opens the Activation Wizard and starts prompting for serial numbers like a standard non-VLA install. It's not intuitive, especially to new LabVIEW users, or new members of a VLA.

  • System Configuration API

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. 

 

  • System Configuration API
0 Kudos

National Instruments has terabytes of software. And, new software is being released everyday!

 

It is becoming increasingly difficult to find specific versions of NI Software. Occasionally marketing will change the name of a package, or a specific software package becomes bundled into a much larger install file.

 

 

By having a BitTorrent option it would greatly speed up the download process of NI software.

Also when multiple packages are needed such as Real-Time, and FPGA it is simple to create a list of downloads that are linked by a BitTorrent Seed link. 

When attempting to create links to the NI website downloads there is are guarantee that the link will work years from now. Where with the BitTorrent a long as there are peers available the BitTorrent link is 'mostly' functional. 

 

By placing NI software on a BitTorrent downloads will be faster. 

 

This same concept could be extend to additional tools such as the JKI Package manager. 

Of course BitTorrent would not replace the traditional website or FTP downloads from NI since many larger companies block P2P transfers. With that in mind many companies allow exception to this rule with a legitimate business need. 

 

This seems to be a sensible option. It could be part of the the licensing agreement with colleges. A slight educational discount in exchange for hosting NI software on there BitTorrent services along with their Linux Distros.(i don't know if that would be an option)

 

As a contractor I can easily spend a day or more just downloading NI software with each client I work with. And, then (on rare occasion) I run into the hassle of downloading the wrong version or language only to repeat the download. 

The NI website does a lousy job identifying (grouping) packages by release date to ensure that all downloads are in lock step with each other.

Having BitTorrent Seed links would not help that, but it would greatly simplify communications to others on a team what was downloaded.

 

The image below is an example of what adding a BitTorrent link would look like.

 

It would also be nice if NI also added a SHA checksum along with the MD5 checksum. The MD5 has been proven to have security weakness and it is possible to fake a MD5 checksum. This would be a nice security check if the software was going to be downloaded form the BitTorrent eco system. 

 

Heck, why not have NI create their own BitTorrent Client that would only list and optimize NI software for downloads?

It could be a mixture of FTP/website/and BitTorrent file download options. 

 

 

BitTorrent Option.png

Am I the only one that has experienced the pain of repeatedly downloading and managing software from NI?

  • System Configuration API

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.

  • System Configuration API

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

 

  • System Configuration API
0 Kudos

Add an unattended installer option button to all (practical) installers so that no single dialog prevent the installer from continuing.  It will accept all default options and reboot if necessary without intervention.  I believe that this option is sometimes available if launched from a command line, however he button option would be a nice alternative.

  • System Configuration API
0 Kudos

Hi Everybody,
I'm a student, and now i'm interning at a company that wants me to develop an industrial vision system.
I would like to ask you if i can use NI vision builder for automated inspection (VBAI) with the Labwindows/ CVI
If so, how? and what are the difficulties that may affect me?
THANK YOU for your help !
Best regards,

  • System Configuration API

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.

  • System Configuration API