LabVIEW Idea Exchange

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

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:

 

TimingDuringDevelopment.png

 

AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!

 

We need this:

ProposedTimingDuringDevelopment.png

 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.

 

 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

Perhaps my most obscure suggestion...

 

You can't create a build spec with the same name as an existing one regardless of capitalization:

avogadro5_0-1734658840776.png

 

But if you use a mismatched case in "<vi.lib>\AppBuilder\AB_API_Simple\Build (path).vi" you get this error:

avogadro5_1-1734658933762.png

 

So either you should be allowed to create build specs with the same letters and different capitalization, or the API should be smart enough to find the matching build spec regardless of capitalization.

Scroll bar should be disabled if all elements are visible! Kudo here to get a big bang for the buck sooner than the 2nd in TOP KUDOED IDEAS from 2013 with 600+ kudos (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Indicate-that-array-constant-contains-more-elements-than/idi-p/2299860). It points out that the scroll bars are not a viable method because it looks the same when all elements are visible. That is EASY to fix; disable the scroll bar if ALL elements are visible! Currently it is disabled only if an empty element is visible. Perhaps the behavior was originally by design like block diagram scroll bars as mentioned in the reason that the following was Declined, '...without this "boundary", it is impossible to create more space...' but constants can easily be stretched by border handles to create more elements (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-window-scroll-bars-reflect-actual-contents-of-window/idi-p/1844127).

 

dwb_0-1703104642443.png

 

 When you align a control that has increment/decrement buttons to other objects on the front panel that do not have them, LabVIEW aligns the buttons with the edge of the other controls.  The align objects command should ignore the increment decrement buttons and align the border of the control with the borders of the other controls.
 
 align.jpg
 
Workaround:  Hide Inc/Dec Buttons, align objects, Show Inc/Dec buttons.  However not as convenient.

 

 

  It would be very usefull to know which VIs are still running.

   aaaa.png

If I have a standard VI that's hung, I can highlight execution, and then drill into the hung VI (reentrant or not) to see what's going on:

_carl_0-1719594144175.png

_carl_8-1719594621558.png

 

But...if it's a class override method, I can't do this:

_carl_5-1719594530350.png

_carl_6-1719594541579.png

_carl_7-1719594559755.png

 

(There is technically an exception: If the override is not reentrant, and you guess the correct override in the popup, then you can debug it.)

 

This experience would be so much better if I could drill into the overrides seamlessly, without being prompted for which override to look at, and with the correct runtime instance of the override popping up.  This is the kind of thing where, on complex projects, this improved debugging could literally save me hours on some bugs.

 

 

 I believe the number and age of "New" ideas on this exchange renders the word meaningless. I just Kudoed an idea that was 13 years old and marked as "Status: New". This idea would be in middle school; that doesn't sound particularly new. Inaction on an idea after some amount of time should automatically trigger some other status. 

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.

The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.

 

I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.

It's not uncommon to accidentally leave a process hanging and to have a really hard time tracking it down.  Different folks seem to have made different "kill all VI" tools, but this should be a native LabVIEW feature supported by NI.  The tool should just work.  "Ctrl+." doesn't always work.  You should be able to push some shortcut that works even if you have a frozen modal dialog or whatever, and all running VIs are stopped, and log of which ones were stopped prints to the screen.

You can currently pin LabVIEW projects, VIs, and other files to the file lists in the LabVIEW start dialog as shown in the pictures below:

 

Ryan_Wright__2-1712932470451.png

Ryan_Wright__3-1712932507143.png

Ryan_Wright__4-1712932555995.png

 

It would be really nice if the Recent Projects and Recent Files menus in front panels and block diagrams automatically included the same files at the top of the menu item lists (and in the same order) as illustrated in the pictures below:

 

Ryan_Wright__5-1712933140673.png

Ryan_Wright__7-1712933697562.png

I have created NI MAX custom scales to use in a data acquisition system with a cRIO and LabVIEW.  As part of the Quality Management system at my company, I regularly calibrate instrumentation, and update these calibrations as custom scales in NI MAX.  My issue is that these calibrations/custom scales are a very important part of overall data integrity. The concern is multiple test users can gain access to NI MAX and randomly change the custom scales without knowledge of the Quality System manager, thereby compromising data integrity. Perhaps NI could look into allowing password protections of Custom Scales like they password protect the configuration of the cRIO system I am using.  This would help greatly to protect data integrity. Thanks for your consideration.

The smaller footprint of the Local Variables in 2010 has increased usability of the IDE and readability of the LabVIEW language. Another node that could benefit from a smaller footprint is the User Event Ref Constant.

 

Below is some conceptual artwork on what a smaller footprint might look like. Feel free to post more concepts!

 

21658iE20B431D386A4E45

The help page, that is supposed to provide a starting point for the developers on creating readable, high quality code in LabVIEW seems to be unchanged for quite some time: LabVIEW Style Checklist - NI.

At different workplaces (including NI) and different teams I have seen different implementations of such guides, many of which included extra "rules".

One such example is the file naming convention:

  • Using spaces for separating words.
  • Using Libraries to namespace VIs instead of including the noun in every related VI.

These are the most prominent examples I can come up with from the top of my head, but I'm sure that there are more.

 

I'm curious if an updated version exists somewhere that could be used to replace the above refenced help page?

If there is not, then I think could we collect some ideas here for updating this document.

It would be really nice if double-clicking column header separators in tables, trees, and multicolumn listboxes automatically resized the columns based on their contents (like Microsoft Excel). This would be useful in these types of controls and indicators at both edit and run time. It would also be useful to have this capability interactively (initiated by the developer or user) and programmatically (through properties or methods).

The Project page of the Project Properties window contains the Mark Existing Items... button. When pressed, this button enables the programmer to enable the "Separate Compiled Code" setting for all files in the project. This is very useful.

 

Suggestion: It would be useful to have similar functionality that could enable or disable Automatic Error Handling for all VIs in the project. This could be achieved by adding a drop-down menu that enables the programmer to select whether they want AEH to be enabled or disabled, alongside a button that enables the programmer to apply the selection for all project items, as seen below.

Screenshot (annotated).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • It may be best to add the button and drop-down menu in a new dedicated Category page named perhaps "Error Handling".
  • It would be useful to have the functionality available at a class and library level too. Meaning the ability to easily enable/disable the setting for the VIs inside a lvclass or lvlib, but not for the rest of the project.
  • The "Separate Compiled Code" and Automatic Error Handling settings are similar in that they are both Boolean settings (True/False value) that apply to each and every VI.

Many times a day I need to look at the full text of an error cluster's "source" string.

The workflow for this has always been awkward.

Additionally, "Explain Error" also requires some extra clicks.

 

What if we combined all of that functionality into the context help so that, when the user mouses over a populated error cluster with context help enabled, the user can see all the relevant information quickly?

 

ContextHelpErrors.png

In Windows File Explorer, Alt + double-click on a file or folder pops up that item's Properties page. It is equivalent to right-clicking and selecting Properties. This is a useful, time-saving keyboard shortcut/gesture.

 

The same keyboard shortcut/gesture should work in the Project Explorer. Executing the shortcut would pop up the Properties window of whichever item was double-clicked on.

 

The shortcut should work for lvclass and lvlib items, VIs, and CTLs (and possibly other item types too). For lvclass and lvlib items the Properties window would appear. For VIs and CTLs the VI Properties window would appear (equivalent to Ctrl + I).

 

Screenshot 1

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Screenshot 2

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks

When refactoring code, I often find myself in a situation where I've broken dependencies. Maybe it's a name change, or a library path change. This is precisely when I'm most in need of the ability to just replace the missing file (be it a VI, control, class, or PPL).  Yet this is when LabVIEW decides that nope, it can't be that easy:

 

_carl_1-1709776637528.png

 

Instead you have to track down every instance and manually swap them out.

 

The request: allow us to replace missing files using the "Replace with..." option.