LabVIEW Idea Exchange

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

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.

 

 

This is related to this issue, https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Run-Code-Cleanup-profile-Nattify-VI-on-Save/idi-p/4291727

and is a more general request.

 

Have the ability to run custom scripting code on a save event.

 

What problem does it solve?

 

For me personally, I am working on an autoformatter. It would be nice to run that everytime something is saved. Right now I have to monitor the source folder from outside LabVIEW (using Python) and then use G-CLI to run my formatted. I'm sure there are probably other ways to do it and an onSave hook seems like the best choice. 

I'm sure there are plenty of other use cases. Perhaps some kind of linting or enforcing some sort of style guide. ie if you save a VI without a description, it won't let you unless you enter a description. Perhaps even every time you save a file, run some unit tests?

 

Ideal Solution

 

Ideally the scripting code would have access to the reference of the thing being saved. The easiest thing to envision is a VI, but why not also classes, libraries, the project itself? Maybe also some indication of what triggered the save. Was it a saveall, a save all this library, etc. Maybe if it is a saveall, you get a list of all the things being saved, before anything happens?

The IDE would then wait to continue until the scripting code completes, maybe even failing to save on an error or a boolean - not sure if that is the best behaviour as in a bug in your scripting code could cause you not to be able to save - so maybe some way to override the hook?

 

Maybe include a way to autogenerate a VI with the correct connector pane.

 

Maybe it makes sense to generalize this to add more hooks into LabVIEW? Perhaps a call to update the project provider to something more usable/less user-hostile?

The VI Properties window allows to select between local help file and Web-based Help URL.

 

Loc_fr_0-1718700568074.png

 

LabVIEW Class, Library and Project doesn't allow to use Web-based URL.

 

Loc_fr_1-1718700590702.png

 

Loc_fr_2-1718700613471.png

 

The idea is to have the same behavior for all source file.

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.

 

First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.

 

Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!

 

When is LabVIEW going to get with the times?

When using the insert quick-drop option, it works great when wiring something into a single wire.

 

However, when working with multiple wires, it just inserts a new VI on each wire. This could be improved upon to better support the standard LVOOP workflow where you'd want to pass two wires through each VI.

_carl_2-1718229032665.png

I find that this is the scenario where the quick-drop option could be most-useful, however the current implementation really isn't very useful in this scenario at the moment.

 

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

I've encountered quite a few limitations when debugging debuggable PPLs, and feel that a number of improvements could be made to this process. I often find myself having to open a second project with the specific dev library in it, and then toggling back and forth between the two which is both confusing and inefficient. This is just scratching the surface, but here are some improvements I'd like to see made:

 

  • Non-editing menu options should remain available. One I use quite commonly: right-click on a class cube, and select "Show Class Library". But it's not available:
    _carl_0-1718205041101.png
    The workaround I use is to "Copy Data", press ctrl+n to create a new VI, drop the class cube there, and then right-click on that and select "Show Class Library", then toggle back to the temporary VI and close it.
  • VI Properties aren't available in VIs:
    _carl_1-1718205311007.png
    I often want to double-check reentrancy settings on VIs to ensure everything's configured correctly.
  • Private class data isn't shown. I get why this isn't available in non-debuggable PPLs, and I understand that there's a healthy debate that can be had as to whether or not this should be available in debuggable PPLs. I'm of the opinion that private data should be available in debuggable PPLs as they are meant for debugging, not for distribution.
  • Private class methods don't show up in the project.  But if you click on the sub VI for a private method, you can open up the block diagram.  If the block diagram is accessible, it really should show up in the project. I often find myself searching for a VI in the project, and not finding it anywhere, because the method is private.
  • Unusual interactions. I've seen a number of scenarios where I'm prompted with requests that I shouldn't be asked.  For instance, if I double-click on a malleable VI in a PPL's block diagram, I get this popup:
    _carl_2-1718205991996.png

     

 

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.

 

Combined.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Benefits

  • Removes the need to use a separate Color Box Constant and Bundle By Name node when writing to VI server properties that take the LvFontTypeDef.ctl as an input.
  • More intuitive representation (a colour displayed as a visual colour rather than just a number).

Notes

  • The underlying data type of the Color Box is U32. Hopefully this means that this change would be "transparent" to the compiler. The change would affect only the visual appearance and  would improve the human interaction with this typedef cluster.

It would be useful if the Project Explorer supported a Shortcut item type.

 

  • The Shortcut item would be associated with exactly one VI, CTL, lvclass, or lvlib item that exists in the same project.
  • When the Shortcut is double-clicked the Project Explorer would perform the same action as if the referenced item itself had been double-clicked. For example, if the referenced item is a VI or CTL, then double-clicking the Shortcut would open the VI or CTL.
  • It should be possible to associate any number of Shortcuts with the same underlying item. For example, there could be two Shortcuts that refer to the same VI.
  • When the underlying item is removed from the project, Project Explorer would automatically remove all associated Shortcuts.

Use cases

  • DQMH-based projects. It may be desirable to create a virtual folder named say "DQMH Main VIs" that contains a Shortcut to the Main.vi of each DQMH module.
  • Large projects with multiple EXE build specs. It may be desirable to create a virtual folder named say "EXE Main VIs" that contains a Shortcut to the Startup VI of each EXE.

TestStand provides the extremely useful Label step type.

 

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It would be extremely useful if the LabVIEW Project Explorer provided a similar Note project item. The Note would serve as a documentation and annotation tool inside the project. Project notes would serve to explain the purpose of a group of lvlibs or lvclasses, or to provide short descriptions inside an lvlib, lvclass, or virtual folder.

 

As a workaround I currently use virtual folders to add notes to the project. By convention I name these virtual folders starting with "_Note:". The underscore helps the Note appear first (near the top) when the items are arranged by Name or by Type. By convention I never add any item inside the _Note virtual folders.

 

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The implementation of a Note item could be quite simple. A Note item would essentially be just like a virtual folder with the following modifications:

  • Different icon. An icon that resembles a document would make sense.
  • The Note item would not be able to contain any other items.

The Search Results window should contain a “Remove” button. When the button is pressed, the selected item(s) would be "removed and rewired" using the exact same implementation that operates behind the QuickDrop Ctrl + R shortcut. This functionality would be useful when refactoring codebases. Currently the quickest way to remove and rewire n instances of a subVI is to navigate to each instance (perhaps using Search Results Ctrl + G) and perform the QuickDrop Ctrl + R shortcut on each instance. The "Remove" button would enable n instances to be removed in a single bulk operation.

 

Combined.png

 

 

It's useful that we can open the Error List window via the Ctrl + L shortcut.

 

1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It would be great to have keyboard shortcuts that allowed us to navigate to the next and previous errors (broken run arrow locations). This would be similar to how Ctrl + G and Ctrl + Shift + G can be used to navigate to the next and previous result in the Search Results window.

 

I would be happy with any key combinations chosen for this purpose.

 

Thanks

The name of the "Get Date/Time in Seconds” function is misleading. The function should be renamed.

Combined v2.png

 

 

 

 

 

 

 

Details

  • The current name does not make it clear which Date/Time it is going to return. The words "now" or "current" are missing.
  • The "In Seconds" portion is misleading and unnecessary. The function correctly returns a timestamp data type. The timestamp represents a moment in time that is expressed not just in seconds, but also using lots of other time units such as days, hours, minutes, ms, us, ns, etc. I understand that when a timestamp is converted to a DBL, the value represents the fractional number of seconds since the beginning of the epoch, but this is an implementation detail. It should not be part of the name of the function.
  • “Get Date/Time in Seconds” would be a suitable name for a conversion function that takes in a formatted Date/Time string and outputs a DBL that represents the number of seconds since the beginning of the epoch.

Names of equivalent functions in other languages

  • .NET: System.DateTime.Now
  • C++: std::chrono::system_clock::now()
  • Python: datetime.now()

Notice that the equivalent function names contain the word "now" and omit "in seconds".

 

Perhaps the best new name for the function would be “Get Date/Time Now”. This name would be very much in line with the .NET, C++ and Python equivalent function names. This name would earn the "let's not reinvent the wheel" prize.

 

Nevertheless, I would be happy with the following names too:

  • “Get Timestamp Now”
  • “Get Current Date/Time”
  • “Get Current Timestamp”

Notes

  • Changing a primitive name may break VIs that use VI scripting to find or create this node. This is a downside. I believe that in this case the long-term benefits would outweigh the relatively minor annoyance of hopefully relatively few developers having to modify those scripting VIs to use the new primitive name.

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

Currently the fastest way to open the Properties page of a front panel element (control, indicator, decoration) is right-click >> Properties.

 

Holding down a modifier key (Alt, Ctrl, Shift, or a combination of these) while double-clicking on the front panel element would be quicker.

Combined.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • Opening the properties page of front panel elements is a common, repetitive task, especially when creating complex UIs where the size, colours, display format, data entry limits need to be changed.
  • Ideally the gesture would work on block diagram terminals too.
  • This idea is very similar to New keyboard shortcut: Alt + double-click to open Properties in Project Explorer. The difference is that this idea addresses opening the Properties page of front panel elements, whereas that idea addresses project items.

Currently the quickest way to open a typedef is right-click >> Open Type Def.

 

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing typedef constant or terminal (Block Diagram) or control/indicator (Front Panel) would be quicker.

Combined.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • The gesture could open the private data definition (ctl file) of a class when double-clicking on an object constant, terminal, or control/indicator.
  • Opening the typedef for inspection/modification is one of the most common actions when working with typedef clusters and enums.

Currently the fastest way to insert a Bundle By Name node into an existing cluster wire is to use the QuickDrop Ctrl + I shortcut.

 

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing cluster wire would be even quicker.

Combined.png

 

 

 

 

 

 

 

 

 

 

Notes

  • Inserting BBN nodes is a common, repetitive action when working with clusters. For example, when working inside the Message Handling Loop of a DQMH module.
  • The gesture should work for class wires too, but only if access scope rules allow it.
  • This idea is very much related to the "New gesture to create Unbundle By Name node (Ctrl + double-click when creating a cluster wire branch)". The difference is that this idea addresses inserting BBN nodes into existing wires. That idea addresses more easily terminating a new wire branch with a UBN or BBN node.

Thanks

Using "Edit Palette Set" is cumbersome and painstaking.

 

Specific use case example:   I create a class library that has an embedded menu file that I want to distribute as a compiled packed library (PPL) or even as a source code distribution for re use by other developers.     To make the mnu available in the functions palette, you have to manually recreate the menu file to link to the versions of the functions inside the distributed functions, which is painstaking for a larger library.

 

It would  really nice if we had the ability to generate or easily edit mnu files.  In the example, a simple search and replace of the paths that the functions in the palette link to would work

Right now, there's no way to easily open show a LabVIEW project file in the "native operating system file explorer" on Linux (for me on Ubuntu, that's the the Gnome "Files" Nautilus app and I can easily open a folder from a terminal/shell by executing an `open .` command).

 

Jim_Kring_0-1715216735950.png

 

Jim_Kring_2-1715216863669.png

 

Side Note: In VS Code (as described in the documentation), you can open to the location of a file or folder in the native operating system file explorer by right-clicking on a file or folder and selecting Reveal in File Explorer on Windows, Reveal in Finder on macOS, or Open Containing Folder on Linux.

Let's please add this to LabVIEW for Linux! 🙂