LabVIEW Idea Exchange

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

All service packs should be useable for the version you own, regardless of your SSP status. Currently, service packs are only good if you have a SSP active or had enough forethought to buy it in the middle of the year between versions.

Several users of XNET miss an important function from the driver: to read signals' logical value from the database.

For example, the value of 1 means 'Initialized', 0 means 'not initialized'. We would like to read those strings.

 

See this thread.

Changing the connector pane of a subVI requires relinking to the subVI in all callers. Until we relink (right-click...), the subVI is bleached and the caller broken.

 

When refactoring old code, subVIs often contain odd connector panes and one might want to change to a more typical pattern (e.g. 4-2-2-4), and reassign connectors to established policies (e.g. error in/out at the bottom corners). Also, sometimes there was poor planning and we need just one more connector terminal.

 

Currently, relinking to a subVI clears all "subVI node setup" settings. This is unexpected and I suggest that these settings are retained instead.

 

Example scenario:

I was working on some very old code (originally from LabVIEW 4.0 :o), and there was a single instance of an interactive subVI that was set to show the front panel when called and close afterwards ((in the subVI node setup of the caller, not in the VI itself). This subVI was interactive and required user interaction to complete. It had some odd connector pane (four horizontal terminals all the way across the icon, top as input and botton as output) and I wanted to change it to the standard 4-2-2-4 pattern. After changing the pattern, I did some switcheroo on the connectors, correctly rewired in the caller, rebuilt the app and deployed it to the PC controlling an instrument. (I could not test run locally because it required the presence of the instrument)

Bam! Triggering the subVI call no longer showed the front panel and since the caller required the subVI to return before continuing, everything was locked up. I had to kill the build executable via task manager. Now the guessing game started, trying to figure out why the app would lock up. Since I also did a few minor changes elsewhere,  It took me a while before realizing that I should maybe look at the "subVI node setup". Sure enough, all settings were cleared. These settings were retained during 20 years of version upgrades and I did not expect them to change behind he scene and without warning :D.

 

Anyone can easily verify that relinking to a subVI will clear all settings in the subVI node setup. Would anyone expect that? Probably not!

 

IDEA SUMMARY:

Relinking to a subVI should retain the existing "subVI node setup" settings.

 

The existing settings are most likely also appropriate after the connector pattern has changed. This is the expected bahavior. There is no reason to clear these settings. Thanks for your votes!

 

If there are multiple projects with the same name listed in the Recent Projects list, there's no way to determine which is which:

 

recent_project_tooltip.png

 

The idea is to display a tooltip showing the full path of the project when hovering over an entry.

In a LabVIEW built executable the Context Help window can always be forced to appear with the CTRL+H shortcut. This isn't always desirable, and indeed I'd like to be able to prevent this. Can we have an option in the Application Builder to ignore this shortcut for executables?

 

cont_help.png

It's not always desirable

In File-Explorer you can show File Properties.

Some files show only common information on the "Details" tab.

But Media files show much more Details.

I want to see there "LabVIEW Version" and "VI-Version" of VIs.

File Properties.png

Add an "Explain Error" pop-up menu on the conditional error probe.

The Generic Probe has this, why not the Conditional Probe?

 

Generic Probe:

10-9-2009 5-24-12 PM.png

 

Conditional Probe: 

 

10-9-2009 5-20-20 PM.png 

Message Edited by Michael Aivaliotis on 10-09-2009 05:27 PM

I often open a subvi while the calling vi's are open.  I make a few changes.  I try the changed code and decide I prefer original.  If I try to close the vi without saving it is not possible.  I must select "defer decision" to save.  Then when I later close the main vi, I am asked to decide whether to save the subvi or not.  By then I may have forgotten that I did not want the revisions saved or simply use the apply decision to all by mistake.  Allowing a close without saving at anytime would be most welcome.

The ability to define anonymous methods to be called multiple times within a block diagram.Capture.PNG

 

 

I have long defended NI's decision to bind the lifespan of DVRs to their creator VI but, with the addition of malleability (totally awesome) and the fix in LV 2020 that allows "New Data Value Reference" to be called directly in an inlined VI (thanks, AQ), the ephemeral auto-cleanup behavior of DVRs is now a big blocker to a reference-based strictly-typed API.

 

I want to open a strictly-typed and malleable reference and keep that reference open until I choose to close it, regardless of whether the opener leaves memory. Without malleability, I could delegate the DVR creation to another thread/VI and get the persistent reference back by callback but I can't have the home-baked persistence and the malleabilty.

Please add a persistence/auto-cleanup flag to New Data Value Reference so I that reference can persist if I want it to. (I need both the persistence and the malleability to write some really cool code.)

Persistent_DVR_idea.png

Here's an old request for this feature that was declined, but things have changed a lot since then: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Persistent-DVR-s/idc-p/2856348#M27799 

CVI has this feature, almost every other UI library has it, too.

Only LabVIEW is missing the simple option to limit the number of characters that can be entered into a string control.

 

I know, it is possible to do this programmatically. But this is always a piece of extra effort I have to undertake, while the solution never looks really satisfactory.

Usually all I can do is react to the value change event of a control and cut what's too much. But this means the user sees some flickering, since the character is first drawn and the corrected version is drawn at a later time.

 

Side notes on how I think this should be integrated:

This should be an additional property for all string controls. For existing controls from older versions, the value should be set to it's default (-1), which means unlimited.

If activated, this feature should also cut the strings in VI input terminals to avoid "special behaviours" in this case.

The idea is the same as Separate Compiled Code From Source File. When using external source code control (SCC) software like git, the user may want to track only the source code content changes. However, when every time saving the VI, the VI Revision History will be incremented. This reflects the change in VI attribute / VI properties, even though the other contents are the same.

hongcc1_0-1611440443410.png

 

This makes the commit log like git hard to trace the real change in the source code content from a high level. When using the compare VI tool, this attribute change will be one of the highlighted difference, which is quite distracting & confusing such as below:

hongcc1_0-1611439309083.png

 

I suggest this option can be disabled at the level of VI, project, or environment like the option of Seperate Compiled Code from VI. Hope it would be accepted 🙂

Today, when you create a case structure and wire a string to it, the case structure becomes case sensitive. This may have been relevant in the 1970s, when every bit was important, but these days I'm guessing that in at least 95% of the cases the structure should be case insensitive, although most people are probably not even aware that you can change it.

 

So, why not make the structure default to being case insensitive instead of case sensitive?

 

Actually, I would possibly even suggest removing the case sensitive option altogether, but this is probably required for some things and would break existing code which relies on this.

Message Edited by tst on 20.04.2010 04:43 PM

 

If code is running and one happens to leave a modal VI open, or opens a modal VI in the middle of a running piece of code, then the LabVIEW environment freezes-up and dis-allows any interaction with the code. It will be great to have a set of Key Strokes to re-set the code if this happens. The only way that I know of now is to hit [ALT + CTL + DEL] and killing the LabVIEW process. This ends up loosing unsaved work and requires a restart of LabVIEW.

 

Regards

 

Anthony L.

When I duplicate a VI inside a library or class using Save As... and check the option to add the duplicated VI to the class/library I would like the new VI to be placed in the same virtual folder as the original.  I will settle for what I asked for in the title, an additional option to perform the same.

 

SaveAsOption.png

 

                Align the upper terminal of "Swap Values"

 

SR2.png

I tried to use In Range And Coerce with a Waveform.

 

Unfortunatly this is not possible so I came up with the following alternative:

CoerceWaveform.png

 

Please make the following code possible:

CoerceWaveform2.png

The configuration panel of express VIs has the [X] disabled in the upper right, but contains standard [OK], [Cancel] and [help] buttons.

 

Every computer users is familiar with the function of the window close button [X], and for convenience it should be enabled unless there is a very good reason to disable it. Such a reason does not exist for express VI panels. Pressing the [X] should act indentically to pressing the [Cancel] button. Note that even the <esc> key is already bound to the cancel button as it should!

 

So why is [X] disabled? This is unecessary micromanagement of the user! Do it like this, not like that!!! (slap on the hand!)

 

Users should have all intuitive and typical methods available to cancel out of an express dialog:

 

  • [X] (currenty not allowed for no good reason at all!)
  • [Cancel]  (already mplemented!)
  • pressing <esc> (already implemented!)

 

Idea summary:

The configuration panel of express VIs should have the windows "close" button ([X] in the upper right) enabled and when pressed, it should act identically to the [Cancel] button on the panel.

 

IdeaCloseExpress.PNG

 

 

How many splitter bars does this VI have?

 

 

 

The answer is three, but they might not be where you think:

 

 

It would be useful if LV showed the splitter bars more clearly in edit mode. Switching to run mode would display them "correctly".

 

 

 

This idea is similar to Show hidden controls as "ghosts" in edit mode and the same basic concept can be extended further. If anyone has anything else which is difficult to see and can be shown more clearly in edit mode, why not add it as a comment?

For as long as I've been using LabVIEW, I've often turned to the LabVIEW Help file (which is a compiled HTML file) and found very little help.  I'll search for something simple like "For Loop" and receive 500 (literally, try it for yourself) possible topics, including the Cohen-Coon Autotuning Method, Control in NI-DAQmx, Limit Specification VI, and so on.  These have nothing to do with For Loops.

 

I'm proposing that the LabVIEW Help be turned into something that is ACTUALLY helpful.  I'm not sure about the best way to do this.  I think that it should still be portable and shouldn't require any Internet access to use (as lots of us cannot access the Internet on our development machines).  I would really enjoy a tool that would allow me to search for something like "For Loop" and receive like 5 topics that all have to do with using a For Loop in LabVIEW.