LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?


Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

I recommend the implementation of architectural warnings in the error log for detection of architectural mistakes. It would be nice if this could be toggled from the error log (like warnings) or had a viewer of some sort.

So far, I only have one architectural error that I’d like to catch, but I’m sure there are many others as well. Feel free to add suggestions for more architectural errors you'd like to catch.

Below I’m demonstrating the problems with bi-directional library dependence when using ppls. In this case the warning should state that: “Bi-directional dependence detected between Lib3 and Lib4”.

 

  • Initial state:
    image.pngLib4 initial state
    and
    image.pngLib3 initial state
    So we have bi-directional dependence which can only be seen through usage of multiple projects.
  • Lib3 built to Packed3 and replaces Lib3:
    image.pngLib 3 replaced with Packed3
    Everything seems fine and the replace operation worked.
  • Now look at the project used to build Packed3:
    image.pngLib3 code locked
    Lib3 depends on Lib4 but Lib4 has had a replace operation so it depends on Packed3 --> Packed3 will always be in memory --> it is no longer possible to rebuild Packed3.
    Reverse replace not possible, so manual reverse is required to fix the code again.

 

Note:

The VI hierarchy does not help at all Smiley Sad

:image.pngNo help from VI Hierarchy

Currently there are no officially supported frameworks for Unit Testing in LabVIEW for Linux.

 

A lack of a unit testing framework on LabVIEW for Linux reduces LabVIEW's usability in widely-recognized and industry standard software engineering practices.

 

A Unit Test Framework created by NI already exists, as well as a 3rd-party tool for free, VI Tester by JKI. However, neither of these are available for desktop Linux (or Macintosh).

 

NI LabVIEW Unit Test Framework Toolkit

http://sine.ni.com/nips/cds/view/p/lang/en/nid/209043

 

VI Tester - JKI

https://github.com/JKISoftware/JKI-VI-Tester/wiki 

Title says all. Can't believe it was never proposed; if it was, I couldn't find.

Missing that, I have to that programmatically, but it's always a detour:

2017-09-28_11-42-52.png

Should be quite easy to change the property page like e.g:

LabVIEW_2017-09-28_11-02-36.png

(6 colors for system booleans, 4 for all others, as known)

 

 

The current implementation for remote debugging needs two ports to be opened on a stand-alone firewall in between.

  • Port 3580 to connect to the NI service locator on the target machine
  • A random port for the application on the target to connect to
    This port is dynamically assigned to the application by asking the OS for a free one

 

This dynamic port cannot be pre-configured on the stand-alone firewall except by opening up the whole port rang above 1024.

The latter is something no IT person with any sense of security will do !

 

So we need to be able to pre-configure a certain port for the target application, so that we can open a dedicated port for this connection on the firewall as well.

Otherwise this whole remote debugging feature is useless to many companies.

 

There have been multiple cases in the last few years where customers (huge ones) have come across this issue. 

This idea came to me from Darren's Nugget 2-23-2018 on Data Agnostic Probes I thought it might be useful to write a Probe.vim or specifically, a data type malleable probe to gain the ability to have some access to the data itself in a general smart probe and maintain the ability to display the data in a type specific manner.

 

One example would be a "Data History Probe" that displays the history values of any data type.  I'm sure there are other good uses.

I would like to have the possibility to "negate" some comparison functions such as "Empty String/Path?". This can avoid to add the "Not" operator.

The picture below is a possible implementation. The dot on the input (on the output ok also) is showing the negation.

Labview Idea.png

This might be good to be implemented for the following functions:

Labview Idea 2.png

Once in a while I encounter a case or event list that forces me to grow the structure

- in order to keep the list readable:

Selector.png

It would be nice if the item-list would automatically "wrap" instead.  

Selector4.png

I've got some calls to low level VIs that rely on windows system dlls within a larger top level VI. To make that application work on Windows and Linux, I've put conditional disable structures around the dll calls. When I open the top level VI in Linux, I have to click through a bunch of "Find missing file" dialogs for the Windows system dlls. If I cancel through all the dialogs, the VI still compiles and runs correctly in Linux, so the Conditional Disable structures are doing most of what they should, but the dialogs are annoying and can cause problems with automated builds and other hands-off activities. Since the code is inside a conditional disable structure, it seems to me that LabVIEW has all the information in needs to know it shouldn't load that stuff, so it would be great to get rid of these nuisance dialogs.

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 Smiley Happy). 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.

I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds. 

image.png

The recently introduced Raspberry Pi is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).

 

The Raspberry Pi is a $35 (with Ethernet) credit card sized computer that is open hardware. The ARM chip is an Atmel ARM11 running at 700 MHz resulting in 875 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 15 times the processing power!

 

Wouldn’t it be great to programme the Raspberry Pi in LabVIEW?

When developing a Complex LabVIEW Applications, we may need to create N Number of Folders as a part of Configuration information.

This requires the developer to make a check "Check if File or Folder Exists"

Instead of that Create Folder Function can have a Boolean "Optional Input" to create the Folder only if not found in the specified Location and Eliminating the Error when trying to create same folder again.

Hope this will help Smiley Happy

 

                                            "Build Path" should be Growable

 

                              something like this,

 

 

toto.png

 

 

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

   aaaa.png

Please let me opt out from this new feature, introduced in LabVIEW 2017, permanently in the setup dialog.

Using LabVIEW for a very long time (since LabVIEW 2.0), I never wished such a feature (it got only 27 Kudoes) - and - I am even using it's "anti feature", implemented up to now, constructively to detach objects (Pull control into a structure, connect it to the new target - and "Ctrl B").

This new feature, forced onto everybody, would be less annoying, if pressing "W" would reliably disable the feature. However,  at least in vritual windows machines (Parallels) on a Mac, it does not work 50% of the time.

 

When setting up In Place Element structures, the current work flow is:

 

  • Drop the structure
  • Right click, add the node you want
  • Wire the reference / array / variant in

It would also be nice to wire the references I want to use to the border of my IPE structure, right click on the tunnel (c.f. for and while loop auto-indexing context, or shift register/tunnel) and select from a sensible list of incoming element types relevant to my incoming wire.

This would be fantastic to see alongside similar ideas such as this or this.

dvr-rcm.png

Browsing through menus to replace a numeric conversion node is tedious.  How about allowing the selector tool to select from a pull-down menu, just like it does from an unbundle by name node?

 

Existing unbundle node behavior is shown at left.  Desired numeric conversion node behavior is to the right.

 

Quick_changing_of_numeric_comments.png

Bookmarks are great.

But why not bookmark on front panel? I think at least free label with hashtag on front panel shall be listed in the bookmark manager as well. Bookmark on the front panel can be used as reminder for coming back in future.

 

Kudos?

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!

If you are using TCP to communicate to a different code environment, you may want to set some of the socket options. For example, for responsive control, you will want to disable Nagle's algorithm. There is currently no obvious or easy way to do this. TCP Get Raw Net Object.vi in <vi.lib>\utility\tcp.llb will provide the raw socket ID, but you then need to call setsockopt() on your particular platform using the call library node. You can do this with the code provide here. A much better way would be adding a property node to the TCP reference that allowed you to set and query the options directly.