LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Display VI version in title bar

While helping in the forums, we regularly run into VI's saved under an older LabVIEW version, modify it and post it back, usually saved in the latest LV version. Soon after the original poster complains, asking for a converted copy.

Years ago, I even proposed a small starware utility (Get VI version) that returned the LV version any vi was saved in. Unfortunately, it stopped working with LV 8 (and didn't recover since... ;)).

I found several proposals for displaying the version number (for instance here and here), but they are related to the application version and not to the vi version. None corresponds to this very basic idea : as long as a vi has been saved in a version different from the one in use, display it as unsaved (using the usual star), with the original version number attached. Something like this :

Alternatively, when saving the vi, the programmer could be proposed to choose the former LV version.

View All (1)

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):

View All (1)

PROBLEM: There are often times when I decide I would like to include some code that is just outside of a structure. Currently in order to get it into the structure I have two options:

Grow the structure, move the code inside, reattach all the wires, rearrange code so that the spacing is correct again.
Delete the structure and readd it. (This option is not valid for sequence structures where I'just want to move code from one frame to the next.)

SOLUTION: Allow a control (or shift) when resizing a structure that causes the structure to capture the code rather than move it. This should not break any wires. In essence, it would be like redropping the structure.. Note this could also work in reverse. If you size a control smaller, it would exclude anything outside the new boundaries of the structure.

Case Merger function

Every now and then I (or others) have two case or event structures that I would like to merge, either completely or just copy some cases from one to the other. If we are talking about one or a couple of cases, doing it by creating empty cases and copying the code from one structure to the other as is the option today is fine. If the number is much higher this gets quickly tedious, and we have to come up with alternative solutions.

(Making a subVI of the two and add another case structure around them, as described in the discussion linked to above, is one - but that changes the layout and adds another selection to the logic).

So how could it be handled by the IDE instead and made much easier?
A case merger function.

Here are a few quickideas on how to implement it (but any similar solution would be better than none);

Copy-Paste-Merger: Selecting the frame of structure 1, copying it, selecting frame of structure 2 and pasting will bring up a merge dialog with the following options:

a) Replace structure?
b) Merge structures (all cases)?
c) Merge selected case only into structure?

Now if the user selects to merge the whole or just the top/selected part of the structures (b or c) the function has to handle overlapping cases (just like the OS does when copying into a folder with existing content) by asking the user whether to keep the old ones, replace with the new ones or leave them as non-unique values (or add an index to the value) for the user to tidy up manually afterwards.
Drag and drop merger; identical to the previous suggestion - but instead of copy/paste the transaction is initiated by dragging structure 2 over structure 1 and e.g. holding it with an edge aligned when dropping to indicate that it is not intended to go *into* the other structure.
A merge option that can be called from the menu or contextual menus on case/event structures. The advantage of this would be the ability to add more complex mergers where you would want to pick frames x, y and z from structure 1 to merge with structure(s) 2 etc... This option could alternatively be combined with the other two and used as the dialog when those are initiated.

Strict typedefs and non-strict typedefs differ significantly. There's too much of a gap for me. Sometimes I'd love a control to be somewhere in between.

There have been times where I wanted to force a typedef to have a constant size or colour or other parameters without having to force all other parameters to be identical.

It would be nice if a typedef could simply be gradually converted to strict by selecting which parameters are locked. That way we could shoose to long only boolean text, width or colour but leave the other properties free. VI Server would need to return an error that the type definition does no0t allow that change, but that is kind of already there for when you try to change properties of a strict typedef.

So by default a typedef would refer to data only (See HERE) but any further cosmetic changes (to which the datatype does NOT belong) we could simply select which parameters are locked and be done with it.

View All (10)

View All (2)

Customized Fonts for Graph Annotation

View All (6)

It's very frustrating to have your floating probe windows disappear when a LV modal window is presented. Frame 1 below shows probes set up, and Frame 2 shows how they disappear when a modal window appears:

Some of the most annoying modals that pop up while troubleshooting include:

"Save changes before closing?"
"Waiting for Real Time Target to respond"
Error windows

#2 and #3 modals windows recently made it impossible to use probes since I was trying to diagnose a problem that constantly would throw those modal windows.

Proposed Solution: Don't ever hide probe windows, regardless of what pops up.

View All (1)

Smart autocorrecting autoindexing

Tunnels for FOR loops are autoindexing by default. Sometimes this is not the correct option for very obvious reasons and we get a broken wire.

The diagram editor should be smart enough to try the "other" option (e.g. no autoidexing) if a broken wire results. If the other option succeeds without a broken wire, it should be used automatically. Maybe the tunnel could "glow" for a few seconds with a small option box (similar to e.g. when pasting into word: keep formatting, text only, etc) that would disappear after a while where we can click and overwrite the automatic handling.

The image shows two wires that would be a candidates for autocorrection of the indexing option. In both cases, LabVIEW should disable indexing automatically to avoid broken wires.

If both options result in a broken wire, nothing should happen, as before.

(Similarly for while loops. e.g. if I wire a scalar across the boundary to an array indicator, it should autoindex.)

View All (1)

When installing a new version of LabVIEW, I always find myself resetting all of the options I previously changed from the default settings in the Tools -> Options menu. This means I have to spend my time remembering what options I changed and where in the Options menu I need to change them. It would be nice if a newer installation of LabVIEW looked at the older version's Options settings and then applied those settings to the new installation.

The same idea applies to how I configure the palettes on the block diagram. It would be nice if newer installations looked at how I configure my palettes and then set them up the same way.

With these changes transitioning to a newer version of LabVIEW might be even more seamless for users that change their settings from the default settings.

View All (5)

It makes no sense (from a Software Engineering and Process standpoint) to force (and store) an absolute path for a build destination directory, in the project. What if a group is sharing a project but each developer prefers to have their files located in a different folder?!!

I recommend NI consider replacing the line of code in LabView that is checking for the presence of an absolute path for the build folder with on that does: "If user entered an absolute path, use it; otherwise, prepend the current project location to whatever (relative) path the user entered before building."

Parallelisation of loops is a great thing in LabView that offers a lot of possibilities and it's very easy to implement. In opposite to this debugging can drive you crazy regularly. A typical situation for me is that there are two loops in parallel whereby the first waits for user input (and handles it) and a second one cycles all the time doing some other stuff.

Assumed that the one with the user event handler needs to be debugged I place a break-point on a good place. When the execution stops there, I usually want to go step by step through the code. The problem is now the 2nd loop: because it is running in parallel the execution pointer jumps always between the two loops. I have to step through each function of both loops even that I only interested in the first one.

This becomes very annoying, confusing and time consuming if there is a lot of code in the 2nd loop, if the diagram becomes larger at all and if the highlight mode is activated.

To avoid this I suggest to show optional elements for debugging for each loop. With those elements I could decide if I only want to step through the code of the first loop while the second is executed normally (no highlighting, no single step).

Current situation:

improved functionality:

View All (9)

The "right-click...replace" option has few choices, typically the home palette of the current selection if available and "All Palettes".

Quite often, I need the entry "Select a VI...", all down at the bottom after selecting "All Palettes".

Suggestion 1: Add "Select a VI..." to the first menu, see image.

Especially when benchmarking or trying different algoritms, I often like to replace the current VI with another VI that is already in memory.

Suggestion 2: Also add a "VIs in memory", which would allow picking from list of all VIs in memory (except things located in VI.lib or in the standard palettes).

Here's an image how it could look like:

Message Edited by altenbach on 07-05-2009 09:35 PM

History for insert

In a big project I needed to insert a function at several (read "more than hundred") places.

How much would I have appreciated a history which gave me a direct access to this function without the need to go to the specific functions palette again and again !

This would have saved me a lot of time... and made this annoying task a little bit less annoying !

LabVIEW should memorize at least the last inserted function/VI but a history of four or ten would be much better.

The history could be implemented either with an extra menu (see below image) or by listing the X last inserted functions/VIs right under the All Palettes menu entry.

The incompatible functions/VIs for the wire type should be grayed out or, even better, the history should be contextual and list only the compatible functions/VIs.

View All (2)

LabVIEW Idea Exchange

Display VI version in title bar

"Delete from Array" function should accept an array at index

Standard marking for when 'error in' is ignored/passed through

Allow structure resize to capture code not just move it

Make every created Enumerated type a Typedef

Case Merger function

Bridging the gap between strict and non-strict typedef

Allow ONLY the Block Diagram to be opened Without Front Panel

LabVIEW.exe Command-Line Argument to Show Block Diagram

Customized Fonts for Graph Annotation

Data Probes Should Show At All Times

Smart autocorrecting autoindexing

Compare aggregates option for scalar comparisons

New LabVIEW Installation Retains Options

Application build destination directory should not require absolute paths

improved Debugging for parallel loops (optional / selective debugging)

Replace/Insert/etc context menu should show palette for wire element type as well as Array Palette

More options for the "right-click...replace" menu.

History for insert

Diagram Constant Representation visualisation