LabVIEW Idea Exchange

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

It takes me too much time recognizing to which class and library this opened VI is belonging to. This is espacially the case when working with LVOOP, having the same VI in different classes.

A subtle improvement would be to have bold colons or 1.5x space between colons and path components in order to improve readability.
Quiztus2_0-1718216652456.png

One of the most over-looked LabVIEW VI Properties, mentioned in all of the "Good LabVIEW Coding Practices", is the one called "Documentation", where you describe what the VI does, and its Inputs and Outputs (at a minimum).  [NI Examples are certainly guilty of this].

 

I've been trying (and mostly succeeding) to ensure that every VI I write has such Documentation.  Sometimes I make a mis-type, highlight "bad" parts, and hit the "Delete" (or backspace), then say "Oops, erased too much, let's undo that with ^Z".  Except there is no Undo, or at least it isn't bound to ^Z here.

 

I can find no other place in LabVIEW that doesn't allow ^Z to replace deleted text.  It works in String Constants, in Labels (whether Free Labels or names for Controls/Indicators), and other places.

 

To encourage LabVIEW Developers to use the Documentation property, can you please allow us to "undo a boo-boo" with ^Z?

 

Bob "Imperfect" Schor

Ther are 10 pages of suggestions coming up when typing "probe location on wire".

AFAIK, none of them addresses this irritating behavior of probes:

 

Screen Shot 2015-04-24 at 18.07.18.png

 

The probe icon will snap to some algorithmically determined location which might result in illegible data flow during debugging, or might end up in a region of the diagram far from where the critical action takes place.

I know that what matters should be the VALUE of the probe, but WHEN to check the probe value is also critical, and in a visual development environment, this time is determined by monitoring the data flow (among other methods). This is where this uncontrollable probe location can be annoying at times.

 

My suggestion: just as for labels, let the user choose the location of a probe anchor point on a wire (especially when it branches off).

Unlike the scales of numeric controls, graph scales don't support text labels (wouldn't that be cool! :smileywink: ) *(see footnote)

 

It could be handled very similar to the way text labels are handled for the scales of numeric controls, so most of the code is already there.

 

This would come in very handy for e.g. histograms or bar graphs, where each bar needs a text label, or for cases where we have arbitrary units.

 

Examples for integer scales: 

  • "January", "February", ...
  • "LabVIEW users", "CVI Users" ...
  • "Europe", "Asia", ...

 

Examples for floating point scales (x, or y):

  • "Too cold", "cold", "warm", "hot", "too hot"...
  • "small", "medium", "large", ...
  • "min", "max"...
  • "high frequrency", "low frequency"...

 

*My quote from this old discussion . See also Ben's example further down.

Jim_Kring_0-1607714897568.png

 

Problem Statement

Sometimes, you may want to delete files that are read-only. The Delete primitive outputs an error (Error 😎 when you try to delete a File that's set to read-only. One then has to change the file permissions to writable and retry deleting it. That's a pain. What's even more painful is when you try to delete a folder, recursively, with the Delete function -- passing it a folder path and setting Recursive to TRUE.  In this case, if even a single file inside the folder is set to read-only, then the recursive delete will fail -- now, the developer has to do their own recursion to find the file that's read-only, mark it as writeable and then delete it. OK, convinced this is a pain?  Here's the solution...

Jim_Kring_1-1607715044205.png

 

 

Proposed Solution

Add an input called "Ignore Read-Only" to the "Delete" function that will do all this form me.

 

Note

The OpenG Delete Recursive VI (in the OpenG File Library) has such a feature already. I was excited when LabVIEW implemented a recursive delete and I started using it all over the place (it's nice to write code that doesn't depend on external libraries, when possible) and then... I got bit by this limitation in some random corner cases where files had gotten marked as read-only.

 

Jim_Kring_2-1607715080073.png

 

 

Wire : Right Click --> Visbile --> Label  (Its void Now )

 

1.png                                  2.png

 

Solution : It can take the control Name as default label of the wire,  instead of  being Void

 

 

3.png

 

Not sure if this idea is already proposed. 

 

 

The list of available LabVIEW modules and device drivers is very long. Their names tend to be long too, which is compounded by the many levels of nesting. Modern screens are large.

 

Given all that, why are we selecting software components by scrolling around a tiny window which can't be expanded?

 

tinyinstaller.png

(Note: most of the trees above aren't exen opened yet!)

 

 

Proposal: Make the window bigger (vertically and horizontally), or resizeable, or both.

 

Thanks for listening!

Often when I want to look at the structure of a complex data type containing nested typedefs, I find the data type description in the Context Help quite heavy/verbose.

 

For example, could you tell at first glance how many levels of hierarchy there are in this data structure ?

 

raphschru_2-1700832707643.png

 

Well, actually there are 5 levels (including the root cluster), but this is obfuscated by the unnecessary levels added by typedefs.

The description could be much more concise:

 

raphschru_3-1700833121443.png

 

Here is an alternative that keeps the typedef type descriptions and appends them after the typedef name. However I'm not sure about this one because it could create description texts that are too long to be displayed in a single line:

 

raphschru_4-1700834723096.png

 

Also for the configuration, it could be an option in "Options > Environment" and/or a button in the Context Help:

 

raphschru_7-1700835928603.png

 

What are your thoughts ?

 

Raphaël.

Today, when you change a numeric control not to use the default limits, it allows you to enter your new limits, but it doesn't actually respect them unless you change the response control on the right side, which can be easy to forget.

 

I propose that the default value of the controls should be "Coerce", not "Ignore":

 

Default to Coerce.png

 

 

This makes sense, because if the user unchecked the check box, they probably want the limits to coerce and in case they don't, the limits already default to the maximum range of the data type, so they can't be coerced unless the user changes the limit value anyway.

 

I would also suggest considering that if the Response control is set to Ignore, the value should be disabled and greyed, to inform the user that changing it won't actually do anything. I would suggest getting rid of the Response control entirely, but it can be relevant if you only want to change some of the limits.

 

I would also consider changing the coercion of the Increment to Nearest by default, since it's probably the most common option, but that could be debated.

I searched but didn't see this idea yet. I'm surprised it hasn't already been suggested.

 

The idea is to add a "Build Set" to the Tunnel Mode menu:

 

BertMcMahan_0-1628094318032.png

 

 

Right now we have to build an array in the loop, then convert it with another loop. A native menu option, with the ability to keep the Conditional checkbox, would be very useful.

 

(Similar thread: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-native-functions-to-convert-between-1D-Arrays-and-Sets/idi-p/4019595)

When I use an event structure, the case I use about 99% of the time is "Value Changed".  This is a bit of a pain since it is alphabetically at the bottom of the list, so I have to scroll down the list every time to select the event.

 

Since I suspect most people use this event the most, I would like it to be the default value when defining an event.  This way, I could just select the control and be on my way!

 

Bruce

Currently the default front panel Alignment Grid Size is 12 pixels. It should be 10 pixels.

 

There is probably a reason why 12 pixels was selected many years ago, but is that reason still valid? Twelve pixels seems like an arbitrary number. Ten pixels would be more logical because is aligned with the decimal system.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks

Compared to plain terminals and references (for example), local and global variables are too big. They waste way too much space on a bulky frame.

 

In my applications, local variables often come in large groups (e.g. if I need to write values from a file to a group of controls inside a case to load a different default set for the controls) and I tend to partially overlap the locals to save diagram space. I would prefer a more economical design, e.g. as shown on the right.

 

Globals could have that little globe (not shown).

 

I am not sure if we really need to encode read vs. write in the frame thickness like for terminals, but it could easily be done by making the frame of the "write" versions thinner (same outer dimensions). I think the little triangle is enough to show the direction.

 

Message Edited by altenbach on 08-15-2009 09:31 AM
As mentioned here, "I lost count of the times where I have a cluster or enum constant that I want to make into a type def and have to first change it into a control, switch to the FP, and then select customize" - it'd be great to be able to right-click on a constand (like a cluster) on the block diagram and select Advanced -> Make Type Def (of course, you'd need to save the type def somewhere).

Even though I use the tools selection in the automatic mode, many times I need some specific tool not accessible in the automatic mode or force one like "Position/Size/Select". Sometimes, mostly designing User Interfaces (UI) that takes all screen, we got the Tools Palette blocking access to something. Then we move the Tools Palette until it get in front of something else.

 

The idea is to have an option to have all buttons in the toolbar. Some programs allows you "dock" just dragging the over the tool bar.

 

Many times we have plenty of space to have all buttons there, if not, we can have a second row of buttons. That will be nice to add more buttons as we wish.

 

tools palette buttons in the toolbar.png

 

PS: I added a swap button between the foreground and background colors. The idea is explained in this thread Swap Colors in Tools Palette.

Add another option to the Search Scope to Ignore VIs in user.lib

That's it!!  😁

Search Scope - user.libSearch Scope - user.lib

This is a follow on to this idea. After terminals are wired to growable nodes. Make it easier to move and reorder the terminals. The switcharoo tool exists if there are only two terminals but it is difficult if there are more. 

I suggest making it easier with a keyboard/mouse combination or mouse long hold or something like that, to select a terminal. Then let the user drag it to another terminal and drop it. If that terminal is wired swap the selected wire and the one dropped over. If not wired, move the wire connection to the terminal dropped over. 

Hi folks,

 

While disconnecting terminals, the amount of context menu selections can be cumbersome.

I'd like to propose that for disconnecting a terminal it'd be nice just hold down ALT or another key, followed by a left click to disconnect a terminal.

 

That would save users from repeatedly doing this:

Disconnect this Terminal.png

 

Thank you,

 

Mr. Jim

 

Provide a growable merge errors.

 

Replace This:

MergeError.png

By This:

 

MergeErrorGrowable.png

 

Note : I have already done this with XNODE. But since XNODE are not available, I can't use it in my project.

Quick Drop (Ctrl+Space) should support replacement (Ctrl+P) on the block diagram terminal as well as the front panel icon. The front panel icon can be selected and replaced with another .lvclass but if its block diagram terminal is selected the replace does nothing.

QDP.jpg