LabVIEW Idea Exchange

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

When your certification expires, do you instantly forget everything you knew? Of course not.

 

I think the Certifications should be tied to a LabVIEW version. That way, there's an "implied age" to one's Certification (if they haven't taken a newer one), but you are still allowed to produce the Certification on cards, job interviews, etc.

 

 

CLAD logo Idea.JPG

Every day I learn something new.

 

Why do we have this?

 

Taggart_0-1660164431768.png

I used to always wonder why when I had selected NXG style controls that sometimes creating a control from a subvi terminal gave me weird styling - as in sometimes. Now I know why, but I still don't understand why. Why does this exist? Is there a valid use case? Can we just get rid of it?

 

Taggart_1-1660164571912.png

 

If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.

 

Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.

 

 

OpenWith.png

The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.

 

Currently, the markers of intensity graphs are left-aligned with the intensity pixels. This is most noticable when graphing small arrays, but is a general problem. Have a look at the left picture (x0 and dx are at the default). There is one too many markers on each axis and it is errorprone to read out the coordinates of a certain pixel because it is always betwen two adjacent markers.

 

(If we graph a 1D array with 10 elements on a plain graph with the same size (loose fit off), the axis will go from 0..9. It is misleading to show another marker at 10 in the case of the intensity graph!)

 

Correct would be to center the axis markers on the pixels as simulated in the image on the right. Now the limits are correct!

 

The problem is even more severe with cursors locked to the plot. The cursors align with the markers and thus fall right between four adjacent pixels (left) while they should be smack dab in the middle of exactly one (right). Currently, we have a 25% chance of picking the right pixel with a cursor unless we are very carefully!

 

 

Idea summary: The markers of intensity graphs need to be centered on the graph pixels. Same for cursors.

 

(...of course the same applies to intensity charts and similar)

I think the Array Element Gap should be sizable. This would facilitate lining up FP arrays with other items on the FP, or simply as a mechanism to add more apparent delineation between elements.

The size should be set in the Properties box, not by dragging the element gap with the mouse - that would add too much "cursor noise".

A new Property Node for this feature would complete Idea.

 

GapSize.png

I would like to have an option to export a simplified image of a graph directly into png. The image formats available in LV2010 are bmp, eps, emf and pict. Png is superior to bmp with rougly 100-50 times smaller file sizes. At the moment if I want to export a simplified image of a graph to png then I have to use the extra code below or alternatively export the image to clipboard, paste that into a graphics editor an save it to png. It would be much more simple to have an option to directly export to png. My suggestions below:

 

export simplified image to png.png

export simplified image to png 2.png

 

Help! I need a way to pack more Classes onto my Block Diagrams!

 

This idea is simple and quite subtle- reduce the size of the Class Constant on the Block Diagram. The majority of the footprint belongs to the Class Icon, which cannot be sized smaller, but the additional border graphic that creates the "Object Cube" effect can be reduced to give a total footprint of 42x42 pixels down from 48x48 pixels. (If you're counting, that's a 42% reduction in "fluff", discounting the 32x32 that must remain!)

 

Idea.png

 

 

If you're not crazy about the first-draft artwork, feel free to post a new rendition in the Comments section!

Hello,

Being able to rotate some indicators, controls, graphics or anything else would be great in my opinion.

Indeed, for example, when you have to represent an electrical circuit in your HMI, you must have several images of the same component with an angle of rotation of 0°/90°/-90°/180°.

So allowing a LabVIEW user to rotate some elements with an angle which could be set, would be more convenient.

 MALT.PNG

  Four images for one element. If we have 2.000 différent elements we must store 8.000 images.

 

 For Example mimic.PNG

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).

The array "Startup/Always Included" carries these Vi's into pre/post build action VI's.

The order of the vi's in this array depends on the order they have been added to/created in the project when, not the order they can be seen on the project window itself.

Here's the project window:

GICSAGM_0-1718176051948.png

Here's the order within prebuild vi:

GICSAGM_1-1718176157393.png

 

The order is NOT the same. "startup" is the first but if you delete from the project and then re-add it, it will become the last.

 

I suggest that the order in pre/post build VI should be:

first - startup.vi

following: always included vi's in the same order they appear in the project window.

 

Also, the always included list should have a 'mechanism' to change the order of the vi's in the list - be it up/down arrow buttons on the side that would move the selected vi or a similar command in a "right click" drop down menu.

 

In this way, any pre/post build action that may involve any of these vi's can be clearly defined and remain stable during the lifetime of the project without running into the risk of getting the wrong vi to "work" on or having to edit the pre/post build vi to add or edit the vi's names every time there is a change in the startup/always included list.

 

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)

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

 

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. 

 

 

I would be helpful if the Python nodes supported Python Virtual Environments. One of the powerful features of Python is able to setup multiple separate environments on a single computer, it would be LabVIEW's Python integration could also leverage this. TestStand already does have this capability, so hopefully it could be quickly/easily leveraged into LabVIEW. 😁

It would be useful if QuickDrop supported a way of dropping multiple instances of the same item in one go. It is sometimes desirable to do so. For example, we may want to drop three numeric constants in one go.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The QuickDrop action above would result in three numeric constants being dropped, as seen below.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

Selecting an error wire, then executing the sequence: Ctrl+Space >> typing "rn" >> increasing the Number of Items to x3 >> Ctrl+I would result in three property nodes being inserted into the error wire, as seen below.

4 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • It would be great if the multiplier could be typed as part of the QuickDrop search string. For example, typing "rn x3" or "x3 rn" would then drop or insert three property nodes. This would mean that the whole action can be done from the keyboard, which would be quicker. However, it seems difficult to implement due to the search string needing to be intelligently split into two parts.
  • Perhaps a much easier implementation that would be almost as quick would be to type "rn" >> press Tab (this would tab to the "Number of Instances" control) >> type "3".

 

Thanks

We've all seen the demo that shogg did where he set the color of his splitter bars to the panel color so they disappear at run time, but what if the splitter goes over background controls that you want to persist between panels?

 

22583iA7F722F2038D69E4

 

It look slike the smallest i can have my splitter bars is 2 pixels.  I totally want them to show up in edit mode, but I'd like them to be 0 pixels wide in run mode (selectable, of course).

TL;DR: the idea is please make building as fast in new LabVIEWs post 2023 Q3 as old ones when you have a clear compiled object cache and when your file timestamps have changed.

 

LabVIEW 2023 Q3 includes a major change to the app builder: 

 

LabVIEW 2023 Q3 has improved cache behavior for packed project libraries and applications.

 

The first build will populate the cache, and then the subsequent builds will be much faster.

Great! It is pretty easy to confirm this and it works! Unless...

 

1. File timestamps change - such as when you clean a directory and clone project files in your CI job

  • Git does not make file timestamps match "commit date" - when you clone fresh all the timestamps are now o'clock, when you change branches all the files that change are reset to now

2. The cache is cleared prior to the build - such as when you want a repeatable build unaffected by prior state so you set your CI jobs to clear it before each build

3. You are doing a "first build" on a new project - such as when you use a container or VM disk image to reset the entire environment to a clean state prior to your CI job

 

In all my testing, any of these conditions pretty strictly cause builds to be slower in LabVIEW 2023 Q3 than in earlier versions: with a clear cache by typically ~60%, with new timestamps and a persisted cache depends on how much of the code has new timestamps.

 

In other words, I expect most everyone using CI will find building slower in 2023 Q3+ than later versions. So, the idea is: whatever optimizations were done, include an option to revert to the old behavior - build spec, config ini, editor option, whatever.

It is time to put a dent in the floating point "problems" encountered by many in LV.  Due to the (not so?) well-known limitations of floating point representations, comparisons can often lead to surprising results.  I propose a new configuration for the comparison functions when floats are involved, call it "Compare Floats" or otherwise.  When selected, I suggest that Equals? becomes "Almost Equal?" and the icon changes to the approximately equal sign.  EqualToZero could be AlmostEqualToZero, again with appropriate icon changes.  GreaterThanorAlmostEqual, etc.

 

AlmostEqual.png

 

 

I do not think these need to be new functions on the palette, just a configuration option (Comparison Mode).  They should expose a couple of terminals for options so we can control what close means (# of sig figs, # digits, absolute difference, etc.) with reasonable defaults so most cases we do not have to worry about it.  We get all of the ease and polymorphism that comes with the built-in functions.

 

There are many ways to do this, I won't be so bold as to specify which way to go.  I am confident that any reasonable method would be a vast improvement over the current method which is hope that you are never bitten by Equals?.

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!

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.