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
0 Kudos

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

 

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

 

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):LabVIEW_2018-08-17_09-49-36.png

 

0 Kudos

I am currently trying to do something which is apparently impossible.

 

I want to create some code which returns a string which represents the selector of an event structure in which the code is executing.  Obviously, scripting is required for this.  While I can do this if the VI I am using for the task is used in only one event structure case (traverse for items) it doesn't work with a cloned VI.  The sub-VI reference found returns the VI definition of the non-cloned instance.  As such there is no way to actually find a specific clone.

 

The key here is that I want to have access to the "Diagram" of the event structure where the code is executing. If I would be able to drop a scripting type constant "This Diagram" which returns a reference to the Diagram similarly to what "This VI" does (but not the top-level Block Diagram, the actual diagram in which the node resides i.e. Diagram within Event structures, While loops, Sequence structures etc.), I would have all I need.  I could then parse the rest in a sub-VI and return the required string without jumping through lots of loops to get there (or not, as I am currently experiencing).

0 Kudos

Morning forum

 

Propose to have RAD utility to include a "Snapshot/Clone" function that snap the image "exactly as is" the state of the cRIO/PAC at that image creation instance; that would include the entire drive structure, configurations, bit files, network settings, etc. Restoring from such type of image onto the cRIO will, without fail, guarantees its functionality (at least back to the state the image is created).

 

This come after the 2nd time of suspected corruption, when I deployed with error in LV causing irreversible/permanent impairment to my deployed RT application. First time being without a backup, that led me to reformat, reinstall and redeploy for one mistake in deployment. Second time being with a backup, apparently incomplete image using the RAD16 (http://www.ni.com/example/30986/en/), upon deployment failure and image restoration, the damage has not been reversed.

 

Hopefully to see this option developed soon, as the conventionally advised method of reformatting, reinstalling and redeploying cRIO, is not really practical.

 

Thanks and have a great day...

Title basically says it all but I'll elaborate.  With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well.  On a 4K monitor this is awful tiny.  This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees.  Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes, example here.  Allowing for these glyphs to grow with the row height would make them appear more cohesive.  There is a thread discussing this topic, and a work around involving an array of picture rings that is placed over the listbox control.  Here is a demo from that thread:

 

Untitled.png

This work around is fine for simple things but doesn't scale well, and doesn't support trees easily.  I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop.  Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closed is a major pain.  Please NI add a feature allowing for larger glyphs, and I would be so happy.

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

0 Kudos

The error cluster is obsolete, it's time to move on. It's 2018 we need a more flexible error output.

 

it's deeply hard-coded into LV.

 

The most hard-coded thing that is impossible to remove is that it's used as a way to force sequential instructions (error in -> error out are many times the only connectors).

 

The problem is that

  • the error codes are limited
  • dont scale.
  • cant embed additional object into it.

 

I can't use the full range of I32 as error code.

If I use error code 6400, it will clash into yours 6400 custom code.

I need a way to say : this is the error code of MyModule/Actor/class/LVLIB, that I need to "namespace" error codes

I need an additional object into error cluster, so I can carry more info.

 

So pls NI, empower error cluster with additional field: "meta error object", that we can derive/extend and use.

(In LV2017) "Browse Relationshiips\Unopened SubVIs" shows a list of icons with truncated VI names - about 12 characters per VI. When looking through a list of similar icons, one has to hover over each icon to see the full VI name.  This is impractical when hunting through tens or hundreds of SubVIs.  If unopened SubVIs could appear as an alphabetically-sorted list of VI names, it would be very helpful.

 

 

 

When creating a LabVIEW installer, in the Source File Settings dialog, I might change the attributes of several files in the same way.  For example, I might make many files read-only and/or hidden.  Currently, I have to click on each file and change its attributes.  I would like to be able to choose multiple files (either by highlight, control-click, etc.) and change their attributes at the same time to the same setting.

 

 

Pulido Technologies LLC

The ability to define anonymous methods to be called multiple times within a block diagram.Capture.PNG

 

 

0 Kudos

A common problem for usesrs is attaching additional input devices (eg. touch panels, keyboards, ...), to LV-based systems (including embedded controllers), but yet LV seems to miss an generic API/binding for that.

 

In Linux world (and BSD, too) we have standard APIs for that. On kernel side, there is evdev, which has lots of drivers for quite any kind of input devices you could buy (and easy to extent for new, even selfmade devices). In userland, there's an small wrapper library - libevdev - which encapsulates the platform/kernel specific stuff and is easily portable to other OS'es (eg. there's already a BSD port, Win32 and MacOS ports shouldn't be a big deal either).

 

This library could be directly called from a VI. This VI could also exist in several specific (and potentially highly optimized) versions, to Labview users have a generic API handling input devices (such as standard USB HID class) in LV.

Ever tried to parallelize a loop?

You just have to place your mouse over what feels an approximately 1 pixel wide area on the left side of your loop and press the right mouse-button without moving the mouse. If there was no input or case terminal around a context menu opens that gives you access to the function you need.

Point anywhere else and the contect menu doesn't contain what you need.

 

The context menu entry could also show if the mouse hovers over any other parts of the loop as well to make the area easier to point at.

0 Kudos

The current version of the Ethernet/IP tool kit 781656-35 only functions as an adapter. I need it to also function as a scanner. Specifically to take control  of the point I/O module 1734-AENT module of the Allen Bradley RSlogix 5000 PLC. I need the Labview to replace the PLC RS l5000 logix software. I still want to use the Point IO modules.

0 Kudos

When passing a control reference to a sub vi , it would be nice to be able to map ALL properties to the taget control in one hit rather than individually setting each property in turn from the reference.

Good day forum

 

Proposal: add "retain value if unwired" option to shift registers. particularly useful to reduce wire clutter inside and outside of loops.LIX.png

Have a great day

 

 

0 Kudos

The "All Recent Files" list on the opening LabVIEW (2015) window is convenient but the order is inconvenient. All .lvproj files are at the top and .vi files at the bottom. Once we open 7 projects the most recent VIs are pushed down out of sight. Since it is a "Recent" files list, it should be sorted chronologically so that if a VI was opened last it is at the top of the list.

0 Kudos

it would be great if adobe reader was built into the additional installers section of the project installer build.

i would think this would be a common thing users end up installing sperately

 

 

0 Kudos

'Database Variant To Data' cannot be placed in an inline enabled VI making it impossible to use in malleable VIs. 

It would be nice to be able to draw on the power of the 'Database Variant To Data' VI in malleable VIs so we could be more flexible when writing database related code.

 

Please make this possible or offer a workaround (like the polymorphic instances of the VI).

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!

0 Kudos

How about an NXG home edition, so folks can try it without any heavy time or cash commitment. It would help acceptance and uptake in the LabView community.

Scalar multiplication is commutative.  (demo)

It is axiom that "a * b = b * a" if "a" and "b" are scalars.

 

Scalar addition is commutative too.

It is axiom that "a + b = b + a" if "a" and "b" are scalars.

 

If the diagram cleanup recognized such a thing, then it could switch leads on a multiply icon to undo a crossed wire, without changing anything in the function.  I tried it, and to my poor ability to tell, it seems to not be undoing the wire-crossings that it could clean up.  There are plenty of things that do commutate, and if re-arranging inputs was enabled for them, then cleaner diagrams could be  made.