2/26/2011 8:01 PM | |
Posts: 14 Rating: (0) |
dear friend, what kind of problem u r facing,,,clearly explain,,,what kind of nodes , u r having |
2/27/2011 12:29 PM | |
Joined: 10/7/2005 Last visit: 5/29/2024 Posts: 3007 Rating: (1049)
|
Hello Begginer my guess is that the nominated receive lenght (ANY pointer declaration of AG_RECV's "RECV" Parameter)does NOT match the lenght of the messagethat is being sent by the partner which would lead to a perceived shifting of the values in your receive DB. Example: You declare P#DB10.DBX0.0 BYTE 22 for AG_RECV's "RECV" Parameter. The partner station does however always only sends20 Bytes of data. The CP343-2will now buffer the first 20 Bytes,wait for the next 20 Bytes to arrive and AG_RECV will then grab 22 Bytes from the CP's buffer (20 Bytes of the first telegram and the first2 Bytes of the second 20 Byte long telegram, this process will continue this way and be perceived as shifitng data in the receive DB). Note too that the "LEN" output of AG_RECV will with TCP/IP simply reflect the nominated lenght in the ANY pointer declaration of AG_RECV's "RECV" Parameter. The "problem" with pure TCP/IP is that it isdata stream orientated and does not contain information about the length or start/end of a message (see HERE for more) and as such youmust ensure that you either: 1) Agree on a fixed (or static) message lenght or 2.) Implement other ways to handle variable message lenght (see HERE for an example) or 3.) Use ISO-on-TCP if the partner supports it (see HERE for more)or I hope this helps |
Cheers |
|
This contribution was helpful to1 thankful Users |
3/1/2011 1:44 PM | |
Posts: 112 Rating: (0) |
Thank you very much Fritz |
This contribution was helpful to1 thankful Users |
Follow us on