LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Preamble:

Just following up on a sub-idea raised within this recent idea from tst: LabVIEW should break VIs which have hidden code. I *almost* like tst's idea, but IMO it is a bit too heavy-handed:

YES, I want better information when there is hidden code on my diagram, but...
NO, I don't want my code to break!

The Idea:

If a structure hides code beyound it's boundary, then provide a visual indication. For example, the edge of the structure could be coloured red to alert the user that something unexpected is going on.

View All (5)

Background

The DAQmx apis allow streaming measurements to TDMS. This supports spanning multiple files (by setting the max file size for individual files in the span set), which is very useful.

We need a similar feature for files we're writing to directly (i.e. not using DAQmx) with the TDMS File functions in LabVIEW.

Note: The main reason we wanting this feature, right now, is that our files are growing quite large and when we run the TDMS Defragement function, we get out of memory errors in RT on cRIO (e.g. if we have 512MB RAM on our cRIO and the TDMS file is around the same size).

Alternatives

We're thinking to do this ourselves, however the TDMS file api does not support checking the file size from a TDMS file reference (and that's a great idea, too).

I'm not totally sure how this would be added to the TDMS file api -- maybe there could be a "TDMS Advanced Spanning" palette with options for configuring and interacting with TDMS spanning.

View All (1)

In some cases the list of context menu items extends beyond the vertical screen height (for example when creating a property for a control). The only way to scroll up or down this list using the mouse is by hovering over the small arrows at the top and bottom (and quickly moving the mouse away to stop scrolling).

This idea is to enable mouse wheel scrolling on context menus where the list of items is scrollable (the scroll arrows are visible) and the mouse pointer is hovering over the list. This allows for precise scrolling with much fewer mouse movements.

View All (5)

Increase Icon Resolution

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.

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.

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.

View All (2)

View String Constant as Icon

View All (2)

Immutable Boolean constants

I´m not to fond of the native Boolean constants and their ability to change value by just a mouse click. To me that is not a behaviour of a constant. What if Pi could be changed to e with a mouse click?

The issue is that when clicking around and cleaning up a messy diagram you may by mistake change a Boolean constant without noticing.

I would like to have native immutable Boolean constants like the ones I´ve implemented with two small VIs. My artwork is perhaps not the best, better ideas are up for anyone´s suggestion.

View All (2)

Allow user-defined default icon

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

View All (4)

Cluster Support for "Add Array Elements"

View All (4)

Add search results preview

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?

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?

When looking for unexpected behaviour in time or memory usage of a project the Profiler is useful and easier than the execution tracer, but it could be made much more useful by adding the ability to monitor for changes and analyse the issues.

Issue:
Currently detecting how the memory or run counts e.g. of a VI changes over time you have to take snapshots, save them and then compare the values in e.g. Excel. (which the saved traces do not directly fit into either...)

Proposed feature: Trends
It would be nice if you could just set the tool to automatically sample and log all/selected numbers regularly and then be able to view the trends.

Proposed feature: Automated Analysis
Having trends will help in manually detecting issues, but the profiler could also have tools that helped you in this, e.g. highlighting which VIs show a continous growth in memory. This could also then be expanded by being able to call a VI analyzer on any given VI - preferably made/set up to identify possible reasons for a memory leak e.g. (unclosed references, continous array building e.g.).

Default cases should be pure!

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.

View All (1)

I currently have a project with an auto-populating folder for documentation. That documentation is included in my Installer build specification.

If I regenerate that documentation while the project is open, the auto-populating folder sees it disappear from disk and removes it from my installer! No notification, nothing. Just completely silent. This has resulted in shipped installers with missing documentation

I propose this should work the same way any other dependency does if it disappears from disk. It should break the installer from building and show a warning sign that the dependency is missing.

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)

In LabVIEW IDE, when configuring executable build specifications, under "Version Informtion", it could be greate to have a string control to store free information depending on our version numering management (ex: alpha, beta, release candidate ...). This value could be used as a postfix to the 4 digits version (ex: version "1.3.0.1 alpha 5").

In "Details" tab of Microsoft Windows executable files, the "Product version" metadata is a string so there should be no problem.

Download All

The database toolkit is limted by the database variant to data function. It can only cast to a labview datatype as long as you wire that datatype to the type input. This means that you have to know the datatype of any SQL query in advance (or convert to string). It would be very useful if the function would also accept a variant datatype. This way it would be possible to cast any complex type into labview datatype, without the need of a predefined cluster.

Image - casting the database input with a the variant type input (circled) doesn't work

View All (1)

If you copy a group of controls/indicators from a front panel to another, the layout of their terminals on the block diagram is not maintained (instead it is typically messy...)

Vice versa: If you copy terminals from a block diagram to block diagram the block diagram remains the same, but the control layout is messed up.

Why not just keep both as they were when copying?

Bonus-idea: If you try to fix this by using the diagram clean-up function controls with the same name, but an iterative suffix (which the IDE is able to automatically generate itself as well, so it has a relation to it alread) the clean-up ignores the order of the names when ordering the controls...(so it might stack them nicely, but then control ...<n+1> is not put after/below ...<n> e.g. Perhaps it could be a bit more intelligent and include that in the ordering algorithm too?

LabVIEW Idea Exchange

Visual indication that a structure is hiding code beyond its boundary

Need "TDMS Advanced Spanning" api -- an easy way to span TDMS files and limit individual file size

Enable mouse wheel scrolling in context menus

Increase Icon Resolution

Malleable VI - Option to view Instance VI

View String Constant as Icon

Add boolean text specifier in format into string

Immutable Boolean constants

Allow user-defined default icon

Cluster Support for "Add Array Elements"

"View as Portal" for Controls and Indicators in the Block Diagram

Add search results preview

Dynamic/smart Index/scrollbar on array constants

Trends and analytical features in the Profile Performance and Memory tool

Default cases should be pure!

Build specs should NOT silently remove items if they are deleted on disk

Probe of a typedef cluster should use the typedef for display

Executable version string can have a free postfix (alpha, beta, release candidate ...)

dynamic database variant to data with variant type input

Keep block diagram layout when copying between front panels and vice versa