LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Currently, the TDMS File api does not offer a way to get the TDMS file size.

 

Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too).  To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).

 

 

Jim_Kring_0-1707938415587.png

 

I started a discussion here

 

Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project.  I never use the default icon provided by NI.  -- N-E-V-E-R --   That's a personal choice. 

 

So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless.  Let's see how many users of LabVIEW also find the default icon useless....  (Kudos would be a way to take a poll).

 

A nice feature would be to allow the developer to create her / her own default icon.  The default icon is probably somewhere in the ini file (I have not checked).  One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.

 

In my case, when creating a new VI, it ends up with a icon like this:

 

 

 

I would be happy to have a default icon that looks like this:

 

 

 

The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.

 

And may plenty of kudos adorn this thread..  🙂

 

Spoiler
 

 

Excel displays the number of selected cells.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

VS Code displays the number of selected characters.

5 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

LabVIEW should display the number of selected items in the Project Explorer.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

LabVIEW should also display the number of selected items on the block diagram and the front panel.

4 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • In the Project Explorer the functionality would be useful to count/monitor/audit the number of VIs and CTLs in a lvclass, lvlib, or in a virtual folder of these owners, etc. It would be nice to know at a glance "oh, there are 12 public VIs in this class".
  • The block diagram count functionality can become more useful in large projects and VIs. For example, I recently edited the block diagram of a VI in a DQMH-based project. The project contains 16 DQMH modules at the moment (more to be added). I wanted to check that the VI I was editing was calling the Start Module.vi public VI of each of the 16 modules (wanted to check that the VI would launch all DQMH modules). The only way to do this was to "manually" count the VIs on the block diagram. Selecting them and LabVIEW displaying "Count: 16" would have been easier.
  • In the block diagram the information displayed by LabVIEW could be more nuanced. For example, it could display the total number of items selected (subVIs, nodes, property nodes, etc), but also a breakdown based on item type: number of VIs, number of nodes, number of property nodes, etc. All these selection stats may occupy too much space for all to be displayed at once. Perhaps they could be displayed in an element that, when clicked, expands to present all the information.
  • The block diagram and front panel count functionality would enable programmers to quickly estimate the complexity of a VI. Pressing Ctrl + A on a block diagram to select all items, then looking at the selection stats would reveal the relative complexity of that VI.
  • If a whole structure is selected on the block diagram, then the count should return the count of all items contained in the diagram, not just the items displayed to the user. For example, if a case structure is selected, the number of items contained in all cases should be displayed.

Thanks

It can be difficult to go back to the Search Results window when searching for subVIs or text in a project with many open VIs.

 

It'd be great if the Search Results window had an "Always on top?" option. The screenshot below shows a possible implementation, using a tickbox.

1 (edited).png

I'd be happy for the default value of the tickbox to be false (unticked). The default behaviour would be identical to the current behaviour.

 

When the option is ticked the Search Results window would float on top of other VI windows, similar to how the Probe window floats on top.

 

This would make life easier when going back and forth between a few results, with many VIs already open, especially when so many VIs are open that all LabVIEW windows have collapsed into one tall list in the Windows taskbar.

 

This feature is not terribly impactful, but has a high benefit-to-effort ratio, due to the very small implementation effort.

 

Thanks

LabVIEW 2021 now has this pop-up, which lets you know if you still have VIs running in the background when you try to close a project: 

_carl_0-1655215157557.png

Great!  Because previously you were alerted that some VIs were still running, but not which ones. So this helps substantially with debugging.

 

However, I usually just want to abort these VIs without closing my project. There's still no (obvious) way to either open or abort these still-running VIs. That leaves me twiddling my thumbs (often for several minutes on large projects) while I close and re-open the project.

 

The request: Add the ability to either open or abort these running VIs from this window.  It could be as simple as adding an "Abort All" button...or even adding documentation on how these could be closed:

_carl_1-1655216075971.png

 

(And yes, obviously the correct solution here is for me as the developer to fix the bug that's leaving these VIs running... however, in the real world, sometimes this is either lower priority than other issues, or falls onto someone else's plate...and in the meantime you're left regularly waiting for your project to reload.)

In a simple project, the main entry point into an application is usually easy to find:

simple.png

 

However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:

complex.png

 

Proposal:

LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project. 

 

One possible implementation:

links.png

  • Display tagged items as links at the top-level of the project.
  • Links would be pinned to the top row
  • Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "WidgetTester.lvlib:GUI.lvclass:launcher.vi")
  • For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
  • In principle links could point to anything interesting, not just the main VI.
  • Double-clicking a link should open (or navigate to?) the target item

 

Right now, there's no way to easily open show a LabVIEW project file in the "native operating system file explorer" on Linux (for me on Ubuntu, that's the the Gnome "Files" Nautilus app and I can easily open a folder from a terminal/shell by executing an `open .` command).

 

Jim_Kring_0-1715216735950.png

 

Jim_Kring_2-1715216863669.png

 

Side Note: In VS Code (as described in the documentation), you can open to the location of a file or folder in the native operating system file explorer by right-clicking on a file or folder and selecting Reveal in File Explorer on Windows, Reveal in Finder on macOS, or Open Containing Folder on Linux.

Let's please add this to LabVIEW for Linux! 🙂

Many times a day I need to look at the full text of an error cluster's "source" string.

The workflow for this has always been awkward.

Additionally, "Explain Error" also requires some extra clicks.

 

What if we combined all of that functionality into the context help so that, when the user mouses over a populated error cluster with context help enabled, the user can see all the relevant information quickly?

 

ContextHelpErrors.png

Sometimes, it would be useful to view string constants as icons to save space on the block diagram.

 

1_String Constant Right Click.png

 

2_String Constant Details.png

 

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

 

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

 

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

 

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

 

It would be really nice if double-clicking column header separators in tables, trees, and multicolumn listboxes automatically resized the columns based on their contents (like Microsoft Excel). This would be useful in these types of controls and indicators at both edit and run time. It would also be useful to have this capability interactively (initiated by the developer or user) and programmatically (through properties or methods).

Problem: When developing or inheriting a large code base it is helpful to know which VI has Automatic Error Handling (AEH) enabled and which has it disabled. Currently, the quickest way to get this information is to bring up the VI Properties window (pressing Ctrl + I) and navigate to the Execution page. This is tedious when done on large numbers of VIs.

 

Solution: LabVIEW should display whether AEH is enabled or disabled on the Block Diagram. For example, a grey triangle located in the bottom-right corner of the block diagram window could indicate that AEH is disabled, and an "error green" triangle could indicate that AEH is enabled, as seen in the screenshots below. This display method is just a suggestion - professional UX designers may well find a better method. I would be happy with any indication method that I could at a glance see on the block diagram window.

 

2 Screenshot (AEH off).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 Screenshot (AEH on).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Idea expansion:

  • Executing a single left click on the triangle (or any other indication method) would toggle the setting to its other value. For example, a single left click on the grey triangle would toggle the AEH to enabled and the triangle would become green.

The default Data Directory path is set to "%Userprofile%\Documents" under windows. 

This is fine regarding custom probes, settings etc, but problematic when it comes to the compile cache and other "runtime" files.

 

In our corporate setting, this folder is always synced with onedrive AND with the roaming profile. So one problem is, that it bloats the synced volume, which by it self is annoying. But it often leads to corrupt files when onedrive blocks them or writes them in the wrong moment. 

 

So our workaround is to set this path to %programdata%\LabView Data. This, however, brings new problems, since now all users need write access to this folder.

 

I think a better way would be to save the folder under %localappdata%, but this can not be done with a symblic path and must be defined static, so it works just for one user.

 

Solution:

Provide a symbolic link to the %useroprofile% or %localappdata% folders. Additionally it would be nice, if the cache target folder could be seperately defined.

In many programs you can open/close all children (neighbours?) of a Tree node by holding control. It'd be nice it that worked in LV as well. (atleast it doesn't in 2019)

I mean 1 level down, not _all_ if there's several.

Yamaeda_0-1746618810697.png

Ctrl+click the '+' and it should open all the neighbour classes, if it's open all should be closed. 

Open the VI Properties dialog when the Control key is depressed and the VI's icon in the upper right is double-clicked.

 

Right-clicking the icon shows a pop-up menu with VI Properties, Edit Icon..., and Find All Instances. Double clicking it opens the icon editor.

At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.

 

Of course I could use CTRL+G, but I'd still need to clean up the opened windows.

 

Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.


It would save me tons of time if the search results window had a preview of the result:

Search Results Preview.png

The found item should be in the center, preferably highlighted in some way.

 

It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!


Some additional thoughts:

 

Spoiler

 I'd be OK with an image, it doesn't need to be like the DD preview in LV2020. I'd prefer to see an image even if the diagram is already opened...

 

Scrollbars might be nice?

 

The proposed image is just a quick sketch. It would need a splitter bar, and perhaps the preview should be optional?

 

A malleable VI on a block diagram can be converted from an Instance VI to a Standard VI, which I've found useful to aid debugging. Unfortunately this modifies the calling code and requires the changes to be reverted to restore the original malleable VI.

 

This idea is to provide an additional right-click option for malleable VIs - View Instance VI. This would open the instance VI in memory, and allow read-only viewing of the block diagram.

instance-vi-1.png

This is useful when examining how the Type Specialization Structure cases are being evaluated given the currently wired inputs to a malleable VI. It also offers ability to quickly view the instance VI data types, helping determine which malleable input wires are *actually* broken. In the example below LabVIEW shows all of the inputs to Stall Data Flow.vim as broken, though viewing the instance VI shows only one input is actually broken.

 

instance-vi-2.png

 

When the Instance VI is opened for viewing, it wouldn't offer any runtime debugging, but means no changes need to be made to the calling VI when performing static code analysis at edit time.

 

The ability to view instance VIs already exists in LabVIEW through VI scripting (see example below), but would be nicer to have quick access to it when right-clicking a malleable VI.

 

instance-vi-3.png

For everybody who deals with a lot of different LabVIEW versions it is difficult to handle the versions.

If you forget to select [save for previous], the code will be recompiled to the newest version.

 

There is a new feature to select the expected version in the project manager (started with LV2024). 

But there is no possibility to select a specific version for the development environment itself (eg in the menue [Tools] - [Options] - ...

Oftentimes, rearranging or reordering a Bundle by Name or Unbundle by Name for clusters can yield fewer wire crossings. For instance, below, wire crossings can be eliminated by moving "Timestamp" to the bottom of the Unbundle and "Value" second to bottom on the Bundle:

 

20985iEE7ABCE2AA5DD1B3

 

The current process of moving one of these elements:

  1. Increase the size of the node using the Resize Handles on top or bottom, or select "Add Element" from Context Menu (and hope you remember if it adds and element below or above the cell you are clicking on!
  2. Wire to the new element, and deal with deleting the old wire
  3. Delete the old accessor using either Resize Handles or "Remove Element" from Context Menu

This can be laborious. Instead, I would like a way to quickly reorder the elements. I have a few ideas how this can be accomplished:

  1. Context menu with a "Move Up" and "Move Down" action (not so elegant)
  2. A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
  3. A native drag-and drop on the Unbundle/Bundle node itself. This could be realized given the current "click regions" on the node (hover your mouse and sweep horizontally over one of these nodes... you'll discover the 4 regions). The two "Arrow" regions currently move the node on the BD, but they could be used to rearrange the node (see below)

20991iC0D9F95AD3E82BBE 

 

Just throwing out some ideas, I'm not stuck on any one. So, the idea you are voting for: Provide a User Interface for quickly rearranging elements on a Bundle or Unbundle by Name.

I wish there was a boolean text specifier for Format into String functions.

 

% followed by "?" would expect two possible strings like this. Why not?

 

boolean.png