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!
Is there any development in improving the pallet of Calculated Channels? The new stimulus profile editor has a very large list of mathematical and logical functions while the Calculated Channels pallet is very limited. Thanks.
Also, it'd be great if the conditional could be a bit more flexible (e.g., allow multiple conditions) or be changed to a switch/case type function.
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.
The built in CAN information channels for timestamp and time difference are useful. However, to detect a dead CAN network, I'd really like to know the time since a message was last received. The time difference doesn't work because it waits for a next frame before computing the time difference. If I have a 10 Hz frame that is not coming in, it will just display 0.10 s even if no new frames come in. I'd like to have a time since the last message so I can detect if the message is no longer coming in. I was thinking of doing a difference between system time and the most recent receive time, but system time is relative to the start of VeriStand while the CAN receive time seems to refer to real world time. I hear that real world time will be available in VeriStand 2012, so we can more easily do this checking in a calculated channel, but it'd be great to have this feature as a CAN information channel. Thank you.
To raise the visibility of the increasing number of NI VeriStand add-ons available on the website, I suggest we put a button on the Getting Started Window of NI VeriStand that takes the user to www.ni.com/veristand/addons.htm
This doesn't have to be a button on the window, it could be in the menu.. under file, tools or help.
You can not choose multiple Workspace objects to move in VS 2011, so it is time-consuming to organize the Workspace. I hope that 1. you can choose and move multiple objects at the same time 2. you can align object by alignment tool like below images.
Currently, In VeriStand, you can refresh Models if you made a change or added/removed channels. I would like to be able to refresh custom devices so I do not have to completely remove it and add it again when I add or remove a channel.
I was thinking for very large systems that use the same channel configuration for multiple channels on the system configuration can be very tedious. A work around for this is the API to build a system definition file but for those customer's with limited or no LabVIEW or .NET experience this isn't valid.
Since we can test the IO channels in MAX by creating tasks for all of our hardware I would like to add the ability to pull the configuration information from a task we've created in MAX and apply them to our channels in VeriStand. So in stead of setting MIN, MAX, input configuration, shunt resistor location and value for 100 channels I can configure it in one location (MAX) and apply the settings to all my Current Channels.
The other issue is if the channel doesn't support all the configurations from each page then we need to contact NI support to add functionality. Recently I worked with a LVDT sensor for a SCXI chassis. This allows customers to have an instant workaround rather than having for NI to allocate resources to update the page.
By adding MAX task to act as the template for our channels we can edit the parameters for all channels of the same setup from one location (MAX) vs each individual page. This also allows you to test individual channels instantly in MAX to make sure the configuration is valid without resolving other errors across the whole system definition.
Again this is more for deployments where they have 100s of channel similarly configured where configurating each channel is tedious but they are not unique.
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.
I'd like a way to select/deselect dependencies that get sent to the target upon deployment. I understand that all dependencies are necessary for a project to run. However, I deploy one system definition to many targets, and often there are very minor changes that don't need a transfer of all the dependencies which takes time. Also, the fact that the default is to transfer all dependencies means I need to keep every computer updated and sync'd or else a deployment could fail. I'd like the ability to manage which dependencies to transfer and potentially overwrite. Thank you.
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.
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.
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.