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:
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.
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 :
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,
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?
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”.
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.
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!
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.
Please change the NI uninstaller program in Windows to be resizable. You have a tiny list box to list all the MANY little applications that NI installs. It's so small, though, that I have to constantly scroll to read the names. Vertical scrolling only would be tolerable. It's the horizontal scrolling, too, that is most annoying.
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.
Many times, I find myself wanting to compare different I/O traces side-by-side, but I can only have one instance of I/O Trace in memory and hense can only view one capture at a time. Would it be possible to view two different captures within one instance of I/O Trace? I believe a lot of people would appreciate either a split screen option or the ability to open another instance of the I/O Trace application in memory.
Send the VLA log automatically as notification to the VLM administrator.
The VLM log can send the logfile automatically to NI, however this is not an option when the server is not connected to the internet. In this case, emails can be send to the administrator. It would be great if the VLA log will be attached to the email, so that the administrator can forward this to NI.
With VLM 3.1, a number of default reports are available (License Activity, Client Activity, ...).
Some of the default reports (License Activity, Seat utilization and Seat Utilization (Concurrent)) have a License field that the user need to complete.
The issue I have is that we are using different licenses (Dev Suite, Dev Suite with Data Management, Dev Suite with FPGA, ...) and that I cannot generate a report that includes all licenses together.
My request is to have the possibility to select "All licenses" in the License field.
I am more than willing to validate this feature in an alpha/beta release.
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.
I recently handled a service request (SR# 1698819) in which a customer was confused why TestStand was not listed in License Manager (LM) when his admin had generated a disconnected license. For him, all that was showing up in his LM was the following screen shot:
I explained that the Developer Suite with Industrial Monitoring and Automated Test (Disconnected License) includes a disconnected license for TestStand.
The product suggestion I'm making involves being able to expand disconnected suites by clicking a plus button to the left of the suite for example to view all of the software that's available to the client. This will avoid future confusion on the customer's end and reduce support call volume.
I have detected a small but cumbersome problem witch at the end of the day can grow to a problem with heavy impact related to security updates.
In the actual release, the NI Volume License Manager can disable the NI Update Service on the client machines if the Administrator of the Volume License Manager sets the option “Disable NI Update Service on all client machines”.
Now, for example, there is a scenario on witch clients get the License for a DIAdem installation from the NI Volume License Server and get the License for a LabVIEW installation from the local License Manager.
The problem is, that the user cannot update his LabVIEW application using the NI Update Service because it is blocked by the administrator of the NI Volume License Manager for the DIAdem installations.
There should be the possibility to disallow the Updates by Products instead of disallow the whole NI Update Service.
With best regards
It would be nice for RF simulations if the 0dBm reference on the spectrum analyzer was referenced to 0dBm in 50 ohms (0.224V) versus 600 ohms (0.775V). Maybe a solution would be to make it user defined.
Thanks for consideration.
We are doing testing of our complex Logic devices (CPLDs and FPGAs).
With this effort we are finding from the FPGA designers, that to cover testing requirements for the CPLD we need to generate 100’s of code files that validate all the test cases per our requirements.
The designers then creates 100s of VCD files from ModelSIM that Test Engineering then has to convert to HWS files using the digital Waveform Editor 3.0 in order to run on the HSDIO cards.
Since the effort is currently manual, we were looking to automate the importing tools from DWE 3.0.
as my project grows the amount of files to test wil grow to 1000's of files. Automation of the import and export wizard would help substantially.
However, Digital Waveform Editor 3.0 does not support scripting or provide LabVIEW APIs to do so.
We are currently looking at a Windows scripting engine to do this by mouse clicks but would prefer a LabVIEW API implementation to control this operation.
It would be great to create APIs that can script the import and export functions of the DWE 3.0
I see that the .LLB libraries are there in the DWE directory but no documentation to use for scripting. I believe this is possible to script but not without a lot of trial and error on my part.
Is NI looking into creating APIs with hooks into Digital Waveform Editor (DWE) for scripting conversions from VDC files to HWS files?
This is my thoughts on the API from the Import Export wizard.
<ctl>VCD or ASCII (enum)
Import Wizard Select Signals
<ctl> Array of Signal Names
<indicator> Array of selected Signal Names
Import Wizard set Signal Name Type
Drive, Compare, or Bidirectional (Enum)
<ctl> Array of Signal Names
Import Wizard Sample Method - On Edge of VDC signal
Select Sampling Method
Select VCD Signal
Sample on: Rising Edge, Falling Edge, Both Edges (Enum)
Delay After Rising Edge (sec)
Import Wizard Sample Method - Fixed timebase or Rate
Cycle Time for Sampling (sec)
Sampling Start Position (sec)
Retrieve from File (T:F)
File Path (path)
Save As: HWS or ASCII or Binary (enum)