IN GENERAL

If two devices want to communicate, there must be established a connection at first. Only after that the data can be transferred in between these two devices.

TCP and UDP protocols are used for sending data bits - known for exchanging data packets between network devices.

TCP protocol provides a way to deliver (and receive) controlled stream of data packets over the network. This protocol ensures that the data sent from one application will be recieved to the second application in that very order in which they had been sent and that this transport is reliable (none of the data is lost). The consequence of this complicated communication is a certain latency (delay) of the transmitted information.

UDP protocol does not guarantee the reliability or the order of incoming data. Basically the independent datagrams are sent in to the network. There is no connection between two applications. The UDP protocol is used to provide a faster flow for the information by using no error control. UDP is appropriate to be used where the request for the speed is greater than the request for reliability.

In two-way connection (TCP) there is a socket created and it is connected using one specific port number. It is because the port number is then registered and no other application can connect to this port again. One-way connection (UDP) doesnt occupy the port because the port number is stored inside of the datagram. No connection is created.

PROS / CONS

Railduino module uses both types of communication - UDP and TCP

For immediate information about change at digital inputs of the Railduino module it is appropriate to use UDP (request for fast information about the change). For controlling the outputs of the Railduino module it is appropriate to use TCP (request for reliability of information)

MODBUS TCP

Communication Modbus TCP is a master-slave communication type, where the superior master system (Modbus TCP Client) actively writes/reads the information into the controlled slave device (Railduino modul acts as Server). The server is waiting for incoming connection from the Client. Once the communication is established Server responds to the Client's requests until the client terminates the connection. Requests of the Client must meet the standards of the Modbus specifications - functions FC1 - FC16 - more e.g. HERE

The data exchange field between devices is called Modbus map and is described in the Basic connection chapter of the Railduino module page.

CONCLUSION

For quick responses to changes at Railduino module inputs use UDP protocol

For reliable executed commands for Railduino module outputs use MODBUS TCP protocol