Additional NI Software Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Hello,

 

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.

 

Regards,

 

Shawn

Hello,

 

As the Idea : Controls for macros , it would be nice to add screen controls in order to handle with procedures !

 

For the moment, VeriStand RT procedures are only launched using alarms !

 

It could be usefull to be able to launch or stop procedures using screen objects. (Like the Model controller !)

 

ProcedureObjects.png

 

Manu.net

Please modify the VIs from the NI-CAN Frame API library in order to use the 4x2x2x4 connector (pattern 4815) or at least a symmetrical connector.

The improved library would avoid wire bends (error cluster, ObjHandle...) and simplify the alignment of the VIs.

 

CAN Frame API.jpg

 

For example this is the current connector of ncReadObjMult.vi :

 

CAN VI connector.jpg

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”.

 

IO Trace selective devices.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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 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.

I had to manually enter the properties of 25 frames and their signals (at an average of ~5 signals per frame). That's not fun, especially since many of them were similar.

 

The process would be a lot faster if I can clone the frames/signals and just edit the fields that differ.

 

xnet_pain.png

 

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. 

In certain circumstances it would be helpful to see exactly what license file ties to each piece of activated software within NI License Manager. This would be an additional field in the right hand pane of License Manager as shown below.

 

 

License Manager Idea.PNG

Hey there,

 

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 :

FPGA_Info.png

 

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 😉

 

Have a great day,

 

 

Hi,

 

Today we need to configure the hardware in MAX and in System Explorer.

 

Allow VS to import the hardware configuration from MAX and eliminate the DIO number of ports and port size manual definition.

 

I guessed the PXI2569 and PXI2570 configuration in a trial and fail matter till I found the number that did not cause an error during deploy.

 

Import all board I/O configuration and let the user remove what is unused later.

 

Cheers,

CHCastro

First time poster here so please excuse my ignorance if I am posting incorrectly.

 

I know NI supports CentOS and SUSE GNU/Linux distributions, but Debian distros are the most popular according to distrowatch.  I would like NI to consider creating 488.2 driver support for Debian based distros.  Specifically Linux Mint and Ubuntu.  I have been using Ubuntu 14.04 LTS and recently switched to Linux Mint 18.3.  Mint 18.3 works so well, I abandoned Windows 7 on my personal computer and only use Windows 7 at work (because I must).  I can use NI USB devices on Mint (and Ubuntu) by installing the driver in a Windows 7 virtual machine and passing through the USB in VirtualBox.  However this does not work for PCI cards.  Drivers are a big roadblock to migrating our test equipment off Windows so I am hoping NI considers better GNU/Linux development in the future.  Thank you.

It would be good if MAX was able to report the serial number of the PXI chassis and PXI controller, if they are applicable.

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. 

 

http://www.cnet.com/1770-5_1-0.html?query=extra+putty&tag=srch

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.

Hello,

 

In System Explorer, you can not change the order of items by drag & drop. It is better for users to change the order of items like Calculated Channel.

image.png

 

However, I guess better mapping usablitity will resolve this problems. If the mapping is like below image and the order can be changed, it is better for users to map all things.

image2.png

 

Regards,

 

Saku

Hi

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.

 

For download of updates from ni.com such as the device drivers (http://joule.ni.com/nidu/cds/view/p/id/3145/lang/en/rating/1) NI recommends to use the NI Downloader.

 

First suggestion: Fine, but the Download tool should download all the relevant files in one operation.

Not as of now where you have to download one NI Download program for each of the (here two) "DVD's" and execute each of them to get both install images downloaded. It is error prone, tedious and requires additional installation instructions.

 

Second suggestion: Give the user an option to keep the download in one big file. I think it is very few users who actually need the files to fit on a space restricting storage medium. As a note I see from the latest LV2012 downloads that some of the installation distribution files are more than 8GB. 8GB would easily hold the device drivers (as of 2012Smiley Wink) so there is actually no need in this particular case to span two media.

 

ni downloader.png

Provide an option to show more characters in the IO section (in quotes) of the Description field.  Why not use the column separator as a way to expand the viewable characters, instead of just showing more white space?

 

IO Trace expanded Description characters.PNG

 

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. Task configuration.PNG

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.

 

Current VeriStand.PNG

 

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.

MAX Task for VeriStand.PNG

 

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.

Posted this in Data Acquisition Ideas as well, but it seems like it would be implemented with something like MAX, so...

 

When dealing with various remotely deployed cRIO hardware configurations, it may be impossible to keep a sample configuration of every type of system we ever sell.  Unfortunately, if upgrades or revisions are made to the base code in our system, remotely deploying to our customers becomes impossible unless we have their exact configuration on-hand for the programmers to compile.  Remote connection to the hardware for this type of operation is also not typically possible.

 

To be able to simulate or emulate a full cRIO system (processor & hardware modules), then compile the RT code for deployment on that system as if it is physically connected to our development system would be ideal.  This would allow images to be created, which can be sent to customers for local deployment at their facility.  Dramatic decrease in "hardware library" requirements on the development end, reduction in "on-site upgrade" service trip costs to the customers.  Plus, easier for OEMs like me to justify the move away from PLC types of hardware and towards cRIO, once you take away some of the potentially nightmarish continued support and update issues involved with basing systems on cRIO platforms.