TCP Communication Response Time

[tingxing 1]

Hello, I try to setup TCP communication between a PC and Q CPU using MC protocol (3E Ascii). My problem is, I found the communication response time is rather long: about 250ms - completely not negligible. To be specific, the response delay is found to be the time between send over and when data available at the TCP stream. Is this related to some setting at the Q CPU side? Many thanks in advance. Ting

[kaare_t 155]

It should not be like that!! Which software do you use on the computer side?

[tingxing 1]

I use C# (.net 3.5) tcpclient component. As for the 3E frame, there is a field for timeout whose unit is 250ms (1=250ms, 2=500ms...). Really I set the value to 1. But it seems this should not be the reason for the nearly 250ms delay, it should only be a timeout value. I also think the PLC cpu should not have taken so long to respond. Xing

[kaare_t 155]

OK. After the 250ms delay, do you get a request ACK, or NAK (in other words, was it succesful or un-succesful)? Can you update values in the PLC correctly, or read them correctly?

[tingxing 1]

The communication is OK - ZR device was successfully read. I checked and found, it almost took no time until sending over. But after send over(by PC) and before data available at the tcpclient of PC, almost 250 ms elapsed. Xing

[kaare_t 155]

Just for testing, what happens if you set the timeout field to e.g. 4 (1000ms)? We could check if that's where the delay comes from, or if it's something else....

[tingxing 1]

I have tested, to set the timeout to 500, or even 0, the delay time is almost the same, 250ms. Because I am reading ZR, I tried to read a different kind of device: D", it turned out to be the same. Really queer. For a large block of data, there wont be more delay due to TCP speed. But this delay is really annoying, it restricts my access to PLC data only 4 times per second. Xing

[kaare_t 155]

I think that the problem must be in your C# program... Because the timeout setting obviously does not have any effect on the delay time, the problem must be somewhere else, and the "only" thing that's left is then your C# application. As I mentioned earlier, it should not be like this, and the fact that changing the timeout setting does not affect the overall performance indicates that the timeout setting has nothing to do with the delay you experience. IF the timeout setting was the problem you would have a propotional increase in delay when increasing the time. Hence, the only thing that's left is the C# application. May I ask for some more information regarding your C# program? Did you write the MC protocol yourself or are you using MX Components? Could you share your C# application so that I could take a look (if you do not want to post it in public, PM me for my e-mail address)?

[kaare_t 155]

By the way: You say you use TCP communication. How do you handle each request in your C# application? Do you 1. Open a TCP socket, send a request, then close the TCP socket. Open a TCP socket, send a request...... 2. Open a TCP socket, send a request, send a request, send a request..... This is a very important sequence question, so please respond to this.

[tingxing 1]

Thank you very much for your analysis Kaare. It is not I do want to open the code, but because it is not strictly modular and hard to extract. The segment related to TCP communication is merely a use of Tcpclient of .Net 3.5. I just 1. establish connection ( at the initialization stage of my C# program) when it is time to do communication: 2. send communcation test 3. wait for response ready, which is tcpclient::GetStream().DataAvailable I dont close the connection until my program exits. And I am not using MX component. I assemble MC protocol communication text from scratch: it is not very complicated. And because even though there was delay, I got proper response from PLC, I think there is not anything wrong with the usage of MC protocol. Xing

[kaare_t 155]

OK, but have you checked your response against ACK/NAK? There is a possibility that the PLC replies with the correct data but with an error code or similar. Alternatively, are you sure that your receiving C# is working correctly and not searching for an ACK in the received data, but the PLC actually sent NAK? Did you implement any kind of receive-data checksums or do you just apply checksums to outgoing data and never check the received data. How does your receive code woks (pseudo-code or similar...)?

[tingxing 1]

I think there is no problem with response code. If there is anything wrong, the returned error code will be received. Because my return code is 0000, everything is right. I did some earch, and discussion indicate "IgnorePushBitOnReceives" of windows system is a cause. But even if I have changed the IgnorePushBitOnReceives to 1, there is no improvement. Xing

[kaare_t 155]

OK, When you monitor the TCP connection and data exchange with Wireshark, how does it look? Does the reply from the Q come instantly or can you actually see a ~250ms delay?

[tingxing 1]

I tried to monitor it with wireshark, the following is the monitoring result for ZR device read (only 1 word): 10 7.855994000 192.168.31.20 192.168.31.10 TCP 96 imgames > blackjack [PSH, ACK] Seq=2 Ack=1 Win=65535 Len=42 11 7.874295000 192.168.31.10 192.168.31.20 TCP 80 blackjack > imgames [PSH, ACK] Seq=1 Ack=44 Win=5840 Len=26 *500000FF03FF000018000104010000ZR0027ED0001D00000FF03FF00000800000025 the Len=42 message is what I sent to PLC, and the next line is what I received. There is not too much delay in response ? Xing

[kaare_t 155]

You have a 18ms delay between your reqest to the PLC until it gets back to your computer. So basically from your computer sends the request, until your computer receives an answer it takes 18ms. So somewhere in your C# code you have a delay...

[tingxing 1]

Sure, I also tell from the data, there are only tens of millisecs. I have to check it further. I tried to downsize the receive buffer of my Tcpclient, and change the NoDelay setting and so on. I think there must be a solution available - 250 ms is just unbearable! Xing Edited 27 Sep 2013 by tingxing

[tingxing 1]

I have asked Mitsubishi online, and they said their CPU's TCP implementation has push bit set to "1" ! I am now asking them if they got the data of repose time of communicating with windows PC, especially when reading 1 word from some device. Xing