Currently when trying to see errors we need to enlarge the window, scroll through the items, and then take a screenshot of the dialog. This was encountered when trying to share my errors with support. We should make this easier through the proposed ability.
For security reasons, many customers using Volume License Manager to administer licenses to client machines do not authorize users to download and install anything from the web. Therefore, if a critical patch is released, the client machines are unable to download this unless it is distributed by the administrator. It would be useful for the VLM administrator to be able to configure the Update Service such that all Users can run the Update Service but the service has been configured to point to an internal network share rather than an internet location outside the firewall. This way, the administrator could make critical updates and patches available for the client machines and the clients can be notified and install them.
The only way to edit the order of VeriStand workspace screen pages once they're created is to edit the cryptic XML file where screen pages are referred to by numbers. I'd like to be able to reorder the screen pages from within the workspace. Thank you.
Benefit: Simplify the process and reduce errors when using FPGA personalities
Idea: Querry the user-generated FPGA diagram and automatically create the XML file. Additionally, have some kind of editor/viewer for the XML file that would present the information similar to how it is presented in the System Explorer but allow the user to edit certain values (or just make it editable in the system explorer). Some items would be read-only (items specific to the bitfile communication) and others would be editable (heirarchy, scaling, etc).
Ultimately, the process for using FPGA Personalities would be:
- create FPGA VI using NIVS interface/template
- select interface in "utility/view" or System Explorer (XML file automatically generated)
Editing the NI VeriStand Workspace is a very time-consuming job. Especially after arranging a huge number of controls and indicators it is a pain to drag and drop each object in order to move the whole arrangement to another place.
Improvement: If the user could mark multiple objects at one time he could move them all together. The selection could be done by holding the Shift or Ctrl key or just by framing them with a selection box.
In certain circumstances it would be helpful to see exactly what license file ties to each piece of activated software within NI License Manager. This would be an additional field in the right hand pane of License Manager as shown below.
I have many procedures that check for certain conditions before completing its intended function. If a precondition is not met, the procedure exits. It'd be nice to be able to pop up dialogs as necessary. Right now, in order to do so, I have to have the procedure call other alarms if I want any sort of feedback/popup which gets convoluted pretty quickly. Thanks.
Currently there is no specific upgrade path for VeriStand. This affects code reuse and portability when trying to keep up with the latest version. It's understandable that there are going to be limitations, but lack of documentation makes this task very difficult.
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.
* 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)
* 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.
If the License Manager is used to deactivate software, it will leave the prior serial key in the registry. On subsequent activations, the Activation Wizard will automatically populate the serial number field. I assume the same kind of thing will happen with .lic/.lc licenses.
I can see a valid use case for this, but in my scenario, I need to remove development licenses from productions and disallow users to reactivate the software without getting permission (the serial key) from me. Since these keys can be found in the registry, I can write a script to do this; however, it seems like a feature that License Manager should include.
PS: I know, I used the wrong idea label. We need more label flexibility to cover other smaller NI software!