Event driven reading

With event-driven reading, LabVIEW™ events and ADS notifications are used together. An ADS notification only has to be registered once on the server. The server data are then received cyclically or on change (see "Transmode" in chapter Communication modes) from the client. Accordingly, the client only needs to issue one request, and the server then controls whether a new message needs to be sent to the client.

The ADS client in LabVIEW™ forwards the received notifications (data packets) as LabVIEW™ event to an event structure. See also the LabVIEW™ documentation on User events. The event structure inserts the received LabVIEW™ event into an internal queue. The events in the queue are processed by LabVIEW™ using the FIFO principle. If the notifications are received faster than it is possible to process the event structure in LabVIEW™, the queue becomes larger. This ensures that no notification is lost. It must be noted that this increases the amount of memory used. Accordingly, it must be taken into account that a point in time must be reached at which the memory requirement (the pending events) can be processed.

We recommend using the LabVIEW™ Event Inspector Window (View > Event Inspector Window) to observe the processing of LabVIEW™ events.

The interface for LabVIEW™ offers two different modes of operation for continuously registering ADS notifications as LabVIEW™ events:

E-Notification Single
E-Notification Buffered

E-Notification Single

The operation mode E-Notification Single immediately forwards the received ADS data packet to the LabVIEW™ event structure, i.e. it directly generates a LabVIEW™ event. A data packet can contain several samples. Transmode and TCBufferSize are key parameters for this:

Transmode "Cyclic" uses the TwinCAT-side buffer (of size TCBufferSize). In this case notifications are first written to the TCBuffer and then bundled and sent to the LabVIEW™ client when the buffer is full. This achieves higher data throughput, and there is less load on network thanks to fewer messages with low user data volume.

With Transmode "OnChange" the TCBuffer is not used. Here, the individual notifications are forwarded directly to the client without buffering. The client receives any change of state with minimal latency and can respond directly.

In LabVIEW™ the block diagram corresponds in principle to the above picture. Here the Register Notification Block and the Event Structure run in two different threads. The event is registered only once. The system then waits for the notifications in the event structure. Each received notification contains:

Notification Handle
Number of samples
Array of notification data
Array of ADS timestamps

If no notification is received, the event structure times out.

Examples in LabVIEW™: Read Notification-Event Single, Read Notification-Event Multiple

E-Notification Buffered

The operation mode E-Notification Buffered uses a data buffer on LabVIEW™ side in addition to the above structure. The buffer size is set by the parameter LVBufferSize when the ADS symbol is created. The received ADS data packets are first written to the LabVIEW™-side buffer in an intermediate layer and only forwarded to the event structure as a LabVIEW™ event when the buffer has been filled.

This approach generates LabVIEW™ events less frequently than in the E-Notification Single variant. By submitting larger data packets to LabVIEW™, processing can be made more efficient, resulting in higher overall data throughput.

	Buffer size The TwinCAT 3 interface for LabVIEW™ reserves an additional 10% buffer memory when generating LVBuffer.

Transmode and TCBufferSize are also the key parameters for this operation mode:

With Transmode "Cyclic" the TCBuffer and the LVBuffer are used.

With Transmode "OnChange" the TCBuffer is not used. The individual notifications are transferred directly to LVBuffer without buffering.

In LabVIEW™ the block diagram is similar to the E-Notification Single mode. Each received notification has an additional field called BufferInfo. BufferInfo provides additional information about the LVBuffer:

Previous Overflow Samples: Describes a counter that indicates how often the created buffer was not sufficient. Example: The buffer has been created by the user with 50 samples. As described above, 10% more storage space is created internally, i.e. 55 samples. Several samples can be transferred for each notification thanks to TwinCAT-side buffering. If the buffer in LabVIEW™ is already occupied with 45 samples and another packet with 10 samples arrives, the maximum buffer is not exceeded and the counter does not increment. If, on the other hand, the ADS packet was to contain more than 10 samples, data would be lost because the buffer would not be sufficient. Accordingly, the counter would increment by one.
Missing Samples: Describes the difference between received and expected samples. Example: The LabVIEW™-side buffer has 50 samples, so 50 samples are expected. However, if only 48 samples are received, the value of Missing Samples is two.
Buffer Usage: in percent %

Example in LabVIEW™: Read Notification-Event Buffered, Read Notification-Event Multiple