Announcing VeriStand 2020 R6

[Darin_G]

The final minor release of VeriStand 2020 -- VeriStand 2020 R6 -- has shipped and is now publicly available.

Download: https://www.ni.com/en-us/support/downloads/software-products/download.veristand.html

Release notes: https://www.ni.com/en-us/support/documentation/release-notes/product.veristand.html

🚀 New Features in 2020 R6

Improvements to the VeriStand Editor

• Set the default appearance of channels on the screen. Click File » Preferences and select Screen to set the channel label location and cluster arrangement on initial drop.
• Cleaned up Alarm Controls. Configuration on Screens is now improved & more consistent with rest of the control set.
• Quickly open up the command line help located in our product documentation from the command line with VeriStand.exe /help
• The Legacy Stimulus Item in System Explorer has been removed from the product.
• VeriStand's custom TDMS file viewer utility has been removed from the product. DIAdem seamlessly launches instead.

Ballard ARINC 429 Custom Device

• Use Ballard ARINC 429 PXIe modules to talk to LRUs with VeriStand 2020/2021.
• This Linux-RT only Custom Device supports configuration file import/update, viewing of configuration in System Explorer to transmit/receive data or scripting of the settings via a LabVIEW API.
• Supports scheduled and acyclic labels, timestamps, trigger and disable signals.
• Download this custom device from GitHub.

Communication Bus Custom Device Template

• Need to support a communication bus that VeriStand doesn't yet support? We now have a better starting point for developing communication bus type custom devices utilizing LabVIEW 2020 Interfaces.
• Starting from this template from GitHub with a working knowledge of Custom Devices, the protocol and the hardware, we believe users can stand up new Communication Buses much more quickly then ever before, and lead to a more consistent User Experience when juggling multiple communication buses in a single system.

FPGA Add-on Custom Device

• FPGA Addon Custom Devices now support all FXP datatypes that are also supported by LabVIEW.
• You can access this custom device from GitHub.

NI-SWITCH Custom Device

• Use the G scripting API to modify a NI-SWITCH Custom Device. For more information, refer to Scripting Examples.lvproj in <Application Data>\LabVIEW 20xx\examples\NI VeriStand Custom Devices\Routing and Faulting.
• You can access this custom device from GitHub.

Particularly excited by any of these new features? Leave a comment below and let us know!

[Rajesh_Nair]

Most noticeable difference is the performance, huge performance improvement compared to R4

[CyGa]

Very exciting features !

However, what I'm not excited about, is that System Defintions made with VS 2020 R5 are not loadable in R6 !

This makes upgrading a real PITA !

[Darin_G]

Hi CyGa,

System Definitions made with VeriStand 2020 R5 are intended to load just fine in VeriStand 2020 R6. The SD file will undergo a one-way mutation from R5 -> R6 -- so once you've moved to R6 you won't be able to go back to R5 -- but that's the only catch.

If you're seeing something different, please engage with NI support and work with us to identify the cause of issue you are seeing. 

Best,

[ecleary42]

what is reasoning behind the release strategy? It is widely frustrating, 6 versions in 2020 alone!!!

why all these different versions with different exe's?

why are NI not updating software in the regular fashion? i.e. when an update is available it downloads and updates the software keeping the same exe and incrementing the version number

[kabooom]

Hi Rajesh,

We are curently using Veristand R4 and we will maybe move to R6. Could you detailed a little bit the huge performances improvement ?

National Instrument described some improvement in the Editor (essentially remove of old function). So do you mean huge performance improvement in the editor (which feature) ? In the real time execution ? 

Thanks for your answer

[Darin_G]

We addressed some editor performance issue with VeriStand 2020 R6, specifically we fixed a set of memory leaks that impacted load time, memory footprint for large projects. You may see significant improvements if you're the type of user that doesn't quit and relaunch VeriStand very often. Also if your PC is a little tight on PC memory, this could make a big difference in terms of your quality of life.

[ecleary42]

can you answer my question please

I work with VeriStand on a daily basis and with these different versions I have to keep one of each for each client that I have that is running a specific version within their contorl systems

It is highly frustrating and if I can get a reasonable answer from yourself then maybe I can negate some of my frustration

Thank you

[Darin_G]

Hi ecleary42,

I'm happy to shed some light onto our thinking behind our recent VeriStand releases. I am sorry to hear that this has frustrated you. Hopefully this background helps you understand our rationale.

We intend to keep the VeriStand 4-digit year suffix in sync with the supported version of LabVIEW's 4-digit year suffix.
i.e. VeriStand 2019 supports LabVIEW 2019
i.e. VeriStand 2020 supports LabVIEW 2020

Whenever we shift the 4-digit year, we consider this a major release. We try to line up new features that require users to take some kind thoughtful upgrade action on major release boundaries. For instance, for VeriStand 2021 which is coming soon, we are shifting to supporting only 64-bit LabVIEW 2021. That will require all custom devices to be built with 64-bit LabVIEW as well. This is not the sort of change we would do on a minor release.

We also strive to release a minor release once/quarter, so that we can shorten the time it takes for bug fixes to get into user's hands. That is why we adopted the release strategy where we ship VeriStand 2020, then VeriStand 2020 R2, then VeriStand 2020 R3 -- each releasing roughly 3 months apart (plus or minus a month, so that we line up with broader NI events). For each of these releases, we generally test the latest NI RT driver stack and against the latest VeriStand release.

As you are a customer with a number of clients, with each client potentially needing a different version of VeriStand and thus a different version of the entire NI driver stack, you are probably best off developing/using VeriStand in a Virtual Machine environment that is dedicated to each VeriStand version.

There is a different mentality for official NI-supported Custom Device projects stored on GitHub. Feature work we do on that part of the product is generally applicable to the last 3 versions of VeriStand/LabVIEW but can differ on a case by case basis. We maintain Custom Devices with the oldest supported version of LabVIEW (most of the Custom Device source code is saved in LabVIEW 2019 even though we are shipping those changes with VeriStand 2021). Our latest Custom Device releases will work back up to 3 versions unless that Custom Device needed a LabVIEW feature that didn't exist back then.  i.e. our VeriStand Embedded Datalogger CD shipping with VeriStand 2021 can be used with VeriStand 2019, 2020 or 2021. The VeriStand Avionics Bus CDs we have just added recently work only with VeriStand 2020 and 2021 because they use LabVIEW interfaces.

That has been our thinking on release strategy to date. Note that this is not a strict policy and we may change this strategy going forward depending on NI business needs that I cannot readily anticipate.

[Rajesh_Nair]

Hello Kabooom,

I am seeing huge decrease in CPU usage. Our SDF on R4 used to take 35 to 38% of CPU with R6 it reduced to 19% during the execution(after deployment)

Looks like they fixed the bug in R5