LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Installers should show the public version of dependencies instead of internal versions.

This is a specific example, but I presume this behavior is more widespread: An Add-On that has a dependency on LabVIEW NXG doesn’t list the (public) version of LabVIEW NXG upon which it depends.

The OpenG Library v1.0.0.0 depends on LabVIEW NXG v1.0. But the installer indicates the version of LabVIEW NXG to be installed is v 4.9.3.49152-0+f0. To someone not familiar with the internal version numbering for LabVIEW NXG, it’s not obvious that this refers to LabVIEW NXG 1.0. This may lead someone to install an undesired version of NXG.

(I had NXG 2.0 already installed, and I assumed, incorrectly, that the version of NXG that the OpenG dependency referred to would also be NXG 2.0.)

By changing some NIPM settings (e.g., enable the "Show full version numbers and infrastructure packages" option), one can logically (but not definitively) deduce the public version that the internal version is referring to:

Review 2.png

Having a continuous integration system is an essential component of software development:

Continuous Integration Process

This system requires automating the building process.

The LabVIEW development environment unfortunately does not have built-in tools to achieve this easily.

But the community has supplied a few sollutions to achieve this: CLI Tool

On of the biggest hurdles that yet remain, is the fact that the application builder is inherently tied to the development environment.

This requires a valid license for the environment and all toolkits / technologies used in the source code of the product you intend to build.

My proposal would be to have a special "CI" license in which all required modules and toolkits are activated, and that would allow the development environment to launch in some sort of protected mode that prevents users from actively developping code (while still allowing scripting functions), for the sole purpose of building applications.

View All (3)

According to some engineers that I have spoken to in the prototyping industry, Windows 10 IoT is gaining some traction as a preferred embedded OS for developing ideas. Windows 10 IoT, as I understand it, is delivered in 3 different versions: Core, Enterprise, and Enterprise Mobile. Now where Core is built as a .NET application and lacks some of the system capabilities of Windows 10, the Enterprise version is built as a Win32 OS and is closest to Windows 10 as it is now.

If resources allow, it might be beneficial to see some future support for at least this version of Windows 10 IoT to meet the demands of a growing body of engineers who will want to integrate LabVIEW executables with their Windows 10 IoT powered devices.

After another case of this happening, I did a search, and while I found a lot of suggestions about auto-grow with regards to adding new controls via the BD "Create xxx" menu and some about adding new controls into a Tab control on the FP, I'm surprised that I didn't see any comments/suggestions about how adding a control to the FP can cause an auto-grow oops since you can't really control where the new Terminal is added to the BD.

This is a bit of a frustration for me, I'll have written part the skeleton of my code, my structures in place and sized how I want them. I then swap to the FP to start adding more specific controls, I select the controls I want on the FP palette, drop them, swap to the BD and everything is messed up because some of the controls decided they were part of various BD structures and thus resized things. This isn't just auto-grow, I've had a case where the control was dropped into a case frame and while working with another control, the visible frame was changed, and I 'lost' the control terminal. I was able to find it by swapping to the FP and using 'find terminal' but was still a pain and a bother.

My suggestion is: New terminals added via the front panel are not added to any sub-diagrams in the BP, instead of semi-mimicking their location relative to the FP, just place them near the desired location that isn't already taken up. This way, the only way a terminal is added to a sub-diagram is when the user decides to add it to the sub-diagram.

View All (3)

Different size options for VI's

The length of the right click context menue (mainly in the block diagram) increases in each new LabVIEW version. So the handling becomes more and more uncomfortable - especially because there is no eye-catcher for the different entries.

There es one program who is doing it much better: MS-Word 2013. There are much more functions in the right click menu in comparison to the LabVIEW menue but it is more comfortable and the items are easier to find because of the icons => Have a look to the picuture.

I'd like to suggest to implement a context sensitive right click menue in the style of MS Office to re-align the existing items and beeing ready for further extensions of the menue.
Beside giving the current menue entries a new style also some of the properties of the structures which are selected could be moved to this new menue (e.g. text styles, number formats, basic alignment, grouping, ...).

View All (8)

Enable LVPROJ to specify VI search path.

A "path" may override or be composited with the path specified in its parent environment (the IDE or another project).
A "path element" may be a directory or file, or a recognized LabVIEW type (lvproj, lvclass, lvlib, virtual folder, etc.) that can be resolved to a working environment directory or file.
A "path element" that resolves to a directory may be searched at just the top-level or it may be recursively searched.

If no project search path is specified, default to current VI resolution behavior.

If a project search path is specified, resolve VIs by name within the scope of that path. If resolution fails and parent scope is available (composition rather than override), search the parent scope too.

Straw use

Given ProductA dependent on, but not containing CommonLib. When CommonLib moves for arbitrary reasons, the developer shouldn't have to (tediously) reconnect each individual component referenced. It should suffice to modify ProjectA's VI search path to reflect CommonLib's unique and perhaps relative path location. Perhaps, the "Find the VI" dialog should sport an option to modify the VI search path as an alternative to specifying the precise VI.

If I'm revising a product to use Library 2, I want to be able to checkout the product based on Library 1 and then re-point the project search path to pick up VIs from Library 2. A VI should resolve in the scope (possibly upward recursive) of the project search path. If that fails, then it should prompt--relative or absolute pathing within the VI should have no precedence when project search path is specified.

A micro second wait VI

NI Community,

I have developed some applications where it was desirable to have a Wait, but 1 millisecond is just too long.

I came up with a method using the High Resoution Releative Seconds.vi, to create a delay in the microsecond range (it's attached). This works for the particular application I need it for, because I am waiting on an external buffer to be ready to accept new data (its rate it can process is 60 nanoseconds). Waiting for an entire millisecond in this case is just too long.

The downside to this method is it is tied to your processor speed and current workload. It would be great if NI supported a 'Wait Until Next us Multiple.vi (it doesn't Sleep).

Attached is my work-around. I'd love to see other ideas on this topic.

Thank you,

Dan

The built-in mouse wheel support for numeric controls is very convenient, as it allows comfortable tuning of values using the mouse wheel. But it has a potentially dangerous flaw: the default mode is "On Key Focus", which means that when you click inside the control, you can change its value by scrolling. But when they move the mouse somewhere else in the window and scroll (e.g. in order to zoom a graph), the focus stays in the numeric control, and you unintentionally change the value of the numeric control. This behavior has the potential to damage our hardware, as we are controlling high voltages and pressures using numeric controls.

Setting the Built-In Mouse Wheel Support property to "On Hover" keeps the values from changing when the mouse cursor is not above the control. But unfortunately it also changes the value when the control does not have the key focus, leading to another source of unintentional value changes.

So my suggestion is: If you add the option "On Hover AND Key Focus" to the Built-In Mouse Wheel Support property, accidental changes of values by scrolling could be prevented effectively.

This is a bit of a pet peeve of mine while programming, a tunnel placed at the midway of a structures edge will be covered by the resize handle when you want to move/select the tunnel. It would be nice if the tunnel had precidence over the resize handle on the structure, and as such would be cover the resize handle so that you could more easily access the tunnel instead of the other way around like it is now. If you need to resize the structure, there are handles at the edge of the structure, and a Ctrl press while resizing will lock the regrowth to one direction, so the center handle access really isn't as needed.

As it currently is

Would be nicer like this

SSL TLS Support

View All (2)

When developing new VIs f the procedure is usually the following:

1. right-click class or desired location, new VI (static or dynamic dispatch template etc.)

2. Implement functionallity

3. Edit VI icon for easier recognition

4. Save VI

The problem here is that usually the icon allready contains the ideal name for the VI which means I am typing the name of the VI twice, once when editing the the icon and once when saving.

Would it not reduce the development-time by suggesting the name entered in the VI icon editing procedure as the user attempts to save the VI?

I'm currently expanding a large SA with 270 classes and on good days I implement 20-30 VIs and would find it nice if I were not forced to type the name twice.

Interested what experienced LV-users think of this suggestion!?

When placing Icon Text inside a frame in the Icon Editor, there appears to be a rule that the text region is between the lowest two horizontal lines. I'm trying to design an icon with a two-line-width frame, with a lot of empty space in the middle, but this (deduced) rule stymies my efforts. I'd like to suggest that the algorithm be changed to place the Icon Text inside the largest blank space available.

Here is an illustration of the problem. All these images are a one-pixel Frame and a single line of text. In the first image, a single additional line is at the top, while in the second image, a single line is at the bottom. The final image pretty much precludes designing a Template with a two-pixel bottom border, something I'd very much like to do.

Bob "Frustrated" Schor

View All (2)

Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!

In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.

Here is a simplified example to illustrate the problem (see picture).

In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.

However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course :)). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!

What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.

The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.

Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.

(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)

Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.

I have a large library of general purpose functions and I do a lot of OOP in LabVIEW, and as a result my preferred workflow involves dragging a lot of functions from the project explorer window onto the block diagram. This workflow is slowed down, however by the fact that the project explorer window is regularly hidden by other windows when I click on them.

What I would like to see is something like most development IDEs have, e.g. Visual Studio, where I can have the project explorer always visible in a fixed position on the screen. I suggest this would be an option, so would not affect those who like things the way they currently are.

View All (1)

LabVIEW Idea Exchange

Array to Cluster (Double Click Should allow to select Cluster Size)

Show better version information for package dependencies in NI Package Manager

Dedicated License for using LabVIEW in Continuous Integration Systems

LabVIEW Support for Windows IoT Enterprise

New Controls added to FP should not be added to sub-diagrams in the BD.

Different size options for VI's

Right click context menue in MS word style - better visibility of items, less mouse movements

Enable LabVIEW project to specify VI search path...

A micro second wait VI

Built-In Mouse Wheel Support: On Hover AND Key Focus

Give tunnels precidence over resize handles on structures

SSL TLS Support

Make Save As always available on project/library items

Faster VI development by suggesting VI name as entered in icon when saving the new VI

Change placement rule for Icon Text in Icon Editor

Control tip strip input box should not accept more than max allowed number of characters

"Choose Implementation" sort order

Break bad wire branches, not the entire wire!

Free Labels to Block Diagram Constants Conversion

Allow project explorer window to be pinned