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.
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.
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.
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.
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)?
Nb: I currently have a working solution, in case anyone urgently needs this feature.
It would be extremely usefull and would save lots of frustration if the Veristand Sequence Editor (and all of verstiand for that matter) had undo and redo functions. It is surprizing that software of this caliber does not have such a basic function. I posted this in the main veristand forum and wanted to also make sure it made it into the Idea Exchange.
First time poster here so please excuse my ignorance if I am posting incorrectly.
I know NI supports CentOS and SUSE GNU/Linux distributions, but Debian distros are the most popular according to distrowatch. I would like NI to consider creating 488.2 driver support for Debian based distros. Specifically Linux Mint and Ubuntu. I have been using Ubuntu 14.04 LTS and recently switched to Linux Mint 18.3. Mint 18.3 works so well, I abandoned Windows 7 on my personal computer and only use Windows 7 at work (because I must). I can use NI USB devices on Mint (and Ubuntu) by installing the driver in a Windows 7 virtual machine and passing through the USB in VirtualBox. However this does not work for PCI cards. Drivers are a big roadblock to migrating our test equipment off Windows so I am hoping NI considers better GNU/Linux development in the future. Thank you.
The current Device Driver Installer dialog is not obvious to use. First of all you have to figure out which drivers that you need for your products and then you would probably prefer to remove other unnecessary drivers. However, this is a tedious process with a lot of dependencies.
I have seen many people just installing everything (with its drawbacks) to be safe, eventhough they only needed the NI RIO driver.
I'd like to see a more user friendly dialog where drivers are automatically selected.
My suggestion is that the user instead filters out the drivers on a product level like this:
Let say you choose Modular Instruments. Then next page could let you filter on what type of instrument you have; Scopes, FlexRIO, DMMs, RF, Switching etc...
One of the buttons in the bottom would be something like "Add more products?" so you could iterate this process and finally all needed drivers would be filtered out.
When using VeriStand with Source Control SW paths for Real-Time Sequences in the Stimulus Profile Editor need to be customized on every check out because it’s not possible to use a relative path for a Real-Time Sequence in a Stimulus Profile Editor.
Even if the Real-Time Sequence is in the same folder like a Stimulus Profile itself it isn’t found and the path has to be be adjusted.
So it would be awesome if it would be possible in VeriStand 2017 to use relative paths for a Real-Time Sequences in a Stimulus Profile Editor.
This is a bit of a feature request for the service request manager and/or as a stand-alone (my NI web) tool!
It is needed because the NI webpage makes it terribly hard to search for CAR#'s and a CAR# is only listed when solved, and only listed for the one version where it was resolved, making it nigh-on impossible to check lists of (new) CAR#s and get notified when they are resolved.
For example, I know this CAR exists, but I'm not sure if it has been resolved and the NI search just didn't find it, or if does not exist (user input error for example) or anything..
The tool should reside on "my NI" but it should be possible to export/share the list of monitored CAR's (so colleageus/companies can maintain one master list of company relevant CAR's).
The tool should connect/check against NI (ideally directly to a back-end database) and return any "public" information related to a CAR, such as "in progress", "known work-around", "details" etc. along with driver/software version where it was resolved (if any).
The tool should present a clear list (ideally with green checkmarks / red cross icons) showing the status of each CAR and maybe a synopsis/one-liner from the description to indicate what problem the number is for.
wish-list added feature: allow (on a per user basis) the user to add personal notes to a CAR (e.g. this affects projects x, y and z, once resolved, refactor those projects to remove performance intensive work-arounds!) or similar.
e-mail notification (optional/configurable) when the status changes on any of the tracked CAR's.
As far as how it relates to the service request manager, I would prefer a separate tool but that it also can link to the service request manager as outlined below:
A small but significant number of tickets either relate to, or create one or more CAR#'s (or at least mine seem to create a large amount of CAR's).
When a support tech adds / associates a ticket# with a CAR#, ideally this CAR# would be automatically added to the user's CAR Tracking list..
In addition it would be great if the back-end database tracked CAR#'s and offered up a list of these numbers in the webpage overview, for example next to the "status" column. Taking it a step further, it would be very nice if NI could make it simpler to check if a CAR has been resolved and if so, what version of LabVIEW it was resolved in/with. This information could be displayed in the same web page table, or a new page to itself. The "Status" column could then also be expanded with a green check-mark if (all) associated CAR#'s have been resolved..
Tracking CAR's and manually trying to search and check them off lists locally is labor intensive, especially since the web-page "search" does not do even a passable job when you enter CAR numbers.
Mapping in VeriStand 2011 consists of only text, but user could grasp the whole mapping if the number of connections is increasing. So, visualized mapping tool like dSPACE ConfigurationDesk as below image must be good user interface for users.
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:
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.
In LabVIEW, we have a lot of options for saving our projects as seen below:
In VeriStand, currently, you only have the option for a normal save (as shown below). I think it would be nice to have a "Save As" for saving a copy of the project and, if possible, a "Save for Previous Version".
[Edited on 8/28/2014 by moderator Diego Carvajal (dcarvaja)] [Image included in original post as requested] To help debug medium and large real-time test sequences, it would be very useful if there was a sequence step that allowed the user to specify a console message.
Much like the Print Debug String VI helps debug issues when building custom devices, this step would allow the developer to insert specific console flags and see what part of his/her real-time sequence is executing.