LabVIEW Idea Exchange

Why is "Rearrange Cases" not an option for a Case Structure with two cases?  This page (http://zone.ni.com/reference/en-XX/help/371361H-01/lvdialog/rearrange_cases_dialog_box/) indicates that you need at least three cases in order to summon the Rearrage Cases dialog box.  What if you just want to swap the order of two cases (For example: so that the default case is first or last).  Currently, I have to add a dummy case, rearrange, and then delete the dummy case.

Hello all, 

I have a suggestion about Automotive Diagnostic Command Set. It is currently designed for CAN-based diagnostics only and diagnostics on serial lines (K-line and L-line) are not in the scope of the Automotive Diagnostic Command Set.

I would like the Automotive Diagnostic Command Set to support diagnostics on serial lines (K-line and L-line) too. 

Automotive Diagnostic Command Set User Manual
http://www.ni.com/pdf/manuals/372139a.pdf

Best regards

Rutsu Kenmoku 

As shown by below RG code, the Select function should be redesigned in order to align the s input with the output vertically. Currently, the input is too low.

When a control is disabled, especially a large table or string control, it would be nice if the scroll bar would remain active in order to view the contents of the control, without the ability to actually change it.

I am not asking that the default behavior be changed, however a right click property/property node "scroll when disabled" would certainly have some value.

I sometimes delete controls from the BD and realise some time (from milliseconds to minutes) that I have some broken local variables.

I get greeted by the hugely informative imagery as shown below:

Yeah, good luck realising what exactly you deleted by mistake.  No name, no way of finding out what the local PREVIOUSLY linked to.

I suggest retaining at least the name of the Control / Indicator the local was linked to so that the poor programmer (me) has some fighting change of undoing the error.  Bear in mind there could be many changes made to a VI before this kind of thing is notices so a simply "undo" fix could end up being VERY awkward indeed.

An example of how this could look:

Here I at least know WHAT I have deleted by mistake.

Since most (if not all) controls and indicators can be moved around with "position" property node programatically, the X and Y coordinates on the front panel are useful information to have.

As of right now, users have to adjust the position values by trial and error to know what values suit the UI, or maybe make a program to capture the mouse position programatically.

So I've been getting feedbacks from customer about a function where one can view the coordinates of the mouse all of the time. (meaning no programming is necessary)

I was thinking about two methods (see attached)

1. Show coordinates along with the mouse

2. Show coordinates at the bottom of the pane

Thanks,

I am getting tired suggesting small ideas that could all be placed under one single umbrella:

Any right-click option should also be available from the properties dialog of the item!

Here are some recent example

• Richer Property Dialogs for Structures
• Add "Loose Fit" to scales property page
• Allow access to default value on control properties dialog

But there are probably many more....

Use case

Consider a distributed program, where client PCs have GUIs that show the values of variables hosted on the server PC. Suppose the server has to change its IP address.

Current options

Suggestion option

Have separate targets for the Server application and the Client application (each target can have an alias). Bind Client indicators to project variables hosted on the Server (no extra code required). Update the server address by updating the .aliases file (don't need to update each individual indicator).

The Desktop Execution Trace Toolkit (DETT) can trace enqueue/dequeue operations, so I would think this is feasible:

Add a mechanism to like the Profile>Performance & Memory view to display all active queues in memory by name (for "unnamed" ones, use whatever unique refnum/identifier is available) as well as the max size and current # of items in queue. You could use the same "Snapshot" functionality as the Profiler tool.

A particular use case:

We were tracking a memory leak in a large application that resulted from an unbounded queue whose consumer was disabled. The standard DETT and Profile tools weren't showing where the excess memory consumption was coming from, since queue data does not "belong" to a single VI. Granted, you can see the individual enqueue/dequeue operations in DETT, and even highlight pairs, but that's a little cumbersome in a large application.

I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes).  This one item would expand the UI possibilities.  It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets.  Below are some industry examples:

Adobe Splash Screen (No border, has shadow, not square)

  Microsoft Word 2010 Splash Screen (No border, rounded corners)

 Resource Meter Windows Gadget (No border, specialized graphic)

Windows Media Center Gadget (Empty-transparent space between two UI elements)

I would like to see the context sensitive help window intelligently move out of the way of wiring. It frequenty jumps to the place where I need to run a wire. My idea would be that if the mouse cursor reached the edge of the help window it would jump to a remote place on the diagram, and if you happened to wire to that remote place, it would keep on jumping out of the way.

When debugging (and at many other times), I want to copy data from a probe or control into a text file, Excel, whatever.

For reasons that I am totally unable to fathom, it copies the control as a bitmap. Print screen provides this functionality already. I think copy data should copy text instead!

I wasn't able to find this on the exchange, sorry if I missed it!

When you want to make a resizable front panel there are only few possibilities, especially if you don't want all your front panel beeing resized.

Splitters are great but you can't always use it, in a tab control for instance it's impossible (and someone already suggested this idea here, sad it's not implemented ).

You can do it programmatically (lot of work!), maybe with an XControl depending on your application (lot of work too!) or you can also Scale Object with pane with only ONE object.

There's still one option: Scale all front panel objects when resizing

Why not improving this method by adding an Ignore Resize property?

It might be easier to implement for developers compared to modifying tab control and would be really easy to use !

Renaming files with F2 or the context menue entry "rename" is easy - as long as the file is a LabView or NI-File. But if it is just a simple *.txt, *.pdf, ... file it is not possible. Please add this function! - thanks.

As seen here, the property pages are sometimes like swiss cheese, i.e. full of holes! Useful and often-used properties are missing, even though they are available via right-click.

One example is "Loose Fit". There is no logical explanation why it has been omitted from the scales property page. I suggest to add it!

Here's how it could look like:

IDEA: Add "Loose Fit" to the property page.

I think it is very difficult to make a UI that runs on Windows and interacts with targets. Here are two suggestions to improve this:

1. We currently can't have \c\ format style in a file path control on windows. It would be nice to allow user to specify the OS syntax to use instead of assuming it should always be the local sytax.

2. The icing on the cake would be to have the File Path Control support a property node for an IP Address so when the user clicks on the browse button, it automatically browses the target (this is already an idea mentioned in the link below) and uses the syntax of the target. This becomes especially useful as we start to have targets that may have an alternative way of browsing files besides FTP. It would be a pain to figure out which SW is installed on the target and use the correct method to enumerate files/folders.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-control-of-VI-under-real-time-target-should-brows...

These two features could be implemented by having an enum property node for the File Path Control called Syntax which include options like: Local, Various OSes (Windows, Linux, Mac, etc), or IP Address. If IP Address is specified, another property Node called IP Address will be used to determine what target's OS to use (if it's not specified or invalid, we default to Local).

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:

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number.  For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later.  Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions.  However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

• Changing VI connector panes
• Renaming or moving VIs on disk
• Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs.  Consider the case where I make the following changes to a VI from my toolkit:

	Version 1.0	Version 2.0
VI Path	<userlib>\mytoolkit\CompRes.vi	<vilib>\mytoolkit\Compute Result.vi
Owning Library	none	Mytoolkit.lvlib
Connector Pane

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI.  This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

The specific issue I've run into is that some newer LV features (like Auto-concatenating loop output tunnels and the expandable Merge Errors node) can be represented in earlier versions of LabVIEW with a more complicated combination of nodes and wires.  When "Save for Previous Version" is used, the equivalent code needs more diagram space, but ends up all crowded together on the block diagram.

Here's a specific example (sorry I don't have the original LV2012 source):

In this case, the empty array constant is actually connected to the shift register input of the loop that it is placed on top of.  This is completely invisible, though, and very difficult to decipher.  In my case, I tried to move that seemingly disconnected constant out of the way and inadvertantly broke the VI beahvior, because the wire was disconnected.

I've encountered this issue in particular when receiving support from NI Application Engineers using LV2012 who build sample VIs for me to test and then need to down-save them for me in LV2011. 

I propose that the "Save for Previous Version" automatically clean up the diagram for any nodes that needed to be changed/added in the down-save process (specifically to avoid overlapping and confusing nodes).