LabVIEW Idea Exchange

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

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.

 

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

One of the things LabVIEW is best at is its innate parallelism. Parallelizing for loops with a right-click is something other languages wish they had. Having all code on the block diagram (or equivalent) innately run in parallel is something few other languages have even tried, much less succeeded at.

 

Crunching large datasets can be sped up through use of GPUs, and over the past decade or more, Nvidia has kept their promise of having a common interface to their hardware through CUDA. 

 

Having a LabVIEW add-on that is well maintained, and that can give GPU parallelism in the same ways we've seen LabVIEW deliver CPU parallelism would be a game changer for many labs and manufacturing environments. It could also help LabVIEW be a leader in the AI space.

 

I suggest that you create this add on package using CUDA as the underlying GPU calls, in order to keep the code easy to manage, while also providing the package for a large number of supported GPUs.

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

Hi all,

 

After some issues spending 1 week to get HTTP embedded server working in LV for a single application, I have some remarks that might trigger some need to a more flexible, simple and open HTTP configuration. The current implementation of a HTTP server is quite limited and outdated to my opinion.

First thing is the NI Web Server. This is a nice feature, however, NI recommends using it rather then the outdated Application Web Server but the problem is that this thing is only a single server running on a single port (for every application executable). Good enough for a single web server on a host using a web browser but how about implementing a LV HTTP server for each application (e.g. RPC server)? To my knowledge, every other programming language (e.g. Python, C++, ...) has a core implementation for this.

I have spent a lot of time to see what the best solution is for implementing a HTTP server belonging to a single application executable in LV. This executable is typically a application GUI or a backend service in our projects and we have a lot of them. Every application needs its own RPC server (running on a different port) and hence running its own RPC methods and I ended up implementing a Web Service using a LV Application Web Server, I can't see other ways at this moment using core LV functionality without the need for additional packages to install.

I also miss the enabling and disabling of the HTTP server during runtime. As in our project applications, we also have other transport layers for implementing RPC, such as zeroMQ (thanks to Martijn Jasperse's library on VIPM) and TCP (native built-in to LV). I would like to run only one of these transport services by configuration but here is a second problem here, once the application is running, the HTTP Web Service automatically registers and there is no controlled way for disabling it during runtime, which gives me headaches since I have to change the port number as another transport layer cannot use the same port as the HTTP server. One might say to built another application (actor based) exe and implement the Web Service from there in a different actor but this is a pain in the *** to have 2 exe's for each single application. Why can't the HTTP Web Service not switched OFF and ON again, both in development and runtime? I found a property node to disable the server but it apparently doesn't work (seems related to the native panel web server).

One of the major disadvantages that I also encountered is the HTTP methods that are programmed in a single VI and there is no way to pass data to these method VI's (like using actor framework or even classes in general). It seems we have to use FGV's (Functional Global Variables) to share data between my main application actor and these HTTP method VI's itself. Even then, the HTTP Service Request refnum is only valid in the HTTP method VI itself, once it finished executing, the refnum is flushed and not valid anymore, so no way to pass this refnum using actor framework messages to my application actors. That's quite frustrating since I have to use notifiers within the HTTP method VI's instead as a plan B backup solution signifying that the method VI can proceed and finish its execution once it Wait on Notifier function is complete (since I want to send an answer from my application actors, not from the HTTP method itself)!

Another issue I observed is that I can't "Start" the HTTP Web Service from the right-click menu in the project explorer, it simply crashes with some dubious error that the 'system is currently in an invalid state for the current message'. What does this mean, no clue from NI help docs?

 

Arrowin_0-1715670098941.png

 

I can only right-click and select "Start (Debug Server)" to make it work (but on the debug port 8001 by default). All other options just fail, the same for "Publish", it simply doesn't work in my LV2020 SP1 (32-bit) version and I have no clue why as there is not a single error message at all!

Also, why must we use MS Silverlight to control application webservers from LV? Silverlight is deprecated and I ended up using MS Edge in "Internet Explorer" mode to get the config page working (after spending another two hours to find out). Even then, some config panes just show up with error dialogs and no way to see active services being registered by the application HTTP web server. In the end I just used TCP View to see active services running. It is always frustrating to use third party apps to do simple things.

 

As you might notice from this message, I suffered a lot of days to figure out how to implement HTTP in a simple decent way using LV's core HTTP functionality. I wonder if this will be better using LV 2024 Q1?
If anyone has ideas on how to properly configure multiple application HTTP servers for each application on different ports while controlling itself, please share it with me. I am open to any idea's and wonder if there are other solutions for HTTP implementation (not using 3rd party packages). To my opinion, HTTP should be easy and open to configure properly in LV without a lot of current non-working Web Server issues.
Please note that I tried to reinstall the NI Web Server and other web service related stuff using NI package manager but no avail.

 

Best Regards,

Davy Anthonissen

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! 🙂

It would be useful to have a node that could be fed any wire and return the size (in bytes) of the data on that wire. In other words, the node would return the number of bytes that the wire occupies in memory.

 

1 (edited).png

 

 

 

 

 

 

For example, the node would return a value of:

  • 1 byte when fed a U8 wire
  • 2 bytes when fed a U16
  • 4 bytes when fed a I32
  • 8 bytes when fed a DBL
  • 800 bytes when fed a 1D array that contains 100 DBL elements
  • 9 bytes when fed a cluster that contains a DBL and a U8
  • 9 bytes when fed an object that contains a DBL and a U8
  • 18 bytes when fed an object that contains two other objects that occupy 9 bytes each
  • and so on

Notes

  • The node would would enhance LabVIEW programmers' ability to monitor and audit memory usage.
  • The node may serve as an additional tool to detect memory leaks (by repeatedly calling the VI on the same wire and checking whether the size is going up).
  • The node would simply be interesting to programmers interested in performance and would enable programmers to learn more about LabVIEW internals.
  • The node would be useful especially to query the size of complex data structures, such as objects that contains other objects that themselves contain objects, or clusters that contain arrays, or arrays that contain clusters, or objects that contain DVRs.
  • I would be happy if the node had a second input named "Mode" (or similar). This input may be a typedef enum with items named "Shallow Measurement" and "Deep Measurement" (or similar). This input could be required, recommended, or optional.
    • When "Shallow Measurement" mode is selected, the node would return the size of all the by-value data fields in the main input wire, but would not add up the size of data referenced by DVRs or other references. For example, a wire that contains a cluster that contains a DBL, a U8, and a DVR would return perhaps 13 bytes (8 + 1 + presumably 4 bytes for the DVR reference itself). It would not add to the result the size of the data referenced by the DVR.
    • When "Deep Measurement" is selected, the node would recursively scan all data structures, including DVRs and other references.
  • In both "Shallow Measurement" and "Deep Measurement" modes there should be no limit to the scanning depth. In other words, if a cluster contains a cluster that contains a cluster and so on, they should all be measured regardless of the nesting depth. Similarly, if "Deep Measurement" is selected, and a DVR contains a DVR that contains a DVR and so on, the data behind all these DVRs should be added to the total.
  • When in "Deep Measurement" mode and fed a Queue reference wire, the node could perhaps return the size of all the data in the queue. In other words, the size of all the elements present in the queue.
  • Perhaps the LabVIEW compiler already uses a "Get Data Size" function internally? If such a function already exists, perhaps it would be relatively straight forward to expose it as a node in the palettes?
  • Perhaps the best location for this node would be in the Programming >> Application Control >> Memory Control palette.

2.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks!

Edited Image 1.png

Notes

  • Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
  • Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
  • This idea is somewhat related to the following idea: "Show node names when dropped" option

The LabVIEW compiler currently appears to use one core of a multi-core processor.  It would be nice if it fully utilized multiple cores to speed building of large projects, and recompilation of VIs when editing/opening source code.

Imagine you save a new VI and LabVIEW automatically creates a suitable icon based on various information, such as the VI name, library, class and documentation.

Let's be honest: The easiest way to make a large VI unreadable is to click on the “Clean Up Diagram” button (if you're smiling, that proves I'm right). My suggestion would be to give this button some artificial intelligence. Maybe give the customer the option of setting what is “good” and what is “bad” design. And if you like the challenge, let them train it themselves.

I got some code from a coworker that I'm building into an EXE.  There are a lot of references to user.lib (like 60 classes) and the folder structure that my coworker gave me makes some of the classes in user.lib too long and causes the exe to fail building.

 

I moved the stuff from user.lib to a root folder on my C drive and now I have to manually update every class because they aren't in user.lib.  Its pretty time consuming and I think just saying "Look in this directory for the missing files" would help tremendously for larger projects that need to get moved around.