LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Allow the user to right-click a given test result on the Results Window called "Retest", which re-runs the selected test, and if the test now passes where it previously failed, it clears it from the Results Window.

Start with this:

Right click on the selection, and select "Retest":

The VI Analyzer just retests the selected tests. And then once complete, it returns to the VI Analyzer Results Window, with the selected tests cleared from the list (assuming they passed):

View All (1)

Probing a typedef results in a vertical list showing all the fields in the cluster. Creating the typedef cluster often involves organizing the fields in a particular layout, setting units etc. It seems like probing the data and displaying it in the same format makes more sense.

For instance, I have a cluster of camera information set up as a strict typedef:

When I probe a wire of this information I get:

This cluster isn't too big so getting to all the information doesn't require a lot of searching and scrolling, but that can be an issue. What's more of a pain is that the default unit for angles is rad and I cannot mentally convert them quickly so I end up having to double-click each 'rad' label in the probe window and change them to 'deg' so I can confirm the data is what I expect.

I know I can create a custom probe to display the typedef, but having to constantly create custom probes for each cluster is a bit of a burden.

Am I missing something? Is there a good reason to NOT display the probe using the typedef?

View All (4)

If you build a PPL with a class and then probe the class wire, all you get is the name of the class, whereas probing a source class shows you its private data.

Currently the only way I'm aware of (hopefully I'm just ignorant on this matter) to see the private data is to create extra code to expose it in some form. This also often requires the PPL in question to be rebuilt which can be a huge pain when trying to debug. If the PPL is built with debugging enabled, wouldn't it make sense to show the private data contents in probes?

This idea started when I realized the WebDAV API provided by NI does not have the ability to read the File Creation information on a remote file.

"That's okay" I thought, I'm a programmer and will add it myself. Looking at the source it looks like NI just leveraged someone else's protocol, and wrapped it into some Call Library Function Nodes. NI could have written the WebDAV API wrapping their own HTTP API functions, using G instead, allowing for customization but they didn't.

"That's okay" I thought, I'm a programmer, and I'll look into recreating the WebDAV API, by calling the NI HTTP API. Looking at the source sounds like NI didn't implement all of the HTTP functions available, only the most basic ones. And since WebDAV requires more than just the PUT, GET, and POST, that means also having to update the HTTP API to have those functions, so that I can rewrite the WebDAV API. Oh but look at that, NI also just (seemingly) wrapped someone else's implementation again into Call Library Function Nodes, this time calling the ni_httpClient.dll. NI could have written the HTTP API wrapping their own TCP primitive API functions using G instead, allowing for customization but they didn't.

So this idea is for one or more of the following things, from the easiest, to the most difficult.

Add the File Creation Date, as returned information from the Get File Info of the WebDAV API.
Implement the WebDAV API in G, and eat your own dog food.
Implement the HTTP API in G, and eat your own dog food.

Format Data to String for File

Who doesn't like dumping data to CSV files? But there is a few pain points unless your data is already a string array or the same data type.

The usual way I end up doing it is formatting data to a string, then concatenating it with a delimiter. Then have to figure out if its a new file and prefix the header string. (Its also annoying open file doesn't return an empty file flag (True if New, or Replaced, or Existing AND empty)).

Then you need to add a new column of data - now there is a problem of keeping format specifier strings and header strings in sync. And then you end up with a stray delimiter so your column headers end up offset from the columns... And your format string breaks if you don't get the format code in the right place. And the data you want to dump increases until you have over 60 columns and its a nightmare maintaining long format and header strings, concatenate strings etc!

Format Cluster to String.png

It would be nice to format a cluster to a string. Optionally include the header row. For a 1D array could take its name and append the index to it.

Named Format into String.png

View All (2)

View All (1)

In vi.lib\Utility\file.llb the 'file open+.vi' throws an error when a file can't be opened. It doesn't tell which file it can't open.

One of the strenghts of LV is the source string in the error cluster that can be used to include a lot of extra information. For example which file couldn't be opened.

The change can be very simple, just add the file into the source string, also see attached file:

This is probably true for some other files here as well.

(also checking out these files... would be nice if they are updated to some newer standards... still some very old styling here...)

Some background: https://forums.ni.com/t5/LabVIEW/Looking-for-feedback-on-the-Carya-PDF-toolkit/m-p/4229342#M1228046

View All (1)

This might be a bug report; it depends on whether todays behavior is intended or not(?).

Anyway: if you have properly defined the destination of a file in your application build e.g. on Source File Settings, but then later learn that the file was not actually on the list of source files - adding it to source files will automatically change the destination(!). I suggest it should check whether the user has already defined a valid destination for it and if so keep it.

Here is a demo of the issue:

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.

View All (2)

Move front panel elements by x pixels

Display Format Glyph for Timestamps

String containers have display format Glyphs to help us understand the String Values when the display is Normal, Hex or Escape codes.

Integer numeric type containers have them too to show radix.

Timestamp containers must be inspected for their display format property to determine if they are in System Time or UTC.

Timestamp Controls, Indicators and Contsants SHOULD have a similar optional display format glyph.

This could be used instead of the misleading coercion dots when operations are performed on Timestamps as Seen Here

View All (1)

Like some other ideas here and here, I find the connector pane right-click context menu to be a burden. I would like to see some of the menu items moved or rearranged.

For example, I’ve been using LabVIEW a few years, but the first time I tried many of the shortcut menu items was today. If I were looking for them, I would probably expect to look under "Patterns".

Additionally, if I click a little to the right, three more of the menu options are already available in a much shorter context menu, so I don't feel like they are needed from the connector pane. (Personally, I rarely perform these actions through the icon, anyway, but I’m sure some people do.)

I propose removing the top few items and putting the others in the patterns sub-menu.

Something like this:

Or, if combining the text and patterns creates a UI programming issue, I think it would be acceptable to leave "Patterns" and add a new sub-menu:

Thank you for considering this idea!

-joeorbob

View All (3)

View All (1)

Right-clicking a subVI and selecting "Find all instances" is extremely useful. However there is currently no way to filter the results by a particular input or output being wired in the caller VI.

My proposal is: It would be great to be able to filter by a particular input or output, or a particular combination of inputs and outputs, being wired in the caller (i.e. being used by the caller) when using "Find all instances". There are multiple ways of exposing such a filter to the user, so I won't attempt to mock up a design here.

Background

Recently I refactored parts of a medium-size LabVIEW project that I was working with for the first time. As part of the refactoring I wanted to remove an output of an FGV-type subVI with multiple inputs and outputs, because I suspected that that output was unused by any of the callers. Using "Find all instances" I found around 60 instances where this subVI was called. I had to Ctrl + G through the results list and check that the output I wanted to remove was not used in any of the callers. This would have been simpler if I could have set a filter condition to this effect, as the search would have returned only those callers that were using that output. In this case, the search would have returned 0 results, thus confirming that the output was unused.

Side-note: You are probably thinking "You could have disconnected the output terminal from the connector pane, and used the Error List (broken run arrows) to find the broken callers." That's what I intended to do before I realised that virtually all of the caller VIs were dynamically called VIs. Therefore those VIs being broken wouldn't have broken the main VI of the app. I put those dynamically called VIs into the disabled case of a Diagram Disable Structure such that they were loaded in memory and "Find all instances" would search inside them.

Thanks

View All (3)

Background

This idea is derived from the following idea: Front panel controls and indicators should be genuine after being replaced with control or indicator of different style . Please read that thread for background.

Problem
There are three ways to replace front panel controls and indicators:
1. Right-click the control or indicator, select Replace, then select the select the object to replace with.

2. Select the control or indicator, press Ctrl + Space to bring up QuickDrop, search for the object to replace with, then press Ctrl + P.

3. Select a control or indicator and press Ctrl + X. The control will disappear from the front panel. Select another control or indicator. Press Ctrl + V. The second control is replaced by the first control.

The first two methods preserve some of the look and feel of the original object. For example, when replacing a Modern-style string control with a classic-style string control, the end result is a control that looks like a mixture between the two styles. This may or may not be desired behaviour.

The third method does not preserve any of the attributes of the object that was replaced. The end result is a control that looks exactly like the control that was selected when Ctrl + X was pressed.

Both behaviours can be desireable in different situations, and it's good that there are ways to achieve both. However, the third method is not easily discoverable.

Proposed solution

A more intuitive and discoverable solution could be: After right clicking an object, selecting Replace, and selecting the object to replace with, a two button dialogue message could popup. The message could ask something like "Preserve attributes?" The buttons' Boolean text could be "Yes" and "No".

Ideally the same popup would appear when using the QuickDrop Ctrl + Space, Ctrl + P method.

This would:

1. Enable the user to select either to preserve attributes or not, depending on their intention at that particular moment. (the same user may prefer either behaviour at different times)

2. Increase awareness that two behaviours are available

Thanks

View All (3)

When I was newer to LabVIEW, I found it hard to understand how people could identify front panel object styles e.g. NXG style string control vs System string control.

I believe it is the sort of skill that takes experience and experimentation, and it only gets more complex when the appearance of the string control is customised. For example, modifying the above controls so they are the same size, they are practically identical...

I have never been able to find a good complete documentation of the differences in appearance and behaviour between different styles of front panel object - seems each style of each type of control has their quirks. So when presented with front panel objects that you did not make yourself, it is hard to 'reverse engineer' them if changes are needed. This makes it harder to learn how to make good UIs.

A potential solution would be to add a property which tells you which style a control or indicator was created as, or most recently replaced by. E.g. modern, classic, system, silver, NXG. An extension would be to add a 'reset to default style' which would behave as if replacing the customised object with an object of that style from the palette. A further extension would be to allow changing of style e.g. in this example from NXG to System via a dropdown box, although not all front panel objects are available in all styles so I can see this being more difficult to implement.

This is probably the ugliest UI mockup you will see all day but I hope it gets the idea across and sparks some conversation:

This would be accessed via 'properties' on the right click menu of the front panel object.

I'm not very experienced with XControls, QControls etc. so would welcome suggestions about how these should behave. Perhaps there is some nuance to do with styles that I am missing.

This idea is related to this one which talks about setting style for the whole front panel.

Let me know your thoughts!

View All (5)

For Each Element in Map

I frequently perform operations on Maps of Objects which hold private data where I do not intend to alter the structure of the Map.

Existing Solution

However, Maps are a bit clunky to work with when operating on all Elements. You must first get the list of all Keys, then use an In Place Element Structure within a For Loop and Shift Registers to operate on each Element as follows:

Map In Place Element.png Potential issues with this:

Unnecessary branch of the Map which may not be optimized by the compiler
Excessive block diagram editing which slows down the development time involved when working with Maps
Potential for syntactical errors due to complexity of this operation

Proposed Solution

It would be great if there were some kind of auto-associating tunnel available to For Loops:

For Each Element in Map.png Note that the Key is not modifiable, nor is it even available within the For Loop.

Perhaps the tunnel icons must be changed so they are not confused with shift registers. I just copied the association icon from the map datatype icons.

This level of functionality is similar to the syntactical abbreviations available in most languages which support maps as a standard data type. I originally wanted this kind of functionality for Sets as well, however modifying the values may result in structural changes to the set itself due to the uniqueness constraint. As such, this is only applicable to Map Values within For Loops.

It may not be obvious, but this kind of tunnel would not be available to While loops.

Selection

AutoAssociation Context Menu.png This option would be available on the block diagram through the context menu items of the Map datatype Input Tunnel to the For Loop.

LabVIEW Idea Exchange

Add ability to retest one or more selections in the VI Analyzer Results Window

Probe of a typedef cluster should use the typedef for display

Class data in a debug enabled PPL should be probe-able

WebDAV Creation Date, HTTP and WebDAV APIs

Format Data to String for File

Cluster, Right-Click, Remove Cluster like Tab Control, etc.

Include filename in error code for file handling functions

Pin project to Getting Started window directly from project

Do not change VI Source File Setting when it is added to build source

Case Merger function

Add to private data directly from the right click menu

Move front panel elements by x pixels

Display Format Glyph for Timestamps

Toggle autoindexing with a keyboard shortcut

Clean up the items/options in the Connector Pane’s right-click context menu

Webservice Swagger/OpenAPI document generation

Ability to filter by wired inputs and/or outputs with "Find all instances"

When replacing front panel objects user should be given option to preserve attributes or not

Front Panel Object's Style is shown under its properties

For Each Element in Map

Existing Solution

Proposed Solution

Selection