When working with the free port communication feature of Siemens S7-200, it's essential to configure the serial port properly through programming. This includes setting the correct mode, managing the sequence of sending and receiving commands, and defining the start and end conditions for data reception. For engineers new to this system, there are many subtle details that can lead to errors. When customers report communication issues, one of the first steps is to verify if the configuration is correct. While this process can be tedious, going through each step carefully usually helps identify and resolve the problem.
However, one customer faced a situation that was quite unusual. After writing the free port communication program, the PLC could send data to the other party but failed to receive any. Since sending worked, it indicated that the port settings were likely correct. The issue might have been that the port was being blocked by other commands, preventing it from entering the receive mode. For example, if the XMT instruction was triggered incorrectly or if the system didn’t check for faults before starting a receive operation, it could cause subsequent commands like RCV to fail.
The customer claimed their program didn't have such issues. To test, they tried a simplified version that only included a conditional RCV command, but still no data was received. The RCV instruction itself appeared to execute correctly in the monitor. At this point, we began checking the initial conditions for the receive function. The customer used a start character, which was not incorrect. Even after switching to idle line detection, the problem remained. Could the issue lie with the data sent from the other side? It turned out that the signal could be received using serial debugging software, ruling out external interference.
Since common mistakes didn't explain the issue, I had to go through the program with the customer step by step. But nothing obvious was found. Frustrated, I asked them to send the actual program for further analysis.
At first glance, I couldn’t see the problem. Then I realized something very simple—yet critical. After setting the idle line time (SMW90) and the message timer overflow value (SMW92), the customer mistakenly assigned the maximum number of characters (SMB94) to SMW94. However, in Siemens PLCs, the high and low bytes are reversed. That means SMB94 is the high byte, while SMB95 is the low byte.
The result was that the maximum number of characters (100) was written to SMB95, which was essentially ignored. Meanwhile, SMB94, the actual byte that holds the maximum character count, was set to zero. As a result, the PLC thought it could only receive 0 characters, so no data was ever accepted.
This was a classic case of a small detail causing a big problem. It’s a good reminder that even minor misconfigurations can lead to major communication failures. Always double-check your byte order and memory assignments when dealing with Siemens PLCs, especially when working with free port communication.
Optical Filter,Long Wave Pass Filter,Optical Pass Band Filter,Bandpass Filter
Danyang Horse Optical Co., Ltd , https://www.dyhorseoptical.com