Additional NI Software Idea Exchange

Problem: If you import a model dll you did not create on your own you have no information how to use the model and its channels. Neither the description nor any unit string comes with the imported model.

Please rework the VeriStand model generation tool that the description property of the VI and the channels are transferred to the model dll.

Also please make sure the default descriptions are loaded into VeriStand when importing the model.

Getting the default unit might be more complicated as there is no unit property for LabVIEW controls and indicators. I am sure you have a smart solution for this 🙂

I appriciate!

I tried posting this in "Additional NI Software Idea Exchange", but could not find the "Post New Idea" button.

I have just started using the LabVIEW Embedded for ARM evaluation kit and it looks like an interesting product for seasoned LabVIEW programmers. I've already extensively used LabVIEW, LabVIEW Real-Time and LabVIEW FPGA. Once I'm familiar with LabVIEW Microcontroller, I'll be able to target PCs, CompactRIO Real-Time Controllers, FPGAs and 32-bit microcontrollers. That's quiet a range of target platforms ranging from powerful to deterministic to low-cost.

One of the problems I see is that the number of microcontrollers that are available as part of an out-of-box experience is limited to two (OK, strictly speaking 3). Also, these processors (ARM7 and ARM Cortex M3) are not the most recent and powerful industry offerings. For example, the more recent ARM9 is 4 times more powerful and the ARM11 is 15 times more powerful!

My idea is to introduce an additional out-of-box microcontroller in the LabVIEW Microcontroller range. This should be at least an ARM9 and preferably ARM11. An appropriate high-featured evaluation board should be identified (analog in, analog out, several I2C, UARTS, SPI/SSP, USB, ethernet, display, etc). I think such a move will increase the popularity and usefulness of LabVIEW Microcontroller several fold.

Expanding the Remote Systems category in MAX or launching the NI Network Browser only shows devices in the same subnet that the used host PC is in. However networked devices (LabVIEW Real-Time systems or Ethernet CompactDAQ chassis) are often located on different subnets.

• In order to keep the discovery time low, only one subnet should be selectable at any time.
• The currently selected subnet (default: local subnet as today) should be indicated:
  "Currently showing devices in the [local|[1...255]] subnet. Click here to change"
• Some area or button allows users to pick a different subnet and once the user populates the field, MAX or the NI Network Browser refreshes.

Hello,

I recently had a service request where a customer was unsure why 30 day evaluation licenses were not made available when using unmanaged concurrent name based licenses.  I explained that this was expected behavior.

Then I generated a license file, used a test machine as a server, and my work PC as a client.

Witihin NI License Manager on the client machine, the software package I checked out showed as 1 of 2 licenses checked out.

However, on the admin side, there was no notification of the number of checked out licenses.  The total was displayed as well as the Total Seats Granted.  However, the total seats granted is unmanaged, so this number stays at 0 even once a license is checked out to a client machine.  I believe that another column should be added on the server copy of Volume License Manager to display the number of licenses currently checked out as is displayed on the client (1 of 2 licenses checked out).

Server View While License is Checked Out and Server is Running

Client License Manager Screen Shot While unmanaged name based license of LabVIEW 2011 is Checked Out

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

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.