LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

label auto-numbering

hello forum

given certain circumstances, the auto-incremental function for labels may lead to entirely different meanings. maybe sticking a non-printable character or a delimiter next to autonumber can solve this?

for instance, delimiter "- " in this case would make it even worse, but a non-printable character maybe...

1st label: number: 0 to 1

2nd label: number: 0 to 1 - 1

3rd label: number: 0 to 1 - 2

and so on

This idea has come up repeatedly over the years: a new VI created in a library* should default to private scope. The point of private scope is to limit the number of callers of a subroutine so you can freely refactor the subroutine and know, without question, that the only callers that you can be affecting are the ones inside the library. This allows you to make API breaking changes freely because you can know you are updating all the callers. Note that if we did this, it would almost certainly have a Tools>>Options setting to change it, but the idea is to make "new VIs start in private scope" be the shipping default.

Each of the other scopes is more permissive in some way, with public being all the way open. For APIs intended for reuse and long-term stability, use of those other scopes ought to be a conscious decision.

The vast majority of VIs within most libraries should be private. There are some weird exceptions**, but most libraries have a few routines intended for the world to call and a bunch of subVIs that support the public ones. But going and setting the access scope to private is a lot of work, and many developers never think about it. For small shops, this isn't usually a big deal, but the larger the dev team, the greater the danger of highly interlocked libraries caused by someone reaching for some deep subroutine that just seems so useful, instead of doing the right thing and refactoring that VI out into its own shared library.

I've seen some of our customers get really badly bitten by this, but it is an issue that takes years to build up, and then requires expensive refactoring projects to fix (or cloned code, which is sometimes worse in the long run).

C++ and C# default everything to private unless you declare public; I think that's true in most text languages.

But LV is a programming language for non-programmers, and not everyone needs to understand access scope, so creating new VIs as private by default would push yet another concept into the "you must learn this" category instead of "learn this when you hit a scale where it is useful" category.

In the end, I think access scope is a simple enough concept, one that most people using libraries get familiar with pretty quickly, and switching something to public is easy enough to do. Therefore, I think switching the default would do more good than harm. So that's what I'm proposing here.

* includes plain .lvlib libraries, XControls, LabVIEW classes, state charts, and any other type of library NI may introduce.

** such as the NI Analysis library, which is hundreds of VIs packaged together, mainly for licensing reasons, less because they have shared functionality.

View All (2)

I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire. I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal. I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:

1. Wire this specific VIM on error wires most often

2. Likely don't want the VI to stall in the event of an error

3. Would prefer to see that error propagated as quickly as possible like most other VIs do

Thoughts?

Allow viewing of Map Constant as Icon

View All (2)

Here is my idea:

When searching for something in quick drop, you should be able to press shift and double click on an item and have it either insert it onto current wire(s) or replace the current node.

QD idea.png

Background: I usually either use a shortcut for the exact thing I'm looking for or else use the arrow keys to navigate down to it and then press ctl+p or ctl+i. But in some cases I am trying to insert or replace a node I don't use often and it might be near the bottom of the list. It's more convenient to use the mouse to click on it rather than a bunch of down arrow presses. But then I have to move my hand back to the keyboard to do ctl+p or ctl+i, which is not convenient. It would be nice if I could just press shift or some other modifier and double click and it would automatically insert or replace (I think it could figure out which to do by context).

Edit: I realized that the shift key already means something because it modifies how the insert works (whether to insert on each wire or onto both wires). Therefore I would propose a different modifier key, like alt+double click inserts or replaces, and shift+alt+double click inserts or replaces with shift modifier.

Hello forum

Wouldn't it be nice if we can add W10 IoT Enterprise PCs as Embedded Targets, where we can create VI executable and set it as startup programs and once deployed, the target will be automatically configured to: launch the startup programs with Embedded Enabling Features (EEF), Enhanced Write Filter (EWF), Hibernate Once, Resume Many (HORM) and File Based Write Filter (FBWF) but on different volume; as presented in NI Week TS2361 & TS8562 slides.

Thanks

Subpanel invoknode is not duplicated on block diagram by clicking subpanel on front screen with ctrl+drag

Copy paste of Sub Panel from the front panel by clicking with ctrl+drag is not working as intended. same things happens with ctrl+c & ctrl+v action.
For the two front panel controls(Sub Panel) there should be two function(invoke node) mapped on block diagram. which is not in the case of copy paste of Sub Panel.
We have to manually put Sub Panel from the control pallet, and the name of the Sub Panel is not
auto incremented like other controls like Numeric..Numeric 2, Numeric 3.

Tested on LabVIEW Version 2018.0.0 and 2018.0.1

View All (1)

It would be nice if the LabVIEW primitives for TCP allowed for the creation of a socket without actually connecting it to an endpoint. My thoughts are that there would be two new commands added to the TCP palette:

TCP Create Connection (Advanced)

TCP Open Connection (Advanced)

TCP Create Connection (Advanced) would create the socket but not perform the connect() method on that socket. I would imagine that it would otherwise look and feel quite like the current TCP Open Connection, except that the user would need to manually run TCP Open Connection (Advanced) afterwards that would perform the connect() method on that socket.

I have a need to access the raw socket object before it is connected, using the TCP Get Raw Net Object.vi in the vi.lib\Utility\tcp.llb library. This VI works to get the handle that can be used by winsock and other Windows DLLs, however, it only allows for setting properties for a socket that is already connected.

Specifically I have a need to enable Windows FastPath for TCP to optimize the rate at which I can stream data between two applications. Per the specification, this option must be enabled BEFORE the socket is connected. Right now I can set this for the listener on the server side (TCP Create Listener creates a socket but does not connect), but I cannot set it for the TCP connection on the client side as the first method it calls is TCP Open Connection which returns a socket that is already connected.

View All (6)

When I connect something to the output of a Select node, I would like the input types to be updated to the connected output type.

For example, if I connect an enum to the output of my select node - if I "create constants" on the inputs, it should create the same enum type instead of a double. Similarly, when I connect a string to the output, I would expect the inputs to be strings as well.

If there is a conflict with the compiler, perhaps it could use whatever was connected first (input or output).

View All (3)

(Note that this idea has already been proposed and auto-declined. So I'm trying again, this time with a different UX, and pictures!)

I've got some code on my diagram:

I need to wrap the code in a case structure, so I do:

Then I connect a Boolean wire to the selector terminal and go on my merry wiring way. Unfortunately, I forgot to consider the fact that I need this code to run in the FALSE case, not the TRUE case. But since nothing is broken in my code, I don't realize my mistake until I start running things. I've made this mistake so many times over the years (the most recent being tonight), that I've decided to propose a solution.

There are plenty of times that I want the wrapped code to be in the TRUE case. There are also plenty of times I want the wrapped code to be in the FALSE case. With no obvious default that makes sense most of the time, here's what I propose:

If you interactively drop a case structure by dragging a rectangle around *existing* code, we float a button over where you let go of the mouse and give you a chance to make the visible frame the FALSE case instead of the TRUE case:

(I suck at Microsoft Paint, I'm sure somebody can come up with a better looking button or glyph)

If you click that button, then the case structure turns to the FALSE case. If you do *anything else*, the button goes away and the case stays TRUE.

With this proposed change, any time I wrap existing diagram code with a case structure, I'll be forced to think about whether the case needs to be TRUE or FALSE. And I'm given an easy out if it's supposed to be the TRUE case.

Need Aliases for project items

I really need the concept of "aliases" or "shortcuts" to project items. Consider this project:

Case 1.PNG

Case 1: maybe the item in blue is where I left off working yesterday,

Case 2: maybe the item in blue is a VI that I have to change when I add a new class somewhere else.

Either way, to get to it, I have to

1... Open the target ('RTAC-Culverson')

2... Open the DAQOBJECT folder

3... Open the DAQOBJECT CAN folder

4... Open the DAQMODULE CAN folder

5... Open the DAQMODULE CAN.lvclass

6... Open the ACCESSORS folder

7... Open the MY OUTPUT CAN TASK folder

8... Open the VI that I want.

I suggest this:

1... I pop up on this item in the project, and choose CREATE ALIAS.

2... An Alias appears in the project. Aliases are ALWAYS at the top of the project, without opening any folders. (maybe limit to 10 aliases)

3... You can't do anything to an alias except OPEN it or REMOVE it.

4... Double clicking (= OPEN) an alias merely opens all folders leading to the targeted item, and highlighting it.

5... You can create an alias to a VI, to a CTL, to a CLASS, to a FOLDER, to a BUILD SPEC, anything in the project.

6... Deleting the original item deletes the alias to it.

This seems simple to do, because you don't need a context menu for the alias (if it's a build spec, allow BUILD in the menu, if it's a VI, allow RUN, or OPEN, etc.) Forget all that. Just OPEN it, or REMOVE it.

It's a ref to an item WITHIN the project, so copying a LVPROJ file should copy all the aliases.

Whaddya think ?

Simple idea is to make the icons found in the palettes, the block diagram and help all match.

MissMatchedIcons(larger).png

The icons in the columns are all the same function, however, there are some significant differences. It is reasonable to expect the help menu icons are expanded to show additional functionality, but there is no reason why the palette and BD icons should be different. The core of the icon in the help menus should be the same too.

These icons screen shots are from LabVIEW 2018.

Search Array and Count of Elements

When a user clicks and drags a slider - hundreds of value change events are generated for your code to handle.

Most of the time the user experience you want is just to use the value when the user has stopped dragging the slider. Similar to a text input field where you can select to have the value update only once the user has finished typing instead of all the intermediate values.

My proposal is to change the slider events to support this use case. I'm inclined to leave the exact solution open - as long as NI can support this use case.

There is another idea to add an ended event which would allow for this: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-a-quot-User-Control-Ended-quot-Event/idi-p/1075504?profile.language=en but I created this post to be more specific.

You can find a number of attempts if you search the forums for "slider too many update events" such as

https://forums.ni.com/t5/LabVIEW/Slider-control-generates-too-many-quot-value-change-quot-events/td-p/830659?profile.language=en

If you follow this through there are always compromises in every solution for getting this behaviour.

View All (3)

Using the application builder is problematic if the destination folder is monitored by syncing tools such as Google Drive (Backup&Sync), Onedrive, etc.

During building, there are tons of file operations in rapid sequence, potentially crashing the sync tools or causing false file conflicts (recent example).

To avoid these issues, I wonder if the building steps could be forced to take place in the temporary folder, followed by a final clean move to the destination. My guess this would make building more stable and compatible with external folder syncing tools.

Regular Expression search in Maps

View All (2)

.net function box

.net calls can end up being pretty verbose in LabVIEW, having to pipe between property boxes to get to some nested value, when the call is pretty straightforward when written in a more traditional language. In addition, trying to replicate some .dll functionality seen in c++ is frustrated by how different the calls look. Having the ability to drop into a function block to write .net code would make it much easier to port functionality + debug.

Even if there was a penalty performance wise, it would still be a nice middle ground for getting a prototype off the ground before optimising it for LabVIEW.

View All (2)

With increasing support for PPLs it would be great to have them be a valid <foundvi> location.

It becomes most evident when refactoring a .lvlib into a .lvlibp.

In cases where we replace "LibraryX.lvlib" with its compiled version of "LibraryX.lvlibp", we easily end up with some VIs that referenced subVIs from the original LibraryX.lvlib that need now to be updated to refer to the versions in the .lvlibp instead.

However, even after manually locating (and selecting) the first "missing" VI from inside the LibraryX.lvlibp , it does not behave as a "conventional" folder would: listed in the default search paths under the <foundvi> category and saving us the trouble of selecting every other "missing" subVI from LibraryX.

To be fair, the workaround exists in having the original LibraryX.lvlib present and replacing it with the PPL version for all projects that use it, but it strikes me as one that could be avoided.

Please let me know if that made sense and I'll do my best to clarify it,

Thanks all,

Cris

View All (3)

I have a case where I have bundled a set of command parsers which present an API to a module into a polymorphic VI.

I have a lot of test code which I want to now update with this polymorphic VI. The Polymorphic VI is set to be manually adapted, it does NOT autoadapt depending on the data wired (several instances have the exact same connector pane). I also have the selector visible.

When I replace Instance X (which is a member of the polymorphic VI) it replaces with Instance Y (which appears to be the default). I then need to go and manually re-select Instance X. What would be nice would be if the polymorphic VI is set to not autoadapt, and the VI being replaced is an instance in the Polymorphic VI, then the instance should be retained when replacing with the Polymorphic VI.

Or would anyone object strongly to this?

LabVIEW Idea Exchange

label auto-numbering

New VIs created in libraries should default to private scope

Conditional Indexing to optionally output the false condition (along with the true one)

Stall Data Flow should be a no-op in the event of an error

Allow viewing of Map Constant as Icon

Quickdrop Shift Double Click To Insert/Replace

LV/PDE for Windows 10 IoT Enterprise targets

Please Fix This: Subpanel invoke node is not duplicated on block diagram by doing copy with ctrl+drag/ ctrl+c,v on front panel

Allow creation of TCP sockets without actually connecting them

Update the Select node to support 'reverse' Type Propagation

Optional (and easily-dismissable) prompt to change newly-dropped case structure frame to FALSE

Need Aliases for project items

Make icons match between the different location where they are fou

Search Array and Count of Elements

Improved Value Change Options On Sliders

Make application builder more compatible with google drive and similar tools.

Regular Expression search in Maps

.net function box

Allow Packed Project Libraries to serve as a valid <foundvi> path for "missing" subVIs

Keep instance type when replacing with polymorphic VI