Additional NI Software Idea Exchange

Post an idea

Often times, the values of numeric indicators are changing rapidly and it is necessary to create Calculated Channels with Averaging [Smoothing] functions to make it easier for the operator to interpret the data. When you need to do this for dozens of channels, this is very time consuming for the end user and requires unnecessary resources of the RT controller in performing these calculations.

With charts, it is possible to edit the Streaming Rate, but with Numeric Indicators this is not possible.

Request:

Add an option in the Configuration Pane, for the numeric indicator selected, to Average the channel value by xx points (n)

View All (2)

Request for evaluation by a user group and update of VeriStand System Explorer user interface. The System Explorer user interface has changed little in several years - small improvements, such as allowing the user to enter formulas using the PC keyboard rather than the interface within the Calculated Channel Configuration Page would be significant. As an example, the INERTIA Calculation Custom Device is more user friendly and intuitive.

Additionally, the ability to better organize Calculated Channels, Alarms, Aliases, User Channels, etc. after creation would be helpful. For large projects, where we have dozens of variables and calculated channels, it is a significant amount of work to organize after the variables or calculated channels are created. Creating folders beforehand to help organize is a workaround, but after the fact, using the Cut and Paste functions are clunky - the ability to drag and drop would be preferred.

View All (1)

The way we use VeriStand [currently 2019 SP1] and the INERTIA custom device for drivetrain testing, we work off a project template that may be reused for new tests, but a great deal of editing must be made to the system definition file for each project.

While starting up a new test fixture, I am undeploying the VeriStand project multiple times per day to make edits to the system definition file procedures, alarms, calculated channels, etc.....items that can not be edited [or at least retained after undeployment, such as alarm and user channel variables].

I would like the opportunity to edit a system definition file while the project is deployed so I do not lose downtime on test run time. Would it be possible to, similar to SharePoint, "check out" a system definition file to edit it while the project is deployed, and after the edits are completed, undeploy and then "check in" the new system definition file.

This feature could be integrated with a versioning feature to retain a specific number of revisions of the system definition file - say a preference that specifies to retain 15 prior versions of the system definition file.

View All (1)

When testing, the beauty of automation is, that we can do the same test on many instances just by copy & pasting the code and modify the in-/outputs. Unfortunately, the stimulus profile editor is not know for it's usability when it comes to copy & paste or even applying changes to multiple lines at once.

Now what would be a great addition here, would be to actually rely on the hierarchy of channels (the prime example are CAN Frames). I want to perform the same test, using different CAN Frames that contain some signals for a motor.

MotorLeft_Status/Position

MotorLeft_Status/Speed

MotorLeft_Status/ErrorBit

MotorRight_Status/Position

MotorRight_Status/Speed

MotorRight_Status/ErrorBit

To perform the same test on these signals, I'd have to call a realtime sequence with all of the above as parameters. What I want to do, is just give the Top-Level Path (MotorRight_Status and on the next call MotorLeft_Status) to the sequence and then within the sequence, read the actual signals that I need from this CAN Frame.

The same could be done for the physical signals of the motor if they're organised nicely.

View All (1)

RT time is not the same as PC time unless you:

1) manually set PC and RT time so the y match

2) configuring the PC and RT Linux to sync to an internet NTP time server (requires a special configuration on the RT target)

3) configuring the PC and RT Linux to sync to a NTP time server on the local LAN (requires a special configuration on the RT target)

Why is it important for the computer time to match or at least be within a few seconds? Because the logfile name is based off of PC time and the data timestamps are based off of RT time. If the time between the computers don't match, confusion exists as to why there are different times.

A very simple solution is to sync the PXI time clock to the PC time when the Veristand project is deployed. At least for a few days the timestamps will be within a few seconds of each other.

Hi,

LLBs are outdated, suffer from name collision because it doesn't embedded lvlib nor classes, and force the VIs to match the exact same LV dev version with VS runtime version (to be able to run the compiled code of raw VIs on the target without the need to recompile them).

It would be preferable if custom devices/controls could be built into lvlibp instead.

It has many advantages such as:

* Source protection

* Respect of lvlib and lvclass namespace (avoid name collision)

* Only the compiled code is stored so they are smaller than LLBs

* Compiled code made with LV 2017+ is compliant with upper versions of the run time engine (would allow keeping the version of LabVIEW while upgrading Veristand)

I'm pretty sure the limitation nowadays only relies on file extension filtering to find the 'main' VI to launch in the SysExplo and engine. If I'm right the change could be done easily.

View All (3)

For the AK protocol (probably for any of the protocols supported by the add-on), the add-on expects numbers (represented as strings) for each returned parameter in the device response, but, if there is an error converting the string to a number, all further processing of the response is stopped and 0's are returned for their values

Suggestion: continue processing/parsing the remaining parameters. The final overall error code could be bit-mapped to indicate which parameter(s) has an error and use a base error-code of 0x80000 with bits 0 thru 14 to indicate which parameter(s) had the decode error and bit 15 to indicate parameter 16 or above had an error (or something like that). And the value for the parameter(s) that had the conversation error would return a globally user-defined value (for the driver) such as -999.999 so data being collected or displayed in Veristand can show the data is not available or in an error state.

View All (1)

Hello,

For custom FPGA personnality, it is possible to use PWM scaling: in the system definition, you can define the PWM period (in Ticks), and then at execution, you can play with the ratio (channel value in %):

PWM Out Configuration in System Explorer

I guess the "native" FPGA scaling inludes the conversion between pulse ration specificed by the channel and the period in ticks to get the high and low time used in the FPGA (_High Pulse x and _Low Pulse x in FPGA example project) :

DMA Read operation and High/Low Pulse split in FPGA example

PWM out loop in FPGA example

I am facing for the third time (at least) a customer need to adjust this PWM out frequency at run time. I already adress this need by exposing high and low time in a Custom FPGA Personality. But that's not really convenient (I used to build a display template to get an easy way to configure the whole PWM generation - I'm not sure I even wan't to know if and how is possible with UI Manager).

My proposal : expose PWM period or frequency as an additional (and optional) channel, in order to allow the change of its value at run-time. The FPGA "interface" in VeriStandStand could take in charge the computation of high/low time according to this new channel value. This way, existing FPGA personnality do not have to be changed (backward compatibility).

Cherry on top of the cake, you can even imagine to set up the expected PWM Loop rate and express the frequency in Hz, instead of the PWM period in Ticks (scaling, one more time).

Under the System Explorer, a right click on the PWM out channel could expose a new entry in context menu, allowing the user to Add PWM Frequency Channel (just like Add Information Channels for XNET frames)

Regards,

View All (4)

Hello,

R&D community across the globe is moving toward FAIR Data Principles. More and more funding agencies are requiring that data created by and used for research need to be Findable, Accessible, Interoperable and Reusable (FAIR). NI already has made great strides towards metadata-rich data, such as industry-standard open source TDM/TDMS formats.

The next logical step is to help NI customers to comply with FAIR Data Principles requirements. The best way to support NI customers will be the development of TDM/TDMS API for major public data repositories, such as Harvard's dataverse.org etc.

View All (3)

Dear Colleagues,

customers need for directly importing the NI Veristand log files into third-party tools (as Vector CANanalyzer) and we found the following contrains:

- TDMS are very effective and open, but not directly manageable by other tools

- txt and cvs are potentially more suitable, but NI Veristand 2019 does not allow adding a native Time Channel, that's fundamental. I saw that System Time and Absolute Time are potential channels to add to a log, but there are no options to format the timestamp and to allow some kind of flexibility

Suggestion/requests:

- adding customizable time channels to txt and csv log options in NI Veristand (the limitation is still the files size bacause of ascii, but the multiple files option could help)

- whatever improvement are in the NI VS roamap logging?

- what about MDF4 support? It would be vey useful and well accepted: I recall it was in the roadmap evaluation but no news so far. In case, what MDF: signal and/or message format(s), BTW?

In case, concerning the roadmap, could you please contact me directly (davide.palandella@ni.com)?

Thank you very much

Best Regards

View All (2)

Currently error messages are quite vague - they say what failed, but don't say where. It might be fine in LabVIEW development, where error pops up in the exact location on the block diagram, but it's not well suited for Veristand, where all we have is the error message. Take this as an example:

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

The VeriStand Gateway encountered an error while deploying the System Definition file.

Details:

Error -1074384704 occurred at Project Window.lvlib:Project Window.vi >> Project Window.lvlib:Command Loop.vi >> NI_VS Workspace ExecutionAPI.lvlib:NI VeriStand - Connect to System.vi

Possible reason(s):

NI-XNET: (Hex 0xBFF630C0) A property value was out of range or incorrect. Solution: specify a correct value.

=========================

NI VeriStand: NI VeriStand Engine.lvlib:VeriStand Engine Wrapper (RT).vi >> NI VeriStand Engine.lvlib:VeriStand Engine.vi >> NI VeriStand Engine.lvlib:VeriStand Engine State Machine.vi >> NI VeriStand Engine.lvlib:Initialize Inline Custom Devices.vi >> Custom Devices Storage.lvlib:Initialize Device (HW Interface).vi

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

I'm trying since 2 days to figure out which property is invalid - I have 4 CAN channels and 2 LIN channels in the SDF... If there was an information about the channel/value that causes the error, it'd be far easier to sort the problem out.

View All (4)

View All (2)

VeriStand looks in specific directories for plugins. This makes source code control and configuration management difficult for our ADG customers. If Veristand.ini allowed customers to provide paths (plural) to VeriStand plugins, then the plugin destination directory could be under SCC/CM and isolated from COTS plugins. For example:

AdditionalCustomDevicePaths = "C:\Projects\Resolver;C:\Projects\Valve"

AdditionalFPGAPaths = "C:\Projects\EMF"

AdditionalToolsPaths = "C:\Projects\RTSA"

etc.

View All (2)

Is there a technical reason why DAQmx Scales can't be added to VeriStand waveform channels? My understanding is that the logging mechanism is just the shipping NI-DAQmx Configure Logging function, which supports logging channels with applied DAQmx scales. I'd like to see the same right click menu "Select Scale" option that you have for single point channels to enable it.

Right now I'm looking into how to apply these scales. It looks like I could either add a custom device or post-process the TDMS file, neither of which is a terribly elegant solution, especially since what I'm trying to enable is a shipping feature of the underlying driver and would be annoying to have to replicate.

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)?

--Eric

Nb: I currently have a working solution, in case anyone urgently needs this feature.

View All (5)

View All (3)

Currently there are caveats when upgrading system definition in VeriStand. It would be helpful to have a tool to help VeriStand developers check and see what type of issue they might run into when upgrading a system definition. Specifically an issue that I've encountered was that my pathing for the upgrade was correct but the mapping of the items turned out wrong. An example of something a tool could help out with is a test for the Model item map. That test would verify that all model maps refer to the fully-qualified path to the item.

View All (2)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

Additional NI Software Idea Exchange

VeriStand Screen Numeric Indicator -> Built-In Averaging & Smoothing

VeriStand System Explorer User Interface Update

[VeriStand] Edit System Definition file while project is deployed

[VeriStand] Channel path as parameter for RT Sequence

Synchronize RT Time to PC time when Veristand Project is deployed

Allow VeriStand custom devices to be built as lvlibp instead of llb

Errors in parsing returned data with the Instrument Add-on results in stopping Veristand from decoding the remaining returned parameters

VeriStand : Allow PWM out frequency update while running for FPGA pesonnality

API in Support of FAIR Data Principles

VeriStand Workspace and UI Manager Display Options

NI Veristand Logging capability evolution

[Drivers/Veristand] More detailed error messages

VeriStand Deployment error logging

Write to Digital Port in VeriStand

[VeriStand] Allow INI-based Paths for Plugins and Dependencies

Stimulus Profile Editor -> Find / Replace

Apply DAQmx Scales to VeriStand Waveform Channels

Refresh the *.nivssdf Tree on Demand

Recommended Upgrade Path for VeriStand

Upgrade Test for System Definitions