I was asked to post this here instead of in the VLM forum:
Every time there is a new update of LabVIEW we typically hunt down the installation disks from ni.com as soon as they are available, and start the process of making volume license installers...(Or, if the update seems less exciting, we wait patiently for the shipped DVDs).
I wish it the whole provcess could be made smoother. Based on the volume license installers we have, the VLM could simply subscribe to newer versions.
When 2014 comes out, the package would automatically go out to all the VLMs out there, and new volume license installers would pop up on our local VLM as soon as the software was ready...OR, alternatively, the VLM could be hosted by NI instead (possibly supported by a local VLM for offline use), so that the process of creating new installers were really done by NI (or automatically by NI hardware that is) based on whatever setup we as VLM admins had chosen...and the source material from NI.
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 ;-)
Why don't we integrate PuTTY or some version of it into MAX? "Console out" is powerful troubleshooting tool for all NI RT targets and more because it tranfers vital information such as errors and IP address information regardless of whether you can find the device in MAX. It's especially useful for devices that don't have hardware dipswitches. It's a great tool, but is useless without a program like PuTTY. Hence, my suggestion remain to integrate PuTTY or some form of it into MAX.
Whenever I delete a signal (whether it's a custom device, user channel, calculated channel, etc.), VeriStand goes through to delete that signal from anything referencing it. This is often nice but at times undesirable because I may plan to add it back again at a later time with a new custom device with the same signal names, for example. The auto deletion of all references means that I'd need to go back to relink all of the broken references even if the missing signal gets restored later anyway. Some of my channels are used in 20+ places.
I'd like to see VeriStand prompt me or give me an option as to whether I want to delete all references. If I choose not to delete the reference, I understand that an error will show up later if I try to deploy or run. Thanks.
Provide an option to show more characters in the IO section (in quotes) of the Description field. Why not use the column separator as a way to expand the viewable characters, instead of just showing more white space?
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.
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!
the company I work for designs automotive infotainment products, and we used products from NI extensively in product validation an testing, including TestStand, Labview, DIAdem, FPGA, RT. etc...
In order to simplify license management, we chose to used the NI Volume License Manager (VLM). This provides centralized managment of licenses, including easy addition and removal of licenses, as well as license recovery from PCs no longer in service (broken or decomissioned by IT).
Since I am the technical lead for test system development, it falls to me to perform license capacity planning, request disconnected licenses, manage license groups, and all the other administrative things that go with license management. I am not, however, in the IT department, and since the VLM runs on a Virtual Machine inside the VM park, I always have to request license changes from our IT specialists.
I would very much appreciate it if there were a tool to remotely administer the VLM. This would allow the IT department to give me access to just the VLM to perform administrative duties there, sort of like the MMC in Microsoft Windows Server lets users administer remote servers.
Custom Device development does not have a very good design/develop/test work flow. To improve this, the custom device template tool needs to be rewritten so that it better incorporates design before creating the project/library/VIs.
In order to better incorporate design into the process, I envision a custom device template tool that is configuration based. From this tool, a developer would be able to specify the pages, actions, RTM, dynamic buttons, help topics, and glyphs. The developer should also be able to specify any options the custom device or a given page, RTM, or button may use such as multiple target support RT driver VIs, delete protection, rename protection, RTM/button dependencies and behavior, etc.
Once the developer finishes designing the custom device, the XML should be fully implemented and all the necessary VIs (actions, pages, RTMs, etc.) would be created in the library. This would greatly cut down on the overhead of creating new files from templates and modifying the XML over and over. It also encourages developers to do more design of the custom device up front instead of designing while they code.
For completeness, it would also be nice if the tool had the capability of linking into Requirements Gateway or something so they could do requirements tracking. I'm not sure how this would work, but it's something that maybe should be investigated.
The final aspect of this idea is that there is a need for better testing of custom device developments. I find it difficult to do good tests because my code is always tightly coupled to Item Properties or other things that require VeriStand references. I think this tool could also script some high level test code that would be able to run the pages or RT driver VIs outside of the VeriStand executable. In order to accomplish this, I think VIs could be developed that use the SysDef API to load system definition item information outside of the VeriStand executable so that the references could then be passed to the appropriate page or driver VI. I envision the test VIs are wrappers that wrap up the page, action, RTM, or driver being tested. In the case of pages, the custom device would need to be added to a SysDef and the Init VI would need to be executed. Some pages would also require the section or channel being added to the appropriate section or channel as well. If the configuration tool could script most of this work, I think it would be very helpful.
In most places around VeriStand, channels can be searched and filtered. However, in the channel logging pane of the simulus profile editor, one must manually dig down through the nodes and select channels independently which requires users to know exactly where the channels are in the structure. This is a pain for large systems (we have 4000 channels including CAN and 2000 channels excluding CAN). Thank you.
Currently licenses use the sort key word within a server's license file to specify the priorotized check out of similar software products ( a preference to check out DIAdem professional over DIAdem Advanced for example when a user has permissions for both). With concurrent licenses, right clicking on a software product from a client's License Manager application and selecting the Do not Allow License Request from the context menu as shown below will also bring about this functionality.
Without a set preference, sometimes two licenses are checked out, and this is a known issue:
DIAdem is double-checked out from VLA when several versions are licensed
Do Not Allow License Request for Concurrent License
Sort Keyword Within a Server's License File
My suggestion is that we create a way within VLM to modify the server's *.lic file (by changing sort key word's value) to reflect software check out priority. Currently this change can be made by manually modifying the sort value in the server's *.lic file. This works since the server's license doesn't need to be resigned after said modification. However, it would be nice if this change could be made through the VLM user interface and the *.lic file would be modified behind the scenes.
I have a system definition of over a thousand signals. I see that VeriStand 2011 has some search functionality built in. Is there a way to search not just ni the channel names but for the use of particular variables within calculated channels? For example, if I have UserVar1, I'd like to be able to find all occurrences of where UserVar1 is used. It could be an argument in a Calculated Channel, a mapping destination, an alias, etc. Is there a search tool that can accomplish this? Thanks.
I believe that we should create and API for NI I/O trace so that customers with automated production lines can automate a report logging response to a failure In the case where a production line experiences a UUT failure, these customers could programmatically rerun the specific test that failed last, open I/O trace, start recording, test communication with a device, stop recording, and log the results when a failure is experienced. This could even be used with G or CVI code module, not just TestStand. That way if say the VI experiences a particular error after running subVI "testme", the API could be usted to start recording, re-run "testme", stop recording, and to generate a report. I understand that certain users only use IO trace occasionally, so an API would not be necessary for them, however, with customers who may have to trouble shoot numerous UUTs off of a production line, this could be a great help.