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.
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.
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.
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.
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.
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 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.
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.
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 😉
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.
Many folks have huge trouble with building extra packages for the cRIOs (that are either missing or outdated), not to mention reproducible deployment and configuration management.
In industrial environments, we need a very high degree of customizability and reproducability, which the current nilrt distro just cannot provide. Setting up such an environment from scratch is a huge work for users, which usually aren't Linux embedded expert.
Therefore I'd suggest an fully automatized deployment of development environments, which are also easily customizable for the user. Major keypoints are:
a) development environment setup:
* container-based solution that can put together an environment automatically, using well-proven standard technology (eg. docker, ansible, ...)
* executable documentation: use declarative approaches, that are easy to understand and allow automatic documentation (eg. for verification / validation)
* use a recent, well-maintained standard distro (inside the container), and use off-the-shelf standard tools where possible
* fully tracable source control via git
* easily customizable: the user can fork off his own configuration from the appropriate upstream release, customize to his needs and later rebase to newer upstream releases if wanted
* automatic setup of package mirrors, binary repositories, product specific local deployment and HIL environments, etc.
b) target build environment:
* highly reproducable - even after very long time (eg. also allows automatic source code mirrors, etc)
* executable documentation - the configuration can be easily understood and used for generating documentation
* based on a Linux embedded experts community
* supports building for several (including customer-specific) target platforms
* supports easy configuration / customization of installed packages, as well as features selection and tuning of individual packages
* supports easily adding own software
* supports maintaining customized system configuration with image building
* fully tracable source control via git
--> the natural choice is using PTXDist (fast, reliable, reproducable, excellent expert community)
I'd estimate about 6 man-month (for a lone developer) for the initial stable release of the core system, plus another 6 mm for additional tasks like user documentation, examples, target specific configurations, etc.
Costs: about 200k $ (including extra buffer)
Equals sales price of about 25..30 avg. cRIO units. (RIO break even likely at about 50 units).