Additional NI Software Idea Exchange

To be specific, I am talking about the link below from the 3.x NI License Manager (this is on a VM I use for LV 8.5 development)

It had the nice feature of filling in your computer's information and all the products you are activating as part of the link.  Unfortunately, NI's website no longer supports this pre-filling - using this link in 3.x now just redirects you to the normal result of typing in ni.com/activate into your browser.

My typical workflow with this screen would be to enter my real serial number into the preceding dialog, use this dialog to get the activation link, go back to the preceding dialog and enter in a fake serial number, press next twice to get the activation codes entry dialog, and copy the activation codes into the dialog.

In NI License Manager 4.x, you either need to use web activation (which saves your serial number everywhere) or enter codes manually, requiring a trip to http://ni.com/activate for every product that needs activation (and trying to figure out how the name of an application in License Manager - say "Vision Development Module Runtime" - matches against the website's entries - say "Vision Development Module", "Vision Development Module (FRC)", "Vision Development Module Runtime (FRC)", and "Vision Runtime") and a bunch of e-mail spam if you choose to get a copy of the activation e-mailed to you.  Note that activating LabVIEW alone requires two of these trips (or at least used to), as the Professional Development system and the Application Builder activate separately.

As far as why I often don't want to use the built-in Web Activation, it stores your serial number on the computer.  This leads most (I think LabVIEW 2017 is an exception) versions of LabVIEW to display your serial number in their splash screens and about boxes - this could be visible in a public setting or at a customer site.  It also stores the serial number even after you deactivate it, so if you temporarily activate a tester while you are doing its initial debug, your serial number will be stored for your customer to reactivate (and possibly distribute).

I labelled this as MAX, as there is no License Manager Idea Exchange - in a way this applies to all NI products.

Hi

I would like to be able to simulate XNET devices in MAX (with minimal support). I would not expect these devices to simulate data on the bus. They could help us developers catch some bugs before we integrate with the actual HW.

It would be easier for a developer to be able to create configuration files, databases and test them out without connecting to the actual HW. In most cases, the HW is on a rig which is in use, or the HW is not yet delivered for the rig. We would not need any data on the bus in these cases.

I have been struggling over the past few months, to be able to define databases or use databases and test my configuration UI without the actual HW. And I have faced lot of error with creating multiple sessions, opening sessions after the HW is reserved etc.

I would hope that such errors could be tested and fixed using a simulated device, where the actual messages on the bus are not important.

It would be very good if the DSC llb will be reentrant (vi property -> shared clone reentrant execution).

It's no problem if I work with 50 citadel databases in parallel from executable files. But if I do it from one exe (with reentrant VI that work with citadel) then it works very slowly and very often with critical memory errors... And 50 exe files is not a good solution any way.

Increase the size of the "handles" used to resize the display panes in MAX so that it can be done on a touchscreen interface. It is impossible to "grab" the border between two panes on the MAX window using touch to expand a pane. It would also be very nice if MAX remembered its window/panes positions between sessions.

National Instruments has terabytes of software. And, new software is being released everyday!

It is becoming increasingly difficult to find specific versions of NI Software. Occasionally marketing will change the name of a package, or a specific software package becomes bundled into a much larger install file.

By having a BitTorrent option it would greatly speed up the download process of NI software.

Also when multiple packages are needed such as Real-Time, and FPGA it is simple to create a list of downloads that are linked by a BitTorrent Seed link. 

When attempting to create links to the NI website downloads there is are guarantee that the link will work years from now. Where with the BitTorrent a long as there are peers available the BitTorrent link is 'mostly' functional. 

By placing NI software on a BitTorrent downloads will be faster. 

This same concept could be extend to additional tools such as the JKI Package manager. 

Of course BitTorrent would not replace the traditional website or FTP downloads from NI since many larger companies block P2P transfers. With that in mind many companies allow exception to this rule with a legitimate business need. 

This seems to be a sensible option. It could be part of the the licensing agreement with colleges. A slight educational discount in exchange for hosting NI software on there BitTorrent services along with their Linux Distros.(i don't know if that would be an option)

As a contractor I can easily spend a day or more just downloading NI software with each client I work with. And, then (on rare occasion) I run into the hassle of downloading the wrong version or language only to repeat the download. 

The NI website does a lousy job identifying (grouping) packages by release date to ensure that all downloads are in lock step with each other.

Having BitTorrent Seed links would not help that, but it would greatly simplify communications to others on a team what was downloaded.

The image below is an example of what adding a BitTorrent link would look like.

It would also be nice if NI also added a SHA checksum along with the MD5 checksum. The MD5 has been proven to have security weakness and it is possible to fake a MD5 checksum. This would be a nice security check if the software was going to be downloaded form the BitTorrent eco system. 

Heck, why not have NI create their own BitTorrent Client that would only list and optimize NI software for downloads?

It could be a mixture of FTP/website/and BitTorrent file download options. 

Am I the only one that has experienced the pain of repeatedly downloading and managing software from NI?

The VeriStand System Definition API allows you to edit a definition file. While it is mostly used as an offline API, it is also often used in custom devices code, notably thanks to the Item Reference to Pointer function that gives your access to the SystemStorage namespace, an internal representation of the SystemDefinitionAPI.

Unfortunately, there's a hiccup with that. If you want to edit existing nodes in your system definition, it works. If you want to add/remove nodes or sections (say, automatically add an alarm when you add a given custom device channel), the underlying API calls will work but you can't see the modifications in the System Definition tree: my alarm won't show up in the tree although it exists in memory. You'll have to manually save and reopen the *.nivssdf file for that. This can't be a decent workaround for end users.

Would NI R&D be nice enough to provide us with a public function that refreshes the tree (or parts of it if we feed the node reference)?

--Eric

Nb: I currently have a working solution, in case anyone urgently needs this feature.

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. 

Currently there are caveats when upgrading system definition in VeriStand. It would be helpful to have a tool to help VeriStand developers check and see what type of issue they might run into when upgrading a system definition. Specifically an issue that I've encountered was that my pathing for the upgrade was correct but the mapping of the items turned out wrong. An example of something a tool could help out with is a test for the Model item map. That test would verify that all model maps refer to the fully-qualified path to the item. 

Currently when we try to look into the Model's Parameters we don't really know the difference between he Path and Expression indicators. A tip strip would be helpful in figuring out the correct paths. 

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.

Hi,

We are using the VeriStand SystemDefinition .NET API to automatically generate VeriStand .sdf files. However the SystemDefinitionAPI only seems to work when accessed in 32Bit applications (in our case Matlab/Simulink). As in the future more and more applications will only be available as 64Bit versions, this very convenient VeriStand feature will no longer be usable for us. Thus I strongly suggest for to provide also a 64Bit compatible version of the SystemDefinition .NET API. Interestingly, other VeriStand .NET APIs (like the Execution API) seem to work well even when accessed from 64Bit applications.

Best regards,

Thomas Zettl