From 08:00 PM CDT Friday, August 12 - 01:00 PM CDT Saturday, August 13, ni.com will be undergoing system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Does LabView have high-level and efficient I/O multiplexing module like Python "selectors"?

Solved!
Go to solution

Hi there,

 

I have use case that need to monitoring on a TCP/IP connection to receive data and then trigger the related event handler VI. I know that Python has a module "selectors — High-level I/O multiplexing — Python 3.10.4 documentation" that can be used for my case. My question is: Does LabView (native or 3rd-party module like OpenG, MGI etc) has a counterpart module like Python selectors? If so, I can use it directly in my project instead of creating the wheel from scratch.

 

Thanks in advance!

Xiang

0 Kudos
Message 1 of 4
(240 Views)
Solution
Accepted by RenXiang

You may have to consider rethinking your approach a little. Typically all LabVIEW nodes do internally already asynchronous IO but that is hidden from the user. For your LabVIEW diagram it looks like the node is operating synchronously and from the point of view of your diagram that is really the case, but underneath all the LabVIEW TCP and UDP nodes are fully asynchronous (and so are others such as VISA by default (but you can change an option on the VISA node to make it operate synchronously by using the synchronous VISA API instead.

 

What basically happens in the case of a TCP Read for instance is that LabVIEW sets up a read() operation and then uses internally the select() call to wait for some data to arrive until the requested amount of data has arrived or the timeout has occured.

 

So in LabVIEW you program concurrent communications by having independent loops that each do their thing and then communicate with messages through queues or similar things. And rather than having these loops all in a single VI there is absolutely nothing against having them in their own independent VI that you launch at some point and let it run as an independent daemon in the background. There are several message based frameworks that all use this principle, with the NI Actor Framework being one of the more complex ones. It has a steep learning curve and is fully LabVIEW object based but once you know it you will typically never go back to anything else.

 

https://labviewwiki.org/wiki/Actor_Framework_is_not_as_hard_as_you_think_and_here_is_why%E2%80%A6

 

Other similar message based frameworks do exist and are typically a little less intimidating but quite as capable as well. LabVIEW comes even out of the box with the Queued Message Handler example but it is generally considered a poor mans choice, but that's probably not always a bad thing. It is an example of how it can be  done, not a fully fledged implementation.

 

Others that build on the QMH idea but formalize it quite a bit more would be:

 

https://dqmh.org/

https://forums.ni.com/t5/Reference-Design-Content/Dr-James-Powell-Messenger-Library/ta-p/3538506

 

Rolf Kalbermatter
Averna BV
Message 2 of 4
(211 Views)

@RenXiang wrote:

I have use case that need to monitoring on a TCP/IP connection to receive data and then trigger the related event handler VI.


If that's all you want (monitoring 1 TCP/IP connection and sometimes send an event), you can simply make a loop. Read incoming data, if the trigger is there, send a user event. Or trigger a value signaling. Or enqueue something. Or use a channel wire.

 

For multiple connection, you can start this VI multiple times, either dynamically or statically.

 


@RenXiang wrote:

. I know that Python has a module "selectors — High-level I/O multiplexing — Python 3.10.4 documentation" that can be used for my case. My question is: Does LabView (native or 3rd-party module like OpenG, MGI etc) has a counterpart module like Python selectors? I


I don't know that much about Python (not about selectors anyway), but they seem to be a Python solution to a Python problem.

 

On the other hand, selectors do seem to work a lot like user events. But LabVIEW uses event structures to catch events, not callbacks. 

 

You can actually use callback VIs in LabVIEW, but the problem is these VIs are executed in isolation, so you'd always need global or by reference data to actually do something. AFAIC, Event structures are preferred.

0 Kudos
Message 3 of 4
(193 Views)

Thank you Rolf for your detailed reply! That's exactly what I need.

0 Kudos
Message 4 of 4
(123 Views)