Additional NI Software Idea Exchange

The new compactRIOs come with a very useful USB-ethernet interface. I would like to access this on systems without the full driver set for low power hosts where we don't want to fill the system with a full driver install.

For example, I have a surface go which would be great if I can just plug it in to access the web interface for debugging.

It's not just me either: https://forums.ni.com/t5/Real-Time-Measurement-and/How-to-include-the-usb-lan-driver-with-an-installer/td-p/3306592

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

We request "Disable Licensing Wizard" function.

This request from my customer.

The customer is managing a bunch of software licenses with Flexnet.

If the client user try to use some software when there are no available licenses, only NI software pops up the licensing wizard.

On the wizard, there is "Evaluation" button and once the client user mistakenly click the button, the software launches as a evaluation for around month and the Flexnet cannot detect the evaluation software, the customer cannot count the number of clients who is using the software.

If there is "disable licensing wizard" function, the issue never happens. 

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

First time poster here so please excuse my ignorance if I am posting incorrectly.

I know NI supports CentOS and SUSE GNU/Linux distributions, but Debian distros are the most popular according to distrowatch.  I would like NI to consider creating 488.2 driver support for Debian based distros.  Specifically Linux Mint and Ubuntu.  I have been using Ubuntu 14.04 LTS and recently switched to Linux Mint 18.3.  Mint 18.3 works so well, I abandoned Windows 7 on my personal computer and only use Windows 7 at work (because I must).  I can use NI USB devices on Mint (and Ubuntu) by installing the driver in a Windows 7 virtual machine and passing through the USB in VirtualBox.  However this does not work for PCI cards.  Drivers are a big roadblock to migrating our test equipment off Windows so I am hoping NI considers better GNU/Linux development in the future.  Thank you.

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.

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

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.

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.

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.