NEW Version 3.2! Variant Reconnecting Stream with Connection Manager

[PrimaryKey]

Description

Description-Separate-1

Overview

This example provides an reconnecting network stream class that can be used to create applications that communicate over the network.

Description

The Stream.lvclass implements an asynchronous daemon that handles the two way connection of a network stream. The daemon is spawned dynamically when you create a stream and you enqueue messages to the outgoing queue that the daemon needs to send over the network. The messages that are transmitted back are read by the daemon and enqueued locally in the incoming queue.

IP with context is required because network streams connect to endpoints in executables based on the executables context (the name of the executable).

This is covered here: Specifying Network Stream Endpoint URLs

Steps to Implement or Execute Code

1. Make sure that your VI Package manager is in version 14 or higher.

2. Install the package.

3. Find the Object Reconnecting Stream in Addons palette in LabVIEW.

4. Run the Example VI for Example palette.

5. Experiment with the code and connection manager.

Requirements

• VI Package Manager 2014
• LabVIEW 2014

There is experimental 2011 version available but it was not tested. Use at your own risk.

Additional Images or Video

https://www.youtube.com/watch?v=3fn1T9z85ac&feature=youtu.be

Changes in Version 3.2.0.1

• Changed the Connection Manager to be a dialog box (based on user feedback)
• Changed the behavior of loading streams in connection manager. Now they are added instead of overwriting existing connections (based on user feedback)
• Marked all VIs of API to separate from compiled code so they do not require to be recompiled after loading

Changes in Version 3.1.0.7 (minor bug fix)

• Fixed a bud that did not allow to use dot and underscore chars in the stream names

Changes in Version 3.1.0.6

• New look for the connection manager and stream adder.
• Added limited size to buffer queues in the stream. That way the user can monitor timeout on writing.
• Speed up to the writer and reader daemon loops.
• Modified a little the example to show new features.
• Added monitoring the size and usage of buffer queues to connection manager

Description-Separate-2

[approximately_whatever]

I am using multiple parallel Streams (each in an Actor) and I noticed that when a Stream is disconnected, the cpu usage was high. Performance profiling pointed me to the Writer Loop.vi and Reader Loop.vi in Stream.lvclass.

There is a while loop with a case inside: the "Connected" case has a 50ms Wait until next ms multiple, while the disconnect case does not - which I suspect is the cause of high cpu usage.

Shouldn't the Wait until ms multiple be outside the case structure? Is this an oversight or a design decision?

EDIT: I just made a local fix by moving the Wait until ms multiple outside the case structure. The high cpu usage is fixed, but it feels like it takes longer to reconnect.