LabVIEW Idea Exchange

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

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

Bug replication steps:

  • Ensure that the "Connector pane terminals default to Required" option is ticked (found in Tools >> Options >> Front Panel).
  • Connect an indicator to a VI's connector pane.
  • Right-click the indicator and select "Change to Control".
  • The indicator changes to a control, but the connector pane terminal is Recommended. It should be Required (should obey the environment setting).

Notes

  • Mis-connecting an indicator to the connector pane while believing it is a control can occur moderately frequently, especially when working with front panel elements that do not look very different when they are controls vs. indicators, for example: variants, objects, typedef clusters, system-style strings or paths.

1 (edited).png

A number of people, myself included, have found it necessary to parse ISO-8601 time strings into time values. The ISO standard has a lot of options, so a complete solution is pretty time-consuming. It would be nice if the string parsing functions in LabVIEW included a format specifier that allowed parsing of ISO-8601 time strings directly.

 

                                            "Build Path" should be Growable

 

                              something like this,

 

 

toto.png

Problem: Many native VIs use the Non-reentrant execution reentrancy setting.

 

Solution: The vast majority of native VIs should use the Preallocated clone reentrancy setting.

  • The native VIs that need to use Non-reentrant or Shared clone are few and far between - they should be identified on a case-by-case basis. Their Context Help and/or Detailed Help should explain why they need to be set to Non-reentrant or Shared clone.

The following is a selection of vi.lib VIs that should use Preallocated clone. This selection is meant to serve as a starting point and is not comprehensive.

 

1.png

2.png

3.png

 

Notes:

  • This idea is related to: The reentrancy of new VIs should be "Preallocated clone" . They both argue in favour of using the Preallocated clone setting more.
  • A significant number of native VIs are already configured to use Preallocated clone, which is great.
  • There are curious cases where closely related VIs are set to different reentrancy settings. For example, Color to RGB.vi is rightly using Preallocated clone, while RGB to Color.vi is Non-reentrant. Similarly, Trim Whitespace.vi is rightly Preallocated clone, while Normalize End Of Line.vi - which lives next to it on the String palette - is Non-reentrant.
    • This suggest that the reentrancy setting of some native VIs was chosen haphazardly. This needs to be rectified.
  • The fact that so many native VIs are non-reentrant partly defeats LabVIEW's remarkable ability to create parallel code easily. Loops that are supposed to be parallel and independent are in fact dependent on each other when they use multiple instances of these non-reentrant native VIs. When an application uses multiple instances of these native VIs it is as if there are "hidden semaphores" that are added between the various call locations that call these native VIs. This leads to less performant applications (more CPU cycles, longer execution time, larger EXE compiled code size).

It would be nice to have a performant way to execute an abstract represented VI.

There are currently two generic ways to execute a VI by reference:

- abstract represented but not performant (FP required, running in UI threading)

- specific represented and performant

Executing a VI currently.png

Is it possible to provide such a functionality which combines the advantages of both solutions like this?

Executing a VI proposed.png

This means, the target VI could be handled in abstract way without coupling to the specific VI connector panel.

Check out this nice readable diagram:

labels.png

Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.

 

I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either. 

Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.

 

The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??

 

Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.

 

As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.

 

Idea -->LabVIEW should also standardize here!

 

 

 

There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂

 

abort_all_running_vi.png

 

 

I understand that empty interface boxes should reflect their purpose, but this design decision wastes too much block diagram space. When using interfaces, explicit type casting is often necessary by definition. Unfortunately, this quickly clutters the block diagram.

Quiztus2_0-1747037507652.png

 

I may want to use it 0-5% of the time.

However, I want to scroll through cases in a structure 95% of the time.

 

Making the 5% use case the default (ctrl-scroll) was a bad design choice.

Reverse it before it's ingrained.

 

(ctrl-shift-scroll is frankly awkward and imagine will become painful eventually)

 

 

I would like to request that public VI properties be added for “Clear indicators when called” and “Auto handle menus at launch,” so these settings can be read and written programmatically.

For anyone that has used CAD software, you know how much of a timesaver this feature is. It is very similar to quick drop but relies more on graphical selection than keyboard input (although, these shortcuts often allow text entry as well and have a configurable menu).

 

For example, pressing the "S" key in SolidWorks pops up a contextual, configurable menu at the current cursor position that allows you to rapidly click on common operations as well as customized shortcuts.

 

I have my own janky extension to quickdrop that makes a graphical menu present after pressing multiple buttons (ctrl+space, ctrl+q, then one of WASD or a mouse click on the popup .vi front panel), but it would be nice if I didn't have to go through multiple shortcut selections to hit my toolbar-of-target. Said another way, a more extensible quickdrop-like shortcut bar would be nice. Something like the right click and shortcut keypresses for Autodesk Fusion and Solidworks are the inspiration.

It's always a pleasure to uncover shared memory problems when working with base vi.lib methods that *should* work as preallocated clones and have uninitialized shift registers and then having to establish a chain of vi references to safely call those methods in an application with distributed/parallel threads. It feels like extra work but does fix the problem. It's a major unknown gotcha unless you're already familiar with the vi you are calling.

 

My most recent hiccup: the NI PID library. I needed two closed loop controllers in actor framework, and was getting very strange timing, setpoint, process variable, and control output crossovers until I realized the stock .vi's had shared memory in the form of uninitialized shift registers (despite being in the context of a pre-allocated actor). Creating references of the vi's I needed and storing them in the actor at launch fixed the problem, but at that point the effort in writing my own PID .vi starts to be a favorable time tradeoff. At least I am able to peek under the hood of the PID library, other aspects of vi.lib... not so much.

 

Or maybe this is a teaching problem. I haven't come across ways of navigating this issue from official NI documentation, in fact the way I learned I needed to call the PID.vi by-reference was from the forum and rather matter-of-factly. There are a couple of great blogs that cover this issue in detail, so I don't feel alone in my ignorance. Maintaining State Information in LabVIEW Applications, Part 5 - LabVIEW Field Journal Archives | LabVIEW Field Journal Archives

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.

I don't use conditional disable structures very often...but when I do, I've always found it a bit annoying that I need to pull up the documentation in order to check what the available options are, and expected string formatting. For symbols with a defined list, why not expose these options through drop-downs?

 

_carl_0-1634052992681.png

 

I just realized that when creating an interface you cannot create property node folders.

 

You can see from the pictures below that option is missing from interfaces.

 

second.pngfirst.png

 

You can also see from that screenshot that it is possible to have property folders in interfaces and they work just fine. You have to edit the xml to do that, but it works. So it is implemented, it is just removed from the IDE.

 

Now I talked to Darren and he seemed to think the original reasoning was "Well property nodes are for storing things in the class private data and there is no private data with an interface, so you don't need them." I can't really argue with that logic, however, there are times when an existing class uses a property node and you want to create an interface that includes that method. For example you may have multiple instruments that have a VISA ref property. You currently can't create an interface with that "write VISA ref" VI (without editing the xml.) If you create a method with the same name/conn pane and it is not in a property folder, the compiler complains. Now you could just go back and edit the original class and remove the property node and just use a regular method. However then you break every piece of calling code that is using a property node.

 

Here is a use case, which I think is fairly common - it happens to me a lot:


I inherit some code. It is using some particular instrument (Oscope, DMM doesn't matter) They want to support another similar instrument (maybe newer version of the DMM).

 

The instrument code is wrapped in a class. Great. As a first step, I can refactor. I can create an interface that has all the same methods and make the code rely on the interface. If it is a class wrapped in a DQMH module, all I have to do is replace the object in the Shift register with the interface and somewhere set the concrete class in the initialize. It all works exactly the same as before, but now I have an interface.

 

Then I create another class that implements that interface and add some logic to pick which one - some kind of factory. Done. I've made very minimal changes to the existing code and it now supports a different instrument. This is the holy grail of OOP. I create a new class and just inject it and everything works.

 

Not so fast. NI has decided I shouldn't be able to do this if the class uses a property node (oh no!) why? I should be able to have 2 classes that both have the same property. Sure the data's not getting stored in the interface, but what does that matter?

 

It does matter to the compiler. If I want to do what I proposed above and the original developer used property nodes anywhere this doesn't work directly. I have to either do some xml hack on the interface or I have to replace all the property nodes in the calling code with subvi calls and then go edit the class and remove the property folders. Why?

 

It seems like all that is needed is enabling the right click menu, because if you manually edit the xml, it all works. That is already implemented for classes, so I imagine the fix would be rather simple.

It would be great if one could mark certain files as having an absolute path so that it is easier to move projects that use a common resource around in a multi developer/station environment.    

 

A project might for example require a shared library or file that is installed by another application into c:\XXXX

Currently, all developers must place their project at the same relative folder depth to the shared resource to avoid linking issues.  e.g If Developer A uses c:\Users\Dev A\Project\  then Developer B would need to use  c:\Users\Dev B\Project\..   The project would complain about not finding the shared resource if Dev B was to use  c:\Users\Dev B\Repos\Project instead for example.


Marking the shared files as having an absolute path would resolve this

As part of everyday class development, I often want to track down everywhere where certain class data is being used. Would be convenient if there was a shortcut for doing this...perhaps something like:

 

_carl_1-1678141878195.png