LabVIEW Idea Exchange

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.

Hi.

SubVIs are sometimes easily missed in a block diagram when you glance over it, and their current configuration is impossible to determine unless you open up each subVI and examine its VI Properties. I suggest a quick way to highlight and configure subVIs within a BD. Consider this section of code:

Then one could hold down the ALT-key (or some other easily accessible interface) to get this view, which gives you an interactive highlight glyph overlay on top of each visible subVI. Letting go of the ALT-key returns your BD to normal of course:

The interactive highlight glyph gives you direct access to this for each subVI:

- It highlights where in the BD there is a subVI.

- It shows if the subVI has unsaved changes.

- It shows the runtime priority of each subVI (more on that later).

- It shows the reentrancy mode of the subVI (as well as inlined/subroutine state).

- It highlights any unwired required inputs of that subVI.

- It shows if the subVI has debugging enabled (which can have a negative impact on performance).

- It illustrates if the subVI is otherwise configured for optimum performance (more on that later).

More on the subVI highlight glyph:

I imagine tooltips might pop up containing additional info if you hover the mouse pointer over the elements in the glyph. I think clicking the "unsaved changes" asterisk should save the subVI with all the bells-and-whistles as if you opened it and did CTRL+S on it. I think clicking the "Debugging enabled?" element should toggle the Allow debugging property of the subVI directly. I think clicking on the colored frame should open the reentrancy setup dialog of the subVI. The colored icon frame is part of many LabVIEW style guides for icons btw, but not everybody is familiar with them, and thus don't use icon frame colors like this. Also such colors might clash with other style guides - class icon templates for instances, or company logo colors. That is why I propose the reentrancy setting being part of this subVI highlight glyph.

More on subVI priority:

I have earlier proposed a much simpler way of defining subVI priority with a number, which is along the lines of how it's defined in a timed structure, instead of the current way of setting Priority and Preferred Execution System in VI Properties (which many people find hard to figure out and keep mixing it with timed structures). That idea can be found here. This priority number is what I propose is located on the subVI highlight glyph. Clicking on this element in the glyph should open the subVI's Priority setup dialog directly.

More on the "optimum performance" element:

I haven't really thought deeply about this element, but I see it as an indicator of if "all the rest" about the subVI is optimized for best performance and least runtime pitfalls. Stuff like making sure Enable automatic error handling and Auto handle menus at launch are disabled. Anything outside of the optimum will light this indicator. Clicking on it should open the subVI's VI Properties dialog or similar.

What do you think?

Cheers,

Steen

I didn't find this idea immediately, perhaps something similar has been posted already?

I would like to propose an extension to the Index Array function, to accept an array of numbers or booleans on the index input. The picture below illustrates the idea. The new Index Array function would replace the for loops in both cases, making for a neater and more readable diagram.