ExamplesΒΆ

Note

The function blocks with an input or output variable with the name hBlock will internally use the library Segmented Block Manager. This library provides functionality for managing data structures in a way that the amount of copy actions is as minimal as possible. Currently the implementation of this library has a serious problem (CDS-56664). It uses frequently function for allocating (SysMemAlloc) and releasing memory (SysMemFree) sections. This behaviour can lead to memory fragmentation. This is not a good practice in the industrial environment, because it is about the possibility of a continuous operation around the clock and 365 days a year.

Inside this folder you will find a NetBaseServicesDemo project archive. Please download and open this archive to take a look inside and learn a little bit more about the usage of the TCP and UDP function blocks.

TCP Server - Client

A TCP_Server typically can handle more then one connection at the same time. To realize this in our examples we have encapsulated the logic for handling one connection inside a function block Handler. So one instance of a Server can be connected to one ore more instances of a Handler function block. Each of these instances may be located in a different task context.

../../_images/TCPServer.png

The function block Server need some information about the network (ipAddr) and the port (uiPort) it will listen for new connections. As long the xEnable input variable is TRUE the function block will accept new connections. The output variables xBusy = TRUE and hServer <> 0 will signal this situation. With resetting the xEnable variable to FALSE all active connections will be closed and the output variables xBusy and hServer will get inaktive values (FALSE or INVALID_HANDLE).

../../_images/TCPHandler.png

After the server has accepted a new connection the output variable xActive of a specific Connection will be set to TRUE and the output variable hConncetion will change form INVALID_HANDLE to a valid handle value. The enabled TCP_ReadBuffer may provide a new message after each invocation. The output variable xActive will signal a new value at the hBuffer output variable. The best way to decouple this possibly very fast flowing data stream from the rest of your application is to use a so called Queue function block. It will store the incoming messages with a FIFO strategy (FirstIn - FirstOut) and is so providing the possibility to compensate load peaks.

The TCP_WriteBuffer function block will send one message with each rising edge of its xExecute input variable. The time till the xDone output variable will be set to True depends on a variety of conditions and can lasts much more time than one or two plc cycles. This is the main reason to decouple the Reader and the Writer with the help of a Queue.

In this example the ownership of the hBuffer handle is directly connected to the processing of the following function blocks or functions. If you do some other processing steps and you will take the ownership of a hBlock handle, it will be necessary to use the SBM.DeleteBuffer function to free the connected resources.

../../_images/TCPClient.png

UDP Producer - Consumer

The UDP protocol is not stream orientated as the TCP protocol. Two peers (e.g. the producer and the consumer) on the same network segment will exchange messages (packages). The message length is restricted to the maximum transmission unit size. There is no guarantee against package loss. There is no mechanism for retransmission of lost messages. There is no rule for keeping the sequence of send packages in the same order as the received packages.

../../_images/UDPProducer.png

The function block UDP_Send takes the description of a message via its input variables pData and szSize. After the detection of a rising edge on its xExecute input variable it will send the message over the next amount of invocations. The successful end of this operation will be signaled with xDone output variable. In our application we will repeat this sequence every 500 milliseconds.

../../_images/UDPConsumer.png

We have to solve the same problem related to the different operation time of a Receiver and a Sender as we did while we implemented the TCP Server - Client application. And we will use again a Queue at the consumer side of our application. The receiver can provide at any time (after each invocation) a new message. So it is very important to hand over the received messages directly to a Queue. The Queue is created after the Peer (Consumer) was activated and will be disposed after the Peer is deactivated. Activation and deactivation of the Peer is controlled by its xEnable input variable.

After getting out an hBuffer handle out of the Queue the application will copy the content of the buffer in a different memory location. It will after this use the SBM.DeleteBuffer function to free the related resources and took the ownership of the handle back from the application to the library.