Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

Receiving TCP Telegrams greater than 240 bytes

Created by: Krish at: 6/23/2007 4:45 PM (12 Replies)

Rating (0)

Thanks 0

Result pages:: |; 1 | 2; |

13 Entries

Entries per page: 10 | all

6/23/2007 4:45 PM	Rate (0)
Krish Silver Member Joined: 5/24/2007 Last visit: 4/24/2024 Posts: 284 Rating: (27)	Hi Everybody We use TCP telegrams to communicate with a PC Station. Some of these telegrams are greater 240 size. To receive the telegram we have a buffer which is the same size of the telegram which is being received. This buffer is definedas STAT in the receiving FB. As long as the buffer size is less than or equal to 240 bytes the receive of telegrams works fine. But when it is increased we get errors. The send of the function of any size (we tested upto 6kbytes) works fine.But receive doesn´t.We are using AG_LSEND and AG_LRECV for the send and receive functions so nothing can bewrong. Does anybody have an idea why this concept does not work for receiving of telegrams. Thanks in Advance

Suggestion To thank Quote Answer

6/24/2007 11:20 AM	Rate (0)
Late Platinum Expert Joined: 1/7/2006 Last visit: 12/23/2024 Posts: 2705 Rating: (320)	Hi Krish, You didn't mention which CP's you are using, so I have to guess which you have, for some CP's there are in the projecting of the hardware a checkmark with"> 240 byte". Also you have to wait until the data is all inside the CPU, between the CP and the CPU, the AG_LRECV have to get all information inside. This may use several cycle, please look very well to the NDR, ERROR and STATUS bits/word. Also the AG_LRECV is not alife anymore for the S7-300 with newer CP'sin newer versions of STEP7, the standard AG_RECV (V2.4)is doing the job (look in the help <F1> in the blocks). Have you some errors on the STATUS, please look to them very accurately. See also the next link for some information Industrial Ethernet: using the AG_SEND and AG_LSEND blocks
	I hope that the answer will help, if you have still questions, don't hesitate to ask me. All the best, Late Never say never, think in solutions, not in trouble......
Suggestion To thank Quote Answer

6/24/2007 2:02 PM	Rate (0)
Krish Silver Member Joined: 5/24/2007 Last visit: 4/24/2024 Posts: 284 Rating: (27)	Hello Late Thanks for the reply I totally forgot to mention that. Well we use typically S7-400 series CPUs and in this case it is 416-3. I had originally CP 443 but changed it later CP 443- Advanced. Also all necessary precautions for working with larger size has been taken care. As mentioned I have no problem in sending telegrams as big as 6kB. Somehow we run into problems only in the receive.I guess it is something to do with the bufferin which we receive.I have got aroundby breaking the buffers into smaller buffers of 240 kbmax size. ButI am not satisfied with the solution.Planning to work on itonce I am off the deadlines . But meanwhile if somebody has a more elegant solution Iwould greatly appreciate it. Thanks for the reply. Krish

Suggestion To thank Quote Answer

6/24/2007 3:13 PM	Rate (0)
Late Platinum Expert Joined: 1/7/2006 Last visit: 12/23/2024 Posts: 2705 Rating: (320)	Hello Krish, Between the CP and CPU the length of data could be not bigger then 536 byte (maybe not the exact length) and so a block have to be devided into several blocks and so also be called several times with AG_LSEND (the AG_LSEND is doing that automatic over several cyclic calls). Also between the PC and the CP there are restrictions, when the PDU-size is for example 1024 byte then there are also more frames for one telegram, the CP would not recognise the beginning and end of the telegrams, so only fixed length TCP-telegrams are easy to work with (length parametrized on the AG_LRECV). When you have different lengths of telegrams then please use ISO-on-TCP when possible. Also the TCP-connection might do some strange things, in a PC you don't have to do anything with a TCP-frame, but in a CP/CPU there are some things you have to pay attention to. Please read the next FAQ Why under certain circumstances are there very long response times with TCP connections and see if there are any restrictions you have to pay attention to.
	I hope that the answer will help, if you have still questions, don't hesitate to ask me. All the best, Late Never say never, think in solutions, not in trouble......
Suggestion To thank Quote Answer

6/25/2007 10:13 AM	Rate (0)
J_Bell Posts: 5822 Rating: (412)	Dear Krish, I would just wonder two things: 1. I guess you use TCP Protocol, am I right? If so how do you figure out the exact Data length of the TCP Frame, do you poll the Data Byte wise or do you know the exact size of the Data you expect on the Connection? 2. Have you ever tried to work external DB’s? I know the FB IDB is also a DB but I have seen too many problems with data areas other than Global DB’s. Best regards J_Bell
J_Bell Posts: 5822 Rating: (412)
Suggestion To thank Quote Answer

6/25/2007 12:58 PM	Rate (0)
Krish Silver Member Joined: 5/24/2007 Last visit: 4/24/2024 Posts: 284 Rating: (27)	Dear J_Bell,Late About your questions. 1. Yes we use TCP. I know ISO-on-TCP is safe. But we have a C++ program on the other side and we have programmed it to listen to a port number and it just gets telegrams from the PLC. I never put my mind into figuring out how to work with ISO-on-TCP. Somebody has some knowledge on this, Iwould very much appreciate. The way we have done the receive (similar on the receiving C++ program also), we first go into collect the data byte by byte and when 6 bytes match the telegram header which we have defined we change the buffer size to thedefined telegram size. Alsowe have a variation where the 7 byte is thebuffer size.The idea is to have fastest possible communication (byte by byte is quite slow) and reliable withmuch loss ofdata (6 byte identification done byte by byte to minimizedata loss). 2. No I have not tried with External DB. Actually we started with telegram sizes less than 240 and this system has been funcioning for the last 4 or 5 years and had not much reason to look for better solution. Now that we had to increase the sizes, we have to explore. I will test it (away from the project work) and will let know. Might take sometime as we are bogger down now. To Late´s observation (you have choosen such an odd user name, ..got to be careful while addressing you..), we had already look at this documents and countless forums about this TCP protocol with Siemens and seen through all this. Actually we like the general implementation quite a lot because using Ethereal you can actually see how well the system functions beyond the CP level and diagnosis of problems is so realistic that even for beginners the implementation(on how the protocol works..and what happens)is quite clear and obvious that we have stuck to it. The problem is quite interesting and would definitely keep you guys informed on what we find. Thanks a lot for your efforts Krish

Suggestion To thank Quote Answer

6/25/2007 3:39 PM	Rate (0)
J_Bell Posts: 5822 Rating: (412)	Dear Krish, could you please tell us, because you said you use this already for some years, which CP and which FW Version you use with this CP? Maybe there is a Fix in a Firmware version available right now. Best regards J_Bell
J_Bell Posts: 5822 Rating: (412)
Suggestion To thank Quote Answer

6/26/2007 3:00 PM	Rate (0)
Krish Silver Member Joined: 5/24/2007 Last visit: 4/24/2024 Posts: 284 Rating: (27)	Dear J_Bell We are using CP 443 (6GK7 443-1EX11-0XE0 Version 2.3) for the current project.We have been using CP443 always (though older firmwares). Ihaven´t looked forlatest versions. But I doubt if anybody has faced this problem like us. Thanks for Your Efforts Krish

Suggestion To thank Quote Answer

6/26/2007 5:17 PM	Rate (0)
J_Bell Posts: 5822 Rating: (412)	Hello, you may try this one here: CP 443 -1 Firmware Update V2.6 and Unrestricted Use in any Hardware Release (6GK7443-1EX10-0XE0 and 6GK7443-1EX11-0XE0) Best regards J_Bell
J_Bell Posts: 5822 Rating: (412)
Suggestion To thank Quote Answer

7/2/2007 11:17 AM	Rate (0)
Krish Silver Member Joined: 5/24/2007 Last visit: 4/24/2024 Posts: 284 Rating: (27)	Dear J_Bell Finally I could get some time to test it out and though I have got it working I don´t know the reason why it did not before. Well, I installed the latest updates as mentioned by you before I started testing. Thanks A Lot. BasicallyI used pointers to point to the buffers where a particular telegram data has to go onceI identify the telegram with it first 6 bytes. Whenever the buffer size was greated than 240bytes we got the message that the destination area is not correct. The change I made was to replace the pointer to the buffer (in AG_LRECV) with actual data block directly. With this I had no trouble with any size. The same works with also instance DB instead of normal DB. Only negative part of this style for me was that for every telegram I have a seperate AG_LRECV (of course using the same connections) unlike before when I had just one AG_LRECV. Funny thing is I create a pointer to the same datablocks , it works fine as long as the it is smaller than 240 bytes.Bigger than that I get the error code. Any ideas why it should be so!! Thanks for your efforts.

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on