CL Stream Flush

Owning Palette: Communications/Advanced

Requirements: Quanser Rapid Control Prototyping Toolkit, LabVIEW 2020 or newer, Control Design and Simulation Module

Description

The CL Stream Flush VI writes the data in the stream buffer to the underlying communication channel. The operation of this VI is affected by the blocking mode of the stream connected to its input. Streams have two modes: blocking (the default) and non-blocking. The blocking mode of the stream is determined by the CL Stream Connect or CL Stream Accept VI which created the stream. The CL Stream Flush VI cannot be used with streams created using the CL Stream Listen VI.

Required Inputs All required inputs must be wired. They always appear as terminals on the VI palette. They also appear in bold text in the context help window for the VI.

stream in is a reference to the stream created by the CL Stream Connect or CL Stream Accept VI. If the stream is closed or is otherwise invalid then the negative error code `-QERR_INVALID_STREAM` is returned by the error out output.

Outputs

stream out is a reference to the stream. This output is merely a copy of the stream in input.

error out contains error information. If the error in cluster indicated an error, the error out cluster contains the same information. Otherwise, error out describes the error status of this VI.

	status is TRUE if an error occurred. If status is TRUE, the VI does not perform any operations.
	code is the error code number identifying an error. A value of 0 means no error, a negative value means a fatal error, and a positive value is a warning. Refer to the Quanser Error Codes for a code description.
	source identifies where an error occurred. The source string is usually the name of the VI that produced the error.

Details

This VI attempts to send the contents of the stream buffer over the communication channel. If an error occurs, then it returns a negative error code at its error out output. If the connection is closed it is considered an error condition.

If the stream is blocking, then this VI waits until all the data in the buffer is sent before returning.

If the stream is non-blocking, then this VI does not wait. It attempts to send all the data remaining in the stream buffer. However, if this operation would VI then it returns -QERR_WOULD at its error out output, even if it has already sent some of the data. In this case, the CL Stream Poll VI may be used to determine when at least one more byte may be flushed.

This VI does not support two threads calling CL Stream Flush or CL Stream Send at the same time. However, CL Stream Flush or CL Stream Send may be called by another thread at the same time as CL Stream Receive.

Hint

For packet or message-based protocols in non-blocking mode, the number of bytes sent over the communication channel in each packet may be larger than the number of bytes in the input signal. If the data cannot be flushed to the underlying communication channel without blocking then it remains in the stream buffer and will be written to the underlying communication channel along with the new data the next time the CL Stream Flush VI is invoked. This situation is typically recognized when a QERR_DATAGRAM_TOO_LARGE error is returned at the peer when trying to receive the data. The number of bytes in each packet may be as large as the stream buffer size unless the underlying protocol restricts the maximum packet size. For example, the bufsize option of the UDP protocol has a default value of 1492 bytes. Hence, up to 1492/8 = 186 doubles may appear in a single datagram at the peer if the stream buffer is more than 1492 bytes in size. To restrict the size of the datagrams sent, either reduce the stream buffer size or set the bufsize option of the UDP URI. Reducing the stream buffer size may cause new data to be discarded if there is not enough room in the stream buffer, but it limits the number of datagrams sent. Setting the bufsize option of the UDP URI causes the stream API to send multiple datagrams, if necessary, to flush the stream buffer. A typical URI would be "udp://localhost:18000?bufsize=512", which sets the maximum datagram size to 512 bytes (64 doubles). An even better solution is to allow the datagrams to be large and instead receive the full datagram at the peer. For example, if the stream buffer size and maximum datagram size are both 1492 bytes, then attempt to receive 1492 bytes at the peer (or 187 doubles).

Feedthrough Behaviour

All input/output pairs of this function have direct feedthrough behaviour.

Examples

RCP CL Comm Advanced Stream Example

Targets

Target	Supported	Comments
RCP Windows (64-bit) Target	Yes	Fully supported.

navigation bar

	CL Stream Close	The CL Stream Close VI closes the stream connected using CL Stream Connect.
	CL Stream Connect	The CL Stream Connect VI establishes a connection to a remote host. The connection is made each time the VI executes.
	CL Stream Accept	The CL Stream Accept VI accepts a connection from a remote host.
	CL Stream Listen	The CL Stream Listen VI creates a stream that listens for connections from remote hosts.
	CL Stream Poll	The CL Stream Poll VI polls for events associated with the connected stream.