Additional NI Software Idea Exchange

It would be good if MAX was able to report the serial number of the PXI chassis and PXI controller, if they are applicable.

Provide an option to show more characters in the IO section (in quotes) of the Description field.  Why not use the column separator as a way to expand the viewable characters, instead of just showing more white space?

Posted this in Data Acquisition Ideas as well, but it seems like it would be implemented with something like MAX, so...

When dealing with various remotely deployed cRIO hardware configurations, it may be impossible to keep a sample configuration of every type of system we ever sell.  Unfortunately, if upgrades or revisions are made to the base code in our system, remotely deploying to our customers becomes impossible unless we have their exact configuration on-hand for the programmers to compile.  Remote connection to the hardware for this type of operation is also not typically possible.

To be able to simulate or emulate a full cRIO system (processor & hardware modules), then compile the RT code for deployment on that system as if it is physically connected to our development system would be ideal.  This would allow images to be created, which can be sent to customers for local deployment at their facility.  Dramatic decrease in "hardware library" requirements on the development end, reduction in "on-site upgrade" service trip costs to the customers.  Plus, easier for OEMs like me to justify the move away from PLC types of hardware and towards cRIO, once you take away some of the potentially nightmarish continued support and update issues involved with basing systems on cRIO platforms.

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.

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

Please change the NI uninstaller program in Windows to be resizable. You have a tiny list box to list all the MANY little applications that NI installs. It's so small, though, that I have to constantly scroll to read the names. Vertical scrolling only would be tolerable. It's the horizontal scrolling, too, that is most annoying.

Would like XNET session to filter source addresses at the session level based on source address(es) specified in the dbc file.  Currently only way to filter is apparently to specify each individual frame to be filtered.  See screenshots of sample dbc and code required to filter multiple frames below.

Hello,

Many times, I find myself wanting to compare different I/O traces side-by-side, but I can only have one instance of I/O Trace in memory and hense can only view one capture at a time.  Would it be possible to view two different captures within one instance of I/O Trace?  I believe a lot of people would appreciate either a split screen option or the ability to open another instance of the I/O Trace application in memory.

Cheers!

Shawn S.

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

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.