Siemens S7-200 free port communication troubleshooting measures - Database & Sql Blog Articles

SMD aluminum electrolytic capacitor

Brand AVX TPSE226M035R0125 Low impedance tantalum capacitor AVX 22

Electronic scale crystal oscillator 3.2*2.5mm 3225 16M (16.000MHZ) 12PF 10PPM 20PPM 30PPM

The free port communication of Siemens S7-200 needs to set the working mode of the serial port by programming, arrange the triggering sequence of sending and receiving commands, and set the starting and ending conditions of receiving. For electrical engineers who are just starting to use the s7-200, there are a lot of subtleties that make mistakes. Generally, when the customer complains about the problem of communication failure, it is necessary to help the customer to confirm whether the programming configuration is correct. Although it is troublesome, but check it one by one, you can always find the error and solve the problem. But one customer encountered a problem that was quite unexpected and it took some time.

Customer Response After writing the free port communication program, plc can send data to the communication partner, but it does not receive data from any partner. Can send data to the other party, indicating that there is no problem with the communication port settings. It is highly probable that the port is occupied by other communication commands and cannot enter the receiving state. For example, the XMT is called with a normally open point, or the received fault state is not judged and the reception is terminated, so that subsequent XMT and RCV cannot be executed correctly. The customer stated that his program did not exist. But in order to test the problem, the customer downloaded a program that only contains the conditional trigger RCV, or did not receive the data. The monitor RCV instruction has been executed normally.

Then is the initial condition of the reception set incorrectly? The customer is using the start character, which is not wrong. And after changing to idle line detection, the problem still exists. Is it a problem with the signal sent by the other party? It can be received by the serial debugging software. Seeing these common mistakes failed to cover this problem, I had to confirm with the customer step by step. But still can't find any flaws. Under the sorrow, I had to let the customer send the program to see it.

When I first checked the program, I really didn't notice where the problem was. I don’t think it’s ridiculous until I see it:

I don't know if you can see it? After the customer sets the idle line time SMW90 and the message timer overflow value SMW92, the customer automatically writes the accepted maximum number of characters SMB94 as the transfer word SMW94. The high and low bytes of Siemens plc are reversed, that is, SMB94 is the high effective byte and SMB95 is the low valid byte. See the instructions in the manual as follows:

The result is that the maximum number of characters 100 is passed to SMB95, and SMB95 is a god horse? The god horse is not, in short, regardless of the receiving conditions. The true maximum character count byte SMB94 is assigned a value of zero. The maximum number of characters is 0, of course, no data is received.