Click or drag to resize

3.2.6 Streaming

The Process Data Analyzer API also supports streaming functionality which, in contrast to the standard operation mode, allows for infinite acquisition and real time reaction to recorded events. A rough concept overview is given here.

Streaming API concept

The overview shows a Process Data Analyzer API client in streaming mode.

Overview of PDA API streaming.
Streaming API Concept

A client is connected to the Process Data Analyzer API with streaming mode enabled. The configured signal's trace data is polled by the Process Data Analyzer server. The signals are then mapped into their gRPC/protobuf messages and sent to the client over a TCP stream. It is left to the client to receive, buffer and handle all data correctly from hear on out. All sent signal data is then removed from the server PC's RAM. This way, acquisition can run infinitely on the server side.

Frame structure

A Frame describes a chunk of data, unique by their timestamp. The frame contains all signals that were recorded for each timestamp in the frame.

Stream frame structure.
Stream Frame Structure

The Samples in a frame are filtered by change. If all configured signals do not change for a given time interval (normally 10 µs), the sample point is omitted. In the same manner, the changed signals are mapped to each timestamp. If only three of fife configured signals change their value at the current timestamp, only these three signals are added to the current timestamp.

The number of timestamps per frame depends on the signal value changes in the control card's trace buffer and normally lies between 0 and 4500. The number of signals mapped to each timestamp depends on the signal type and if the signal underwent a value change for the current timestamp. In case the signal is not available at a specific timestamp, the previous value can be assumed (unchanged).

Custom handling of streamed data

API wise, the simplest way to work with a data stream is a fully custom implementation to handle the received data. The client opens the stream with the StreamingMode set to None. This configures the Process Data Analyzer server to send all configured signals to the stream.

The received data can then be used to do manual processing and checks, either discarding the data afterwards, or saving it in any desired way or form. Everything must be handled manually and it must be ensured, that the received data is buffed and processed adequately. See the streaming concept's overview.

Triggering trace save
Overview of the streaming trace save triggering.
Streaming Trace Save Trigger

If the goal is to create a simple condition at which a trace of the current signals should be saved, the client can be configured to send a signal to the Process Data Analyzer server. The corresponding streaming mode is StreamingMode Trigger. In this case, all signals are streamed to the client, but the client can send a trigger back to the server, triggering a trace to be saved. The saved trace can be opened by the Process Data Analyzer UI to inspect the process.

Both the processing and triggering take some time, during which the acquisition will continue on the server. If the needed information is not available within the saved trace, the frames per trace of GetFrameRequest should be increased or the processing speed improved.

Custom condition DLL trace save
Overview of the custom condition DLL trace save triggering.
Streaming Custom Condition Dll Trigger

If triggering a trace save based on conditions is the only application and C# can be used, the custom condition DLL approach requires the least effort while yielding the highest performance. By implementing the ICondition interface, a DLL can be compiled and loaded from the Process Data Analyzer server during initialization of the stream.

With the custom condition DLL loaded, the server can then be instructed to:

  • Save the current frame(s) to a .pdatrace file if the condition is met.

  • Send the current frame(s) to the stream only if the condition is met.

  • Send and save the current frame(s) if the condition is met.

The custom condition DLL does not adhere to the frame, but takes the current timestamp (each sample within a frame) directly as argument of the Check method.

The custom condition DLL is also recommended if four or more control cards should be checked at the same time.

See Also