12-13-2005 01:31 AM
Darren --
Old friend, I think the analyzer is a slick tool. Personally, I would like to see an advanced memory feature that analyzes how/where LabVIEW allocates memory based on how the VI is coded -- basically, a 'VI Metrics' mashed with 'Show Buffer Allocations' on steriods. The analyzer would monitor memory copies as the application is running and then offer suggestions that would minimize them. A feature like this would be really beneficial to those of use with large applications. I've attached an example of what I am talking about...
C.
12-13-2005 09:23 PM
Darren,
I use the VI Analyzer semi-regular throughout the process on many of my projects. I do not use the programmatic features but rather the full analyzer. I find the VI answer very useful for finding certain types of problems in my code (such as Ben's mentioned bundle/unbundle bug), but I find it somewhat annoying to use as well, since I tend to get a lot of false positives and it takes a lot of time to sort through the errors.
Some pet peeves:
The VI Analyzer finds bundle duplicate elements (per Bens post), but does not find unbundle duplicate elements. On a recent 1500+ VI project, we were running into the bug with LabVIEW spontaneously remapping the bundle/unbundles very frequently. VI Analyzer allowed us to find the bundles that were modified but not the unbundles.
VIs using internal storage (e.g. shift registers with a loop), where I define both error and no error cases. The error/no error case needs to be in the while loop, which then gives me a false result that I am not using the error cluster to modify execution.
As above, but cases such as a close file/close serial port where I merge the incoming error with the error of the action performed in a VI to the output error cluster.
Local/Global instances, (I may be mis-remembering on this one, if so, ignore): I have some VIs where I have a "large" (being defined as more than the default of 5) number of locals that are all write locals. I am not concerned as much with write locals/globals as I am with read globals/locals. It would be better to allow a maximum number of read local/globals and a maximum number of write locals/globals.
Unconnected Indicators. A very useful test but again frequently results in a large number of false postives. To save block diagram space, I frequently place an indicator instance of a typedef in a VI, linked to the connector pane. This VI is then used as the prototype for bundle by name functions or typecasting/flatten functions on the block diagram of another VI. It saves significant block diagram space, lessens the likelihood of severe damage due to insane objects, and provides an easy way to identify the typedef being used. However, it shows up in the Analyzer as a false positive that I have to ignore. Note: Since I name all VIs of this type "ControlInstance_something" it is easier to ignore than some of the other issues.
Regards,
Aaron
12-14-2005 11:33 AM
Hi Aaron,
Good to hear from you. I'm glad you're finding the VI Analyzer useful for your applications. I also really appreciate the feedback. Here's what I have to say on the issues you mentioned in your post:
Noisy results: I tried to provide as many means as possible to sift through the possibly large number of results you can get when running the VI Analyzer. Obviously, you can deselect any tests that you don't care about the results on. You can also tweak the "per-VI" selection of tests on the last page of the main VI Analyzer wizard. Also, you can change the priority of the tests you consider of low importance, such that they show up at the bottom of the Failed Tests list for your VIs in the Results Window. If you can think of any other things we could do in the user interface to help you deal with the large number of results returned, I'd love to get your feedback.
Unbundling duplicate elements: WIth the VI Analyzer 1.0, this test actually finds both Bundle and Unbundle failures, but only in LabVIEW 7.0. Due to an internal LabVIEW change that I overlooked in LabVIEW 7.1, the test will only find Bundle failures in 7.1. With the VI Analyzer 1.1, the issue is fixed in LabVIEW 8.0. So if you continue to use the VI Analyzer 1.0 with LabVIEW 7.1, let me know, and I will e-mail you a patch. Also, make sure you're using the 1.0f1 patch with LabVIEW 7.1...there are other internal LabVIEW changes with 7.1 that affect the VI Analyzer that are covered with this patch.
Error case inside a structure: As I recall, you called me up with this same feedback way back when we first released the VI Analyzer 1.0. It's on our list of things to look into with a future version.
Locals/Globals: We do allow you to specify different numbers for all four possibilities: Write Local, Read Local, Write Global, and Read Global.
Connected Pane Terminals: Yes, it does sound like your case is an excellent example of something you wouldn't want to flag as a failure. However, it should be pretty easy for you to deselect the Connected Pane Terminals test just for those specific VIs in the "Exclude Tests from VIs" page of the VI Analyzer user interface...it should be especially easy since those VIs you refer to all have a similar prefix on their names.
Once again, thanks so much for the feedback. Let me know if you have any other questions or comments. It's feedback like yours, and everybody else who has posted on this topic, that turns the VI Analyzer from a great toolkit to an indispensable toolkit.
-D
12-15-2005 04:06 AM
12-15-2005 10:28 AM
Hi Graziano,
There is actually a suite of VI Analyzer tests you can download from the NI website to help analyze RT-specific applications. Here is the link:
http://digital.ni.com/softlib.nsf/websearch/47404D016C211B1986256EA2005EB9EB
As for your issue regarding VI Analyzer failure messages, I tried to make each failure message for all the tests as descriptive and helpful as possible. I even tried to present possible solutions when applicable. If there are any specific test failure messages that are unclear to you, please let me know what they are so I can look at clarifying them in a future VI Analyzer release.
Thanks for the feedback,
-D
12-19-2005 12:37 AM
12-19-2005 01:31 AM
12-21-2005 03:19 PM
Hi Darren
I used analyzer only two times from LV7.1. After second I stopped and I do not think I will come back to it unless new versions are giving more that from LV7.1.
I did not get anything improved better than just doing it, if you know what I mean. Most of the times I get the warnings which are not relevant and do not improve the design nor performance. For me it is much better to use profiler and work on vi until I get the proper oerformance.
12-27-2005 11:13 AM
Hi Pawel,
As I've mentioned in previous posts, some of the style suggestions provided by the VI Analyzer are primarily helpful for newer LabVIEW users. However, the VI Analyzer can still be a tremendous aid in debugging for LabVIEW users of all experience levels. See my previous posts for examples where the VI Analyzer was able to detect functional problems in VIs that could not have been easily detected by visual inspection.
As for new features, VI Analyzer 1.1 recently released, and one of its biggest new features is a Spell Check test. You can learn more about the new version at the product page link I gave in the original post on this thread.
Thanks for the feedback,
-D
12-28-2005 04:25 AM