Optimizing Motorola MDLC Over IP

This technical article for Motorola RTU networks using Ethernet links covers the messaging architecture of MDLC over Ethernet. How the MDLC is implemented within the IP structure, how the retry settings affect the messaging and what IP protocol is being used.
In order to document and validate some concepts of MDLC over Ethernet test in a lab environment have been performed. Two ACE 3640 processors with ID’s 1000 and 2000 communicate over Ethernet port (ETH1). An application was loaded into both units to send a message from site 1000 to 2000 using in some cases a TxFrm (transmit frame) and later a SndFrm (send frame) message type. (STS software version 15.50). In order to capture the network traffic between the units a port mirroring device in conjunction with a computer with running Wireshark software network diagnostics software has been used.
Motorola uses UDP (User Datagram Protocol) as opposed to TCP (Transmission Control Protocol). The difference is TCP guarantees the recipient will receive the packets in order by numbering them. The recipient sends messages back to the sender saying it received the messages. When using UDP, packets are just sent to the recipient. The sender won’t wait to make sure the recipient received the packet — it will just continue sending the next packets.
Test 1. The port configuration parameters of both units have default values. When a TxFrm type message is used between sites the following capture is observed on Wireshark:

Fig 1. Wireshark capture between site 1000 and 2000 using TxFrm. Successful communications between sites.

The 3 messages sent back and forth between sites are known as a three way hand shake. It is a three-step method that requires both the client and server to exchange SYN and ACK (acknowledgment) packets before actual data communication begins. The first message (denoted above as No. 1) is the “SYN”, the second message (denoted above as No. 2) is the “ACK” and the third message (denoted above as No. 3) is the actual Data Packet sent from the STS Application. Notice that when both sites are communicating the time delays between each event is the milliseconds order (as expected for a 10/100 communication link)
Test 2. The port configuration parameters of both units have default values. In this test the communication link between sites is failed or disconnected. When site 1000 use a TxFrm to site 2000 the following capture is observed:

Fig 2. Wireshark capture between site 1000 and 2000 using TxFrm. Bad communication between sites

Site 1000 did three attempts of the “SYN” message to the destination site (Site 2000) with a 10 second delay between each try. These results are correlated back to the Advanced Port Settings of the unit:

The Poll interval parameter is the time delay between retries (10 seconds in this example) and the Maximum number of poll parameter is the number of retries to send a message (3 in this example).

The importance of this parameters is that it allows a programmer to adjust the time delay between retries and the number of “MDLC” retries, without any additional programming at the application level. Configuring this parameter accordingly reduces the possibility of overruns when a message is transmitted. Message overrun is a term we use to describe when the application attempts a retry prior to the MDLC retry attempts expiring, this could cause the transmission buffer of one site to become full and the potentially start dropping messages and affect the performance of the CPU.

Finding the optimum balance between time and number retries and listening time (RTU is not sending messages) can be key to fixing communication issues and streamlining communications. The optimization procedure can be extensive and have multiple iterations before finding the correct balance; considerations to the network structure, speed, data reliability and the particular application will have to be considered to make proper adjustments.

Another important feature of the test was to demonstrate the use of network capture tools such as Wireshark to do diagnostics and help on the parameter settings configuration using reliable data.

On the next article a similar test will be performed using a transmission type SndFrm (Send Frame) between sites. We will show the parameters effect on the sites that communicate using this type of frame.

2 Comments

Yes although using RS232 does not include the IP syn and ack messages. The retries at the MDLC level are still predicated upon the port settings. Typically those retries are factory default set to, 2 retries at a 5 second interval. Meaning if your application is set to 10 seconds to retry on the same site, the following could be happening. IE: (HH:MM:SS:mmm) Application try at 4:00:00:00 PM, after 5 secs the time is now 4:00:05:00 PM the first MDLC retry. The time would be at 4:00:10:00 PM on the second MDLC retry. Now your application is completely unaware of these retires and will try again at 4:00:10:00 PM while MDLC does not give up until 4:00:15:00 PM. Not an issue for one site but with multiple sites during a polling cycle this can compound into an application over run issue, especially if you have a lot of consecutive failed sites. Which I would plan for anyway, obviously no one wants to see that but that’s what programmers need to anticipate. I would strongly suggest that you use a protocol analyzer to capture the data during a polling cycle and pay very close attention to the timing of each message being sent along with the time between each message. Please also note that if you are using third party protocols such as Modbus then all of this is mute. There are no retries associated with third party protocols, since the third party protocols do not support Motorola MDLC. If you are using STS you can simply double click on the port in question (SI1) in the STS Project you are working on and this will provide a pop up window showing the Physical layer and Link layer advanced settings. Physical layer typically holds the interval between retries and the link layer will hold the number of retries. Feel free to let us know if you need further assistance. We are always happy to assist. Regards Chris Phelps.