I/O Trace is extremely useful when debugging system-level text-based applications. Error handling for systems involving multiple drivers + software packages (RF toolkits, for example) is very difficult. After recognizing there was an error, we still have to determine which device threw the error and then query the appropriate driver/toolkit with the correct handle to determine what the error was. NI I/O Trace is a great way to quickly determine which device threw an error and at which function call. Unfortunately, the error reporting returned by I/OTrace is pretty limited. For example, consider the I/O Trace shown below of an application synchronizing two waveform generators. A property is not configured correctly for one of the generators. I/O Trace clearly indicates there is an error, however the exact cause of the error is difficult to discern from the message:
The actual error message is: “The Sample Rate property can not be configured if OSP Enabled is VI_TRUE. “. It would be great if I/O trace could provide the entire error description. Compare this to the LabVIEW error handler:
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.
In LabVIEW, we have a lot of options for saving our projects as seen below:
In VeriStand, currently, you only have the option for a normal save (as shown below). I think it would be nice to have a "Save As" for saving a copy of the project and, if possible, a "Save for Previous Version".
[Edited on 8/28/2014 by moderator Diego Carvajal (dcarvaja)] [Image included in original post as requested] To help debug medium and large real-time test sequences, it would be very useful if there was a sequence step that allowed the user to specify a console message.
Much like the Print Debug String VI helps debug issues when building custom devices, this step would allow the developer to insert specific console flags and see what part of his/her real-time sequence is executing.
Hi, a few suggestions related to software deployment.
1) Separate out the Volume License Installer from the Volume License Manager. These should be two separate programs. Having the VLI separate allows other admins in other departments to create VL installer files for their own area without having to have an agreement file for the volume license server (which would be running on another machine and one which the other admins may not have access to).
2) Have the NI License Manager client require elevated (i.e. admin) privileges to change the settings. This will prevent unauthorised users from changing the network license server which affects all users of the system. This is necessary in a classroom environment.
3) Have as an option whether things like the Package Manager/Registration wizard/Update service etc get installed.
For security reasons, many customers using Volume License Manager to administer licenses to client machines do not authorize users to download and install anything from the web. Therefore, if a critical patch is released, the client machines are unable to download this unless it is distributed by the administrator. It would be useful for the VLM administrator to be able to configure the Update Service such that all Users can run the Update Service but the service has been configured to point to an internal network share rather than an internet location outside the firewall. This way, the administrator could make critical updates and patches available for the client machines and the clients can be notified and install them.
Benefit: Simplify the process and reduce errors when using FPGA personalities
Idea: Querry the user-generated FPGA diagram and automatically create the XML file. Additionally, have some kind of editor/viewer for the XML file that would present the information similar to how it is presented in the System Explorer but allow the user to edit certain values (or just make it editable in the system explorer). Some items would be read-only (items specific to the bitfile communication) and others would be editable (heirarchy, scaling, etc).
Ultimately, the process for using FPGA Personalities would be:
- create FPGA VI using NIVS interface/template
- select interface in "utility/view" or System Explorer (XML file automatically generated)
Write clean IIO drivers for the NI DAQ cards and bringt them to mainline.
* full Linux-support via standard APIs out of the box (without extra sw installations)
* very high quality by community driven maintenance
* directly supporting for standard applications by standard APIs, w/o any hw-specific modifications
* easy integration in / customization for complex scenarios
* increased sales volume by opening a completely new market (Linux/FOSS world)
* avg. 4..8 man-weeks per device type
* usually less than 1kLOC per device
For example, the - currently completely unsupported NI-600x - can be easily integrated into IIO as well as GPIO and PWM subsystems (driver can provide several interfaces in parallel, so users can pick the appropriate one for their applications).
NI could open up a new market - the Linux/FOSS world - which is currently completely unavailable to them right no, due to lack of usable drivers.
Currently when trying to see errors we need to enlarge the window, scroll through the items, and then take a screenshot of the dialog. This was encountered when trying to share my errors with support. We should make this easier through the proposed ability.
I have many procedures that check for certain conditions before completing its intended function. If a precondition is not met, the procedure exits. It'd be nice to be able to pop up dialogs as necessary. Right now, in order to do so, I have to have the procedure call other alarms if I want any sort of feedback/popup which gets convoluted pretty quickly. Thanks.
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.
If the License Manager is used to deactivate software, it will leave the prior serial key in the registry. On subsequent activations, the Activation Wizard will automatically populate the serial number field. I assume the same kind of thing will happen with .lic/.lc licenses.
I can see a valid use case for this, but in my scenario, I need to remove development licenses from productions and disallow users to reactivate the software without getting permission (the serial key) from me. Since these keys can be found in the registry, I can write a script to do this; however, it seems like a feature that License Manager should include.
PS: I know, I used the wrong idea label. We need more label flexibility to cover other smaller NI software!