LabVIEW Idea Exchange

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

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

I would like to see improvements made to LVCompare and LVMerge which allow better git difftool and mergetool integration.

Namely

  • Return/Close process only after comparison or merge are finished
  • Handle both path separators (forward slash "/" and backslash "\") simultaneousely
  • Handle paths relative to calling directory

We use NIRG a lot, and I'd like to move away from what looks like random free text on the block diagram to a text block that's instantly recognizable as a requirement.  Kind-of related to this idea, but specific to NIRG.

Currently, when you programmatically build an application using the "Build" VI of the App Builder API, you have no feedback (such as build details, progress percentage, warnings, errors...) and no ability to cancel while it builds.

So you have no idea how long it will take to build and cannot cancel if it takes too long.

 

It would be great to have these interactions, just like with the manual build:

raphschru_1-1664575565945.png

 

The Build VI could have 2 notifiers or user events as additional inputs:

- 1 to receive build details, progress percentage, warnings and errors

- 1 to send the Cancel command

 

These additional inputs would be optional and default to invalid refnums, which would mean "do not use the feature".

Currently I use LabView through a Windows VirtualBox on a Linux Mint machine. I was told by a customer support employee that I should bring this idea to this forum. I chose this method because of the limited support for Linux even with the supported distro discs. I encourage NI to expand their Linux-compatible software to have the full capabilities that the Windows and Mac versions do for the distros that are currently out, and to expand the number of distros supported. Linux Mint is one of the most widely used flavors, and yet there is no support from NI.

As a new adopter of the Unit Tetst Framework I was keen to export my UTF Results from the Result dialogue for use in an external test report (Word document).

The Save button creates a datalog file only suitable for Loading back into the same dialogue. There's no immediately obvious way to export your results in a readable format.

 

After scrutiny and assistance I found that you can configure automatic creation of HTML, ATML and ASCII formatted reports by changing your Project settings. Hmm. Not quite what I want.

 

I want to be able to quickly and immediately export my UTF Results to Clipboard or File in my chosen format from the UTF Results dialogue please.

 

UTF_Report_Export.png

When Creating a LabVIEW Development Tool and Integrating into the LabVIEW Menus, placing items in the LabVIEW\wizard folder causes them to appear in the File>> menu of LabVIEW. However, there's a known issue that custom menu items in the wizard directory will be displayed in the "File" menu for VIs, but not for projects or in the Getting Started window.  IMO, this is a bug. However, I'm guessing that to get this fixed, we should call it an "idea" that needs implementing 🙂  Either way, it would improve the ability of add-on developers to extend LabVIEW.

 

My "idea":

 

Item's placed in LabVIEW\wizard folder should show in File>> menu of LabVIEW Project Explorer and Getting Started windows (just like it does for VIs).

Quick Drop plugin VIs can currently be assigned to Ctrl-Key shortcuts.  This is a great way to quickly invoke the plugins that I use most.  However, it effectively limits the number of available plugins to 26, and it makes it fairly difficult to remember which Ctrl keys correspond to which plugins when there are a lot of custom plugins to choose from.  I would like the option to invoke Quick Drop plugins with multicharacter shortcut strings, the same way I can drop common panel and diagram objects with shortcut strings.  One possible way to do this could be to allow plugins to be included with the other shortcut objects in the Front Panel or Block Diagram shortcuts:

 

QD Shortcuts.png

I know we have some ways to personalize the Getting Started window but to my taste, it's not enough!

What exists right now could be integrated into a SubPanel to keep the same functionality and that would also let anyone make it's own little plugin into this windows.

 

Here's a little example :

 

gsw.PNG

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.

Support the loading and use of dotnet core libraries.  They are cross platform and could provide functionality for both Windows, Linux and Mac users and there is so much code that we could begin to bring into the ecosystem.  

In Enthought's python integration toolkit (PITL), the "Open python session" VI accepted as an input the path to the python.exe file to use for the python kernel. In LV2019  the "Open python session" accepts a string "2.7" or "3.6", and then labview searches the system path to find the python installation.  The LV2019 method is vastly inferior to the PITL method. Due to the way the LV python node requires one to manipulate the system path in order to find the desired python installation, I realized that this is a complete non-starter for sending compiled applications to end users, because the end user may have multiple python installations on their computer, and I can’t expect them to bend over backwards just to be able to use my compiled LV app.

 

I do not know how NXG currently handles this, but I hope that they emulate the PITL method. Furthermore, it would be great if NXG could handle arbitrary python distribution, such as Anaconda, rather than just the bare bones installation from python.org. It would also be great if there was more documentation about the python node in general--there is very little to be found currently. The Labview python node is shrouded in mystery (e.g. what the heck is NIPythonInterface.exe) whereas the PITL was very self-explanatory. It is a shame that NI displaced such a useful product and replaced it with an inferior one.

Hello all! 

The standard LabVIEW plugins are great but operate based on Ctrl + Key shortcut. This means that after a while almost all of your keybord keys can be occupied by a shortcut.

 

Please add an interface for defining commands in the QD ComboBox, which could be used as a more extensible option over single keys.

 

Example - a Dialog command could be invoked like this:

Ctrl+Space -> Dialog Text -> Ctrl + CCtrl+Space -> Dialog Text -> Ctrl + C

 

Example community package implementing this can be found here: https://forums.ni.com/t5/Quick-Drop-Enthusiasts/Class-QD-Plugin-Package/gpm-p/3992772

 

Thank you!

It would be helpful to have Refresh Palettes operation as part of the built-in Command Line Operations. This would help fill in the NI Package's short coming of not having palette tools like VI Package Manager. My suggestion is the Operation Name to be RefreshPalettes and require any additional arguments.

This is something that started as a way to get data back from Actors in non-actor code (for example, web services). I've never cared for the blocking nature of Reply Msgs and the only other built-in option for getting back data is to make everything an Actor, which is not always an option. Promises solve both of those issues.

 

The basic idea is an enforced single-writer, many-reader cross thread datatype. In the current implementation, they are not much more than a locked-down, single element queue but you can actually do some pretty cool stuff with just that.

 

In the message sender, we create the promise and return it. The idea here is that the Actor owns the promise and will fulfill it. This gives us very low coupling for free.

Actor_Example_lvlib_Start_Long_Running_Process_Msg_lvclass_Send_Start_Long_Running_Processd.png
Wait on Promise will wait for the Promise to be fulfilled. It is a malleable VI so that a Default Value (for timeout) and Type can be wired. Using the timeout lets us do other things while waiting for data.

Actor_Example_lvlib_Launcherd.png
Inside the Actor, we can set the value with Fulfill Promise. Remember, once the Promise is set, that's it, no changing it again. In fact, Fulfill Promise will error out if called twice on the same promise.

Fulfill Promise.PNG
Something else really cool we can do is fulfill a promise with another promise. This may seem pedantic at first but it can help keep your code cohesive by passing the responsibility of fulfilling a Promise to another process. For example, if you have a message broker that just forwards a message, you can have the message broker fulfill it's promise to the caller with a promise from the callee.

Fulfill with Promise.PNG
We can also reject a promise with an error message that will be returned by any Wait on Promise that tries to read it. Rejecting a promise does fulfill the promise so you still cannot set the value later and you cannot reject a promise again.

Reject Promise.PNG
Finally, we have Destroy Promise. It does exactly what it says on the tin.

 Destroy Promise.PNG


I'd love to hit some more of the design points from https://promisesaplus.com/ (mainly adding Then callbacks) but I figure it's at a pretty good spot to share and get some feedback. I'd also like to try to figure out network communication at some point but that's probably a ways away (without some help anyway Smiley Wink).

 

I'm hosting the code at https://github.com/kgullion/LabVIEW-Promise if you are interested in checking it out or contributing!

As described here, LabVIEW will call certain event callback VIs when certain things happen such as LabVIEW startup or shutdown, creating a new VI, or calling Edit > Create SubVI.  The only problem is that there can only be one Callback VI per LabVIEW installation.  My suggestion is to allow more than one callback VI to be called when the events happen.  This can be useful if LabVIEW add-ons would like to implement the functionality without interfering with existing callback VIs.  

 

This is similar to my previous idea, but generalized for all the callback VIs.   

I suggest that LabVIEW Call Library Function Node added automatically identify input and output port functions. And automatically named. This function can save the queryinput and output ports of the time, speed up the development process. Or the same as this Express function:

No "parameters" page.


That's my want!

How comes these 2 palettes avec merged in one called "Vision and Motion"?

 

I'd rather have a Vision palette and a Motion palette.

Plus, if you only install Vision (and not Motion) then the palette name is "Vision and Motion" but in fact it only contains vision functions, so the palette name is inadequate.

 

See here :

Clipboard02.png

I'm working on large AF projects and I want to be able to pack my actors into lvlibps as there are lots of benefits of using PPLs. However, I'm a bit uneasy about distributing the PPLs with the executable because it's possible to reuse the public methods in a PPL. (The software I write is mostly licensable, but it would still be possible for competitor companies to reuse the public APIs)

 

What I would like is a way of securing/encrypting PPLs when distributing the executable.

I really like using VIMs; however, I have been having a lot of issues when saving for previous versions / VIM based bugs.

 

What I would like is a right-click (under the advanced tag) to convert VIM to VI copy (which you could then save) and a 'tools>Advanced>replace all VIM instances in the project' tool.

 

I attempted to make this myself, but it turns out the 'Replace' scripting method doesn't work with VIMs and I don't really want to go down the route of deleting, placing, rewiring.

 

So either, could I suggest creating the tool, or providing the scripting functions for us to create the tool.

 

NB: This is the proof of concept I was trying out to change VIMs to VIs:

Order of operation:

  1. Get a reference to SubVIs and filter for VIMs
  2. Create a copy of the VIM and save as a VI
  3. Replace VIM with new VI

Converting VIM to VI.png