µTasker Forum

µTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: chronosdino on December 11, 2008, 08:49:23 AM

Title: Modbus TCP/IP
Post by: chronosdino on December 11, 2008, 08:49:23 AM
Hi every one !


I have try to do some modbus TCP/IP communication for my project.

The modbus TCP is only a send or reaceave of data by TCP/IP on port 502.

I have try to do the serveur ( that mean that the freescale microchip listen for connections) and everything is ok

Now, i have try to do the oposite, that mean, that the frescale must be the client ( i have to connected me to a computer where a server is on)

i have use wireShark to see the different tcp frame.

the connection is o, but when i send some data, i see on wireshark that it is a warning about "retransmission" and my server only see few frame.

My vision is that i didn't ACK.

i can send a part of my code, have you got any idea before ?!



Thanks for reading
Title: Re: Modbus TCP/IP
Post by: mark on December 11, 2008, 10:12:24 PM
Hi

I think that it may be useful to first see the Wireshark recording so that the behavior can be better understood. Could you post it here?

regards

Mark
Title: Re: Modbus TCP/IP
Post by: chronosdino on December 17, 2008, 03:36:01 PM
There is no probleme, i have keep back my system, end i have recorded the wireshark view.
What do you think about it ?

ps : 192.168.0.89 is the ColdFire in Client mode
     and 192.168.0.62 is my computer with OMBServeur (free 15 minutes version)
Title: Re: Modbus TCP/IP
Post by: mark on December 17, 2008, 06:44:45 PM
Hi

I just looked at the recording and see that after you have established a TCP connection you are sending 2 TCP frames. The content looks identical so I don't know whether you intend this.

Using the simple TCP interface (without buffering) it is not allowed to send 2 TCP frames in the same session without first receiving an ACK to the first one. This is why the second is sent with the same sequence number and thus displayed as "out-of-order".

See why it is sending the first frame twice and, if you can correct this so that it waits for the ACK to the first frame before sending the next, it will probably work correctly.

Regards

Mark