LabVIEW Idea Exchange

This is a relatively trivial one that bugs me once in a while.

If we have a control or indicator (e.g. named "numeric") and make a copy of it, the new control is named "numeric 2". (followed by "numeric 3", "numeric 4" etc. if we make more copies).

Basically, if the label contains a trailing number, the highest existing number will get incremented by one for the new copy. 

What's wrong with this? You ask...

Let me explain: In labVIEW most things start counting with zero (e.g. array indices, iteration counters, etc.). For consistency, the original control should be considered "zero", so the first copy should be called "numeric 1" instead.

Interestingly, if we initially rename the control to "numeric 0", the first copy will be called "numeric 1" automatically. Why is "1" skipped if the original label does not end in a number???

I hope this is the correct venue for ideas about the desktop execution trace toolkit.  It is a LabVIEW-related tool.

In the course of investigating several LabVIEW crashes, one of NIs AEs suggested the DETT.  This seemed like a really good idea because it runs as a separate application and therefore doesn't lose data on the crash.  Better yet, the last thing in the trace would be likely to be related to the crash.  So I started my eval period of the DETT.  I am debugging a LV 8.6.1 program but since I have installed LV 2009, the 2009 version of DETT came up when I started tracing.  It seemed to work, however.

Sadly, the DETT sucked.  After about a minute of tracing, it got buffer overflow and popped up this dialog:

When I dismissed this, I got the usual popup about "Not enough memory to complete this operation."  Following this, the DETT was basically frozen.  I couldn't view the trace, specify filters, nothing.  I had to restart the application.  I tried a few hacks like disabling screen update while running, but nothing changed.  The DETT app was using about 466 MB at the time, and adequate system memory was available.

Possibly this is a stripped-down eval version.  If so, it is a mistake to make an eval  version work so badly that one is pursuaded not to buy the full version, which is the way I feel now.

I have some suggestions about how to improve the tool.  If these are implemented, I would recommend that we buy the full version.

1. Stop barfing when the buffer overflows.
2. A wraparound (circular) buffer should be an option.  Often one is interested in the latest events, not the first ones. 
3. There should be a way to specify an event as a trigger to start and/or stop tracing, like in a logic analyzer.  Triggers could be an event match, VI match, user event, etc.
4. The tools for analyzing events in the buffer (when it doesn't overflow) are useless. A search on a VI that is obviously present fails to find any event for that VI.  Searching should be able to be done based on something like the trigger mentioned above.
5. The display filter is a good start but needs to be smarter.  It should be possible to filter out specific patterns, not just whole classes of events.
6. The export to text is broken.  It loses the name of the VI that has a refnum leak.
7. Refnum leak events are useless.  They don't give even as much as a probe would show, like what the refnum is to, the type, etc.
8. The tool should be able to show concurrent thread/VI activity side-by-side, not serially, so one can see what is happening in parallell operations.

Do this stuff and you will have a useful tool.

John Doyle

Summary: We should add an option to LabVIEW so that if you have the VI Analyzer installed, whenever you use source code control to check in a modified VI, the VI Analyzer runs with a predefined list of settings to make sure that the modified VI meets the standards you've chosen.

Details: There are many aspects of a VI that ought to be a certain way when the VI is considered "finished" that ought not to actually break the VI. For example, you might want the text in your free lables to be spell checked correctly on a finished VI, but you don't really want the VI broken while debugging if you have misspelled words. You might not want coercion dots in the final VI, but breaking VIs when you have coercion dots during development is overkill. At the moment, you have an option of turning on Show Warnings in the Error List Window for a lot of these sorts of things, and LabVIEW R&D could add more to the warnings list, but there are so many things that we warn you about that the list is just noise, and since warnings are off by default, most people never see them. Your other option is to remember to run the VI Analyzer before you check in your VIs, but not everyone remembers to do that everytime. If the analysis could autorun as part of check in, it would help ensure good standards for VIs. I suggest that LV should have some way for the user to establish a list of settings for which VI Analyzer tests to run every time VIs are checked into source code control.

Hi,

  I was thinking it would be very helpful if we had a status bar on the VI window which can show what labview is doing right now. For example, If the person is cleaning up the diagram, there can be a status message "Cleaning up diagram" and later put up a message saying "Diagram Cleaned Up". If possible, we can have a progress bar for long activities like it can show the amount of progress in the diagram clean up.