LabVIEW Bug Reporting
|
This page is considered a National Instruments guideline. It is generally accepted among the LabVIEW community and is considered a standard process that all LabVIEW users should follow. However, it is not set in stone and should be treated with common sense and the occasional exception. When editing this page, please ensure that your revision reflects consensus. When in doubt, discuss first on this page's discussion thread. |
LabVIEW Bugs are not limited to things which result in crashes of the software. Below are the most common categories of LabVIEW problems that should be reported to NI:
- Crashes/Hangs:
- occurring in the development environment – for example, you click undo and LabVIEW crashes
- occurring in during your program execution – for example, when you execute a property node with an unusual value, LabVIEW hangs
- Performance Problems:
- operation is taking an unexpectedly long or short time to execute
- performance in a feature drastically degrades between LabVIEW versions
- LabVIEW Documentation:
- Incorrect documentation such as incorrect steps to follow, typographical problems, etc..
- Incomplete or insufficient documentation for a feature
- Generally underreported and understatedly important
- Cosmetic problems and unexpected behavior:
- Problems with LabVIEW user interface windows
- A LabVIEW feature behaves in an unintuitive manner
Like all programming languages, a problem encountered in a large application may seem like a LabVIEW bug may not actually be a bug. The Reporting a Bug service request type discussed below should only be used to report specific LabVIEW bugs to NI. It is important that any user experiencing a problem in LabVIEW conclusively determine a problem is a bug before reporting an issue as this request type. Most of the time LabVIEW bugs can be reduced to a single VI and/or a set of a dozen or less steps to reproduce. If you need assistance determining if your problem is a bug, or if you need advice on troubleshooting your problem, please use the LabVIEW support channels of your choosing (LAVA, NI AEs, Discussion Forums, etc…) to discuss your problem with the community.
Requirements of a Good Bug Report
Good bug reports should always include the following:
- Steps to reproduce
- What happened
- What you expected to happened
This information is needed to confirm that what you are seeing is actually a bug and to help figure out what is causing the buggy behavior. It is also a great idea to include any example code that demonstrates the bug and/or screenshots of the bug.
Why Report Your Bug to National Instruments?
The reason to report bugs to NI are simple – so they can be fixed! NI Applications Engineers are trained on filing good bug reports (called Corrective Action Requests, or CARs internally at NI) and have a well defined system in place to manage communication with customers. Applications Engineers also look for other opportunities to improve documentation, online literature, etc… as a result of your reported problem and other known LabVIEW issues. For these reasons it is important to report bugs to an AE when possible.
AEs can be reached by creating Service Requests. If you have an active service contract you can reach an AE directly by visiting www.ni.com/ask and choosing to call or email NI. All discussion forum posts that are made to the NI Discussion Forums are monitored by Applications Engineers. Discussing your problem in any community (LAVA, NI Discussion Forums, etc…) is always encouraged and can often result in the community working together to find workaround and better define the problem. However, non-NI forums such as LAVA and info-LabVIEW are not officially monitored by NI employees, and are almost never monitored by an Applications Engineer. To ensure your problem is properly reported to NI R&D, please report your bug to an AE by creating a Service Request or posting a description of your problem to the NI Discussion Forums. Whether the problem is reported directly to NI, we recommend you post a new thread to the NI Discussion Forums on the issue (and include a CAR number if you have one) so that other users with the same problem have public record of it and any workarounds you may have found. To raise the visibility of the issue to other community members, you should also create an NI Discussion Forum thread and link it from the breakpoint monthly bug forum list (discussed below).
Reporting Bugs to National Instruments
If you have a bug to report to NI, and the issue has not already been reported to NI, go to http://ni.com/ask to submit a support request. You can always call the Applications Engineers and open a new Service Request to report the bug. This option tends to be faster and more informative. If you call in then state your reason as "LabVIEW Bug Report" and then talk through your issue with the engineers.
You can also select to Email the Applications Engineers as well. If you do choose to email your reported bug, then select "Reporting a Bug for your Question Type and fill in the other appropriate information. Make sure and be as descriptive as possible in the short field for the Question Summary as the next page will have a list of possible solutions based on those keywords. LabVIEW has been around for a while so make sure and check through this list of possible solutions as you are unlikely to be the first person to run across your issue. If the list of possible solutions doesn't work, then move on to the next step of the email process and try to be as descriptive as possible. As many details as you can put in as far as steps you have tried to solve the issue (i.e. trying it on a different computer, trying a different version of LabVIEW), attach any and all files that would be needed to reproduce your issue on a new computer at the bottom, and also detailed steps to reproduce. This makes the job of the Applications Engineers and NI R&D much easier when trying to diagnose the issue and will lead to hopefully a faster time to solution for you. After you enter in everything, continue with the process and send the email. NI Applications Engineer should follow up in a timely manner after you send it in.
If you select Phone or E-mail NI, and you have a valid service contract, you will be routed to Applications Engineers who can file the appropriate bug report. If you do not have a valid service contract, you should select Phone NI and you will be routed to an intermediary person who can pass you through to an Applications Engineer, provided you are calling to report a bug.
If your bug is in fact a bug, ask for a CAR Number -- this is how your bug is uniquely identified and can be used to track its status. When you get a CAR Number you should update your posting in the Bug Lists forum to include this CAR Number.
Posting a Bug Report on the LAVA Forums
There is a Bug Lists forum on LAVA. This should be used for reporting confirmed bugs with a CAR Number. If a posting in the bug lists forum is determined to not be a bug, it will be moved into another forum. Also, you can use the LabVIEW General discussion forum to discuss the issue with other LAVA members before creating a more official posting in the bug lists forum.
Bug report topics should be titled with a short description of the bug. The description of the topic should be used for status and CAR Number. For example, see the "Move on disk" feature crashes LabVIEW bug. Notice how it has a clear title and description:
- Title: "Move on disk" feature crashes LabVIEW
- Description: Status: Filed with NI support (CAR #4da9pok8)
Linking to Your Bug Report on the Monthly Bug Thread
In order to give NI visibility into your bug, you should post a link to the NI Discussion Forum thread where the issue is reported on the Monthly Bug thread in the Breakpoint forum on ni.com. On a monthly basis, the thread is reviewed by a senior engineer at NI to ensure all threads that link to an NI board have been properly answered and CARs have been filed NI's support engineers use this list to create an index of all publicly reported bugs and will use this index to provide the community with updates when the status of a bug changes.
The easiest way to find the latest Monthly Bug thread is to look at this search results page. The latest thread should be at the top of the search results list.