We should be able to filter the Packages displayed by Feed. This would allow users to focus on their internal feeds and find packages quicker. Particularly when basic LabVIEW\TestStand shows 90+ packages (300+ with hidden shown), the drowns out the internal packages. This would allow for more categorization than the Maintainer and limited Categories (improvement idea) afford us currently.
How nice it would be if my NIPM feed could point to GitHub-hosted packages! This way, I don't need to maintain my own file server. I created a custom feed to try it out; this is what my Packages.gz contains:
Description: Provides support for the NI Scan Engine and EtherCAT custom device for NI VeriStand 2018.
DisplayName: NI Scan Engine and EtherCAT for VeriStand 2018
Maintainer: National Instruments <email@example.com>
Alas, although NIPM accepted the feed, it did not allow the package to be downloaded ("Redirection to another URL is forbidden"):
It turns out that the nice URL above actually redirects to an Amazon cloud storage location, and the final URL is like
Could the restriction on redirections be lifted somehow? Perhaps there could be an optional property in the feed to specify that a particular Filename is allowed to redirect elsewhere. Perhaps the feed creator can nominate one or more "whitelisted" domains for a particular Filename's redirection.
It would be helpful to be able to define additional Categories/Sections for NI Packages. This would help users quickly narrow down searches to find packages. This is needed since there is not a way to filter the packages by feed in NI Package Manager.
can NIPM separate the download and install as 2 separate processes? for instance, download (or queued for download, with scheduled to avoid congestion) into local storage, and install (or scheduled for install, normally after work hours once download is completed) from storage once download is finished. and while at it, allow a local PC to be the repository (that can be set to automatically update itself) and all deployment package can be pointed to download from that storage instead.
an auto-resuming download manager would be nice too...
I am currently facing difficulties upgrading/downloading LV2019 using NIPM and have to break down the 'steak' into 'flakes' due to slow and unstable connection, because the NIPM restarted every time it encounters a problem.
With the NI Package Manager we can now create packages for a variety of purposes (libraries, tools, APIs, stand-alone applications, plugins...).
However, there's currently a limitation with the dependencies. For example, if you want to create a .nipkg file that relies on the LabVIEW Runtime Engine that successfully deploys to any PC, you have 2 choices:
- manually install the LV RTE from NIPM on the deployment machine
- add the LV RTE (and your app) to a custom feed, and manually add that feed to NIPM on the deployment machine.
In any case, there's a manual operation for a user. This is because NIPM does not automatically search for NI feeds when installing a custom package (it only looks into already installed feeds).
There should be (at least) an option like this in NIPM (ideally it should be the default behavior)!
This way, NIPM would behave pretty much like any other package manager (think Linux or mobile platforms)...
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.
This *may* be a niche request, I think a few people may find this useful...
Basically, I would like the "Browse Products" section of the NI Package Manager, but with the ability to run the application from that same window and allow it to display MY built applications. I essentially want a singular place to easily manage and navigate the stand-alone VIs I have deployed onto a machine that my students can access. Oh! And allow non-admin users to access this.
What I envision is a package manager-like program (I'll refer to it as the Application Manager) where an end user can subscribe to feeds of packages (as is currently the case in NIPM). When this Application Manager is opened, it allows you to 1) view the programs already installed on your machine via this feed and provides a link OPEN this file (or just go to the folder where it is stored) on your PC, 2) install programs from the feed(s) you subscribe to and 3) make any updates to programs from the feed that have an update.
For example, a student opens up this Application Manager that has been subscribed to the "Mech Engineering" feed, which contains the package for temperature, voltage and distance sensing VIs. The "browse products" window displays these three VIs, and the user can open each of these VIs from this window. If the Temperature program has an update, some indicator will show that, and they can install the update and then open the updated version.
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.
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.
I/O Trace is extremely useful when debugging system-level text-based applications. Error handling for systems involving multiple drivers + software packages (RF toolkits, for example) is very difficult. After recognizing there was an error, we still have to determine which device threw the error and then query the appropriate driver/toolkit with the correct handle to determine what the error was. NI I/O Trace is a great way to quickly determine which device threw an error and at which function call. Unfortunately, the error reporting returned by I/OTrace is pretty limited. For example, consider the I/O Trace shown below of an application synchronizing two waveform generators. A property is not configured correctly for one of the generators. I/O Trace clearly indicates there is an error, however the exact cause of the error is difficult to discern from the message:
The actual error message is: “The Sample Rate property can not be configured if OSP Enabled is VI_TRUE. “. It would be great if I/O trace could provide the entire error description. Compare this to the LabVIEW error handler:
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.
Ability to request to be (automatically) notified via email of patches and updates to a particular software or driver package. NI Package Manager will only give me updates if I am online and for software I have installed.
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!
Versioning is often a fairly important matter when it comes to long/large projects. When a new FPGA bitfile is generated in LabVIEW, there's a possibility to change its version (in the build specification). As a result, a parse of the .lvbitx file as text file can be used to decypher the aforementioned version (it's following the <BuildSpecVersion> tag).
Though, there's no simple way (aside of making a Custom Device or modifying the accepted tags in the xsd file)) to get this information in Veristand after importing a new FPGA personality. The version may be important, but more information about the bitfile might need to be made public in this window :
In fact, there are a bunch of information that are readable in VeriStand about the model imported (name, version...). Once more, the FPGA needs the same feature ;-)
Provide the ability to filter log entries by device descriptor, similar to the “View Only this Process” and “View only this Thread” options. The new feature could be implemented with another option in the pop-up menu: “View only this Device”.
Or better yet, a way to selectively pick which of several devices to view. For instance, if 5 devices were present in the log (UD0 - UD4), then I could select to only view UD1 and UD3.