LabVIEW Idea Exchange

The Compare VI tool is immensely useful, except when identifying changes in case statements, where it is easily "confused". Take for example two VIs where the cases in the case statement are identical except that in one VI there is an additional case at the end, or has a renamed case. When you run the Compare VI tool, everything is out of whack. It shows differences between two case that are named totally different, ignoring the other case that is named exactly the same. When this happens, you end up manually comparing. It would be great if the Compare VI tool would ignore the case order and compare the actual case names when doing a compare, much like a text compare tool would. Maybe even make it an optional setting.

View All (2)

While writing/debugging applications that make heavy use of reentrancy it is not uncommon for a reentrant VI to be left open after the rest of the application has shut down. This leaves VIs, Classes, LVLIBs locked in the project and your only recourse is to hunt down the offending reentrant item or close the project and reopen it.

It would be valuable to be able to see the running clones in the list of reentrant items found by navigating to View>>Browse Relationships>>Reentrant Items, maybe denoted by a *, like this below:

Having that would easily allow me to open the running clones and close them out manually so I can continue debugging.

View All (2)

Currently, for waveform/XY plots/graphs, the legend, graph palette, cursor window, etc are all "coupled" with the graph itself from a "graphical" perspective.

This means that all of these "addons" must be attached to the graph, and you can't put them in a different part of the panel. Screen resizing thus tends to screw things up, especially if your plot names can be defined by the user.

I'd like to decouple these somehow.

For example, I'd like to be able to put my legend and zoom tools in separate panes separated by splitter bars, or even in a right-click style menu (like a subpanel popping up). This feature would let you use automatic resizing on the plot itself and keep the legend separate.

You could theoretically program your own version of this, but:

-Recreating the legend functionality (line size/width/etc) would be a large undertaking, especially since there isn't a native Datagrid type control that could display a checkbox, string, and small image.

-I don't know of a way to get at the built-in zoom/pan tools programmatically (yes, you could create your own, but it's a big PITA)

-It wouldn't work at edit time, like the current features do, unless you baked all of it into an Xcontrol

Basically yes, you COULD get a lot of this done yourself... but it'd be nice to just use the tools NI already made, which work great. I don't want to reinvent the wheel just for some graphical convenience.

String containers have display format Glyphs to help us understand the String Values when the display is Normal, Hex or Escape codes.

Integer numeric type containers have them too to show radix.

Timestamp containers must be inspected for their display format property to determine if they are in System Time or UTC.

Timestamp Controls, Indicators and Contsants SHOULD have a similar optional display format glyph.

This could be used instead of the misleading coercion dots when operations are performed on Timestamps as Seen Here

View All (1)

This is a very small suggestion, and hopefully easy to implement. When wires cross, very often one of the wires involved is an Error wire, and as it is usually wired last, it sits on top of all the other wires. All I'm asking is that Error wires are always placed underneath all other wires when they are created. To my mind, this improves the readability of the diagram.

What would help further is if Error wires were "faded", as if they were 50% transparent. You do need to be able to see them, but not such that they stand out. But I'm much less certain that such a change could happen. The khaki color is an improvement on the old pink though, that's for sure!

View All (6)

There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:

NXG Style Path.png

Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.

View All (5)

Having sold applications that use functionality from the OPC UA Toolkit we run into an issue if we upgrade our LabVIEW version and continue to develop those applications beceause the OPC UA deployment license will then stop working if we upgrade the software we have delivered to them to one developed in a newer version. So, even though the customer has an OPC UA deployment license and we have an updated developer license it is not enough because the deployment licenses have to be updated as well (and it does not help that deployment licenses are not something we can bunde with the upgrade of the software either). From what I understand new deployment licenses will not actually cost anything, they are provided by NI as long as you already had a deplyment license for the previous version - but the logistics of this is a nightmare for us. Instead of just delivering a new installer with an updated version of our software we have to get involved in upgrading the dpeloyment license for all of their systems each time we have gone to a new version of LabVIEW.

View All (4)

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1. This means the function will wait forever until an event comes in. But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events. I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it. If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running. In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after:

View All (2)

Many or most VIs that ship with LabVIEW have their protection set to Unlocked (no password). The screenshot below shows a selection of such VIs.

It would be much better if the protection of vi.lib VIs was set to "Locked (no password)", to prevent accidental modification.

It seems very risky for built-in VIs to be open to modification, especially to accidental modification.

Scenario 1: Developer A is developing an application on their machine which contains modified vi.lib VIs which were accidentally modified as part of work on previous projects. They build an application which passes validation and starts to be used in production. All of the developer's source code is committed to a source code repository. Developer A leaves the company. Six months later Developer B is asked to pull the code from the repository and add a minor improvement. The application behaves very differently when Developer B builds it on their machine. A long and complicated troubleshooting session later, Developer B concludes that the different behaviour was likely caused by modified vi.lib VIs on Developer A's machine. Developer B cannot be sure, because Developer A's machine was wiped when they left, so there is no way to unequivocally prove the conclusion.

Scenario 2: A team of developers builds a test system for a defence application. The code is completed, and the test system is put through a thorough commissioning and validation process that involves testing dozens of known good units and known bad units. The validation process takes three weeks to complete. Management plans to not have to run the whole validation process for future minor changes. Instead they will ask the development team to perform code reviews and record notes for each minor change. Revalidation is not necessary if the code reviewers agree that the changes are non-functional, for example, the wording was changed in a dialogue message, or a logo was added to the UI. This sounds like a great plan, but is technically unsafe. Strictly speaking the whole revalidation process would have to be rerun, even for minor changes, due to the fact that not all of the source code is visible in the repository (there is uncontrolled source code in vi.lib that could have been modified in between builds).

Essentially I don't think it's safe for an app to contain source code that is not visible or tracked in a repository.

I can't think of a simple, quick solution to the concerns above, but having all vi.lib VIs set to "Locked (no password)" could be a quick first step towards reducing the likelihood of this issue. Developers would at least have to consciously edit vi.lib VIs, rather than doing it accidentally which can happen now. Of course, a malicious actor could still wreak havoc by editing a few inconspicuous vi.lib VIs.

The risk would be reduced further if the vi.lib VIs were password-protected. This would come at the expense of not being able to view the source code of native VIs, something which I find useful. Therefore, I personally would prefer "Locked (no password)" to password-protected, but I might prefer password-protected to unlocked.

Similar concerns apply to non-NI third-party libraries that install in vi.lib, user.lib or instr.lib, for example the extremely useful OpenG libraries. These too are examples of uncontrolled source code. For this reason some developers I worked with preferred to copy the OpenG and other libraries into the project repository (this involves a tedious job of opening each library VI and relinking it to the other library VIs in their new location).

This idea is similar but potentially easier to implement than the following idea: Make the VI's from the "vi.lib" Read-only - NI Community

Thanks

View All (3)

Problem Statement

Sometimes, you may want to delete files that are read-only. The Delete primitive outputs an error (Error 😎 when you try to delete a File that's set to read-only. One then has to change the file permissions to writable and retry deleting it. That's a pain. What's even more painful is when you try to delete a folder, recursively, with the Delete function -- passing it a folder path and setting Recursive to TRUE. In this case, if even a single file inside the folder is set to read-only, then the recursive delete will fail -- now, the developer has to do their own recursion to find the file that's read-only, mark it as writeable and then delete it. OK, convinced this is a pain? Here's the solution...

Proposed Solution

Add an input called "Ignore Read-Only" to the "Delete" function that will do all this form me.

Note

The OpenG Delete Recursive VI (in the OpenG File Library) has such a feature already. I was excited when LabVIEW implemented a recursive delete and I started using it all over the place (it's nice to write code that doesn't depend on external libraries, when possible) and then... I got bit by this limitation in some random corner cases where files had gotten marked as read-only.

This recent idea reminded me of something I have wanted for quite some time now: the ability to determine if a property is read or write based on wiring, not some half-buried option in the right-click menu.

The basic idea is simple: all properties have two terminals, one for writing and one for reading (except read-only of course). No right-clicking, just wire up the direction you want.

The bottom case is a bit interesting. I see a few possibilities:

1. Passthrough (cosmetically saves branching, crossing, etc.) Same behaviour regardless of errors.

2. Read then write : returns previous value. What happens if there is an error? Passthrough, old value?

3. Write then read: almost always passthrough. In case of error would it return old (ie. actual value) or passthrough?

4. Do not allow this.

I would expect it to perform the write and then the read (3) or passthrough (1). What is more important to me is the actual value and not the intended value. Mentally I just see data flowing into then out of the PN when both are wired.

Bottom line: I see no reason not to permit the wiring to determine read or write of a property.

If there is a ~~cop-out~~ lack of consensus and simultaneous connections are not allowed, I would at least ask for a keyboard modifier (say shift) such that I can shift-drag to expand the PN and get the same property repeated instead of going down the list. Then I could at least do the write+read with a lot less mouse movement.

View All (1)

On a For Loop that is configured to have parallel iterations there is a nifty feature when using errors on a shift register. This feature is explained in an article here. It basically ensures that For Loops that run 0 times, will preserve the incoming error as if the tunnel was a shift register. However this feature also means that errors from iteration 0, won't be passed into iteration 1. What is returned if the loop runs 0 times is just the incoming error. But if it runs for more than that, the errors are all merged and returned will be the first error seen.

This idea is just to allow this already existing feature to work on non-parallel configured For Loops. When would this be useful? Say I want to delete an array of files. I want to attempt to delete all files, even if there is an error in trying to delete some, just keep trying to delete the other files. Initially you may think this:

But that has the clear problem that if the incoming array is empty, then the error will be cleared. So we often do something like this.

And honestly this bit of code isn't that big of a deal, but this feature already exists. However it only works on For Loops that are configured to run iterations in parallel. In this case I might be attempting to delete files in a specific order due to their placement on disk, and running in parallel isn't what I want.

Since not everyone wants all errors in loops to act this way it would need to be a right click menu to turn the tunnel into a normal one, a shift registered one, or a preserve and merge one.

That is what I want.

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

Webservice Swagger/OpenAPI document generation

If diff has no panel differences, show the block diagram on top

Do not apply VI Properties "Run Time Behavior" until the vi is running!

Compare VI tools that doesn't get tripped up on Case statement names

Show running clones while browsing relationships>Reentrant Items

Decouple plot legend/tools/etc from the plot graphic itself

Display Format Glyph for Timestamps

Always place Error Wires underneath other wires

Allow hide of path type selector on path controls

OPC UA deployment licenses should be version agnostic

Permanent Knight License

Event When User Event Becomes Invalid

New tunnel mode: Build set

Support Python Virtual Environments

vi.lib VIs should be set to "Locked (no password)"

"Delete" (File) primitive should have an "Ignore Read-Only" input

Consistently expose nested data in Property Nodes

Allow Wiring to Determine Property Node Read/Write

Type conversion to fixed point - should also work for arrays

Allow For Special Loop Error Shift Register on Non-Parallel For Loops