Additional NI Software Idea Exchange

Post an idea

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,

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)

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.

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)

This attached file is a picture that shows the outcome of current drag and drop UI setup (above the box), and the desired drag and drop UI setup (below the box).

As you can see above the box, when I drag and drop each channel that a user could select for a single digital output, the controls are numerics by default. It would be quite tedious for a user to drag and drop each required channel, and then interpret the channel's function based on its name alone. Below the box, I right clicked a channel from the tree, and then selected a control based on the datatype that makes sense with respect to the channel's function. It makes sense that the controls are numerics by default because in the Set Channel Value.vi (part of Custom Device API library), the only accepted datatype is Double. However, it would be nice to be able to set a channel's datatype in a custom device's configuration VI. Channel, folder, and device properties can be set using a polymorphic VI that supports many data types. I propose that channel values could be handled in a similar way. Then in the VeriStand UI, when a channel is drag and dropped from the system definition tree, it could be recognized as Boolean, ring, numeric, etc...

Further desireable functionality would include a custom control which would allow the user to drag a single channel from the system definition tree. The custom control would be composed of multiple programmer-defined controls whose data would be passed to the driver in a cluster since there could be multiple datatypes. Using the attached file as a visual example, the custom control would programatically update its appearance based on the desired output mode (discrete, PWM, or encoder).