Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

TCP/IP Communication - Messages lost

Created by: Kramps at: 6/10/2009 12:22 PM (7 Replies)

Rating (0)

Thanks 0

8 Entries

6/10/2009 12:22 PM	Rate (0)
Kramps Posts: 66 Rating: (2)	Hi, I am using a CPU414-3 with a CP443-1 Communication Board to communicate with another PLC (other brand than Siemens). It seems that sometimes some messages are lost causing some problems in my process. I've tried to look at the different diagnostic tools that are available (NCM S7 mainly). I can not see any error. To communicate with that other PLC, I've declared on Net Pro only one path giving me an unique ID. With that path, I'am using several AG_LSEND and one AG_LRECEIVE. As my software is configured right now, it is possible to perform several call of the AG_LSEND block at the same time (activation of ACT input). I heard that it might cause some problems and that we might use a semaphore to share the connection ressources. Is that true ? Is there a way to see this kind of error in the diagnosis ? Same thing do we have to wait that done signals have been set on every send block to send a new message ? Thanks for your answer, Best Regards, Kramps
Kramps Posts: 66 Rating: (2)
Suggestion To thank Quote Answer

6/10/2009 5:11 PM	Rate (0)
Sydney Gold Member Joined: 1/4/2008 Last visit: 9/26/2024 Posts: 703 Rating: (96)	Hello, in this type of communication you could use only one pair SEND/REC for one connection. Ok, could use more, but not at the same time and how would you synchronise which pair is to becommunicating now? So if you can't use the S7 connection, maybeyou could establish more ISO-on-TCPconnections with this partner, but I suggest to use only one connection and one pair SEND/REC. Make the data length as big as the longest data packet and make the identification (ID)inside. Sending of the new message could be started after the last is finished (done or error). So you would use some message queueor counter for controlling which datashould be sent nowand when receive a new message, read the ID inside and send the data internally to prepared location accordingly. Regards Sydney
	Last edited by: Sydney at: 6/10/2009 5:26 PM sure the english isn''''t still o, but at least some corrections ;o) Last edited by: Sydney at: 6/10/2009 5:23 PM
Suggestion To thank Quote Answer

6/11/2009 8:55 AM	Rate (0)
Kramps Posts: 66 Rating: (2)	Thanks for your answer. I am not sure that we are speaking of the same ID (seems odd to me). I am talking of the ID used internally by the Hardware Configurator (Netpro) & the AG_LSEND/AG_LRECEIVE blocks and not the ID that is included in my TCP/IP Message. Generally speaking for reception I don't have any problem concerning the size. I am always using only one reception block, that is always expecting the same size of message. On the opposite, for the send direction, I do use several send blocks with different sizes of messages. I don't have to make any identification of the messages, I just have several different messages that are trigerred on event. Moreover, I can not modify the communication philosophy on the other system which is not open to modifications.
Kramps Posts: 66 Rating: (2)
Suggestion To thank Quote Answer

6/11/2009 9:56 AM	Rate (0)
Sydney Gold Member Joined: 1/4/2008 Last visit: 9/26/2024 Posts: 703 Rating: (96)	Sorry for mistaking, the ID what I wrote about isn't that ID from the connection configuration, I meant the identification of the message inside the data, lets say "MessageID". When you can receive a few different messages, then you have to know which messege you've received, because the block you use have just an CP address (LADDR) and connection number (ID). So for sending you have to add the MessageID to let the receiver know what are that data for. When NDR comes high, read the MessageID and transfer the message accordingly. Regards Sydney

Suggestion To thank Quote Answer

6/11/2009 8:26 PM	Rate (0)
jklm Platinum Member Joined: 12/22/2006 Last visit: 1/25/2022 Posts: 1742 Rating: (309)	Hello, I understood that you use the native TCP protocol (not ISO on TCP). TCP is stream based and you must take this into account, especially if the messages have a variable length. Here an example. http://support.automation.siemens.com/WW/view/en/19033929 Intesting also in that example is that on the same connection, you may only start the send only once till you get done. Here another FAQ on the usage of AG_LSEND http://support.automation.siemens.com/WW/view/en/24693800
	Best regards jklm Suggestion was helpful? Feel free to rate it.
Suggestion To thank Quote Answer

6/11/2009 10:42 PM	Rate (0)
Krish Silver Member Joined: 5/24/2007 Last visit: 4/24/2024 Posts: 284 Rating: (27)	Hi Kramps Your methodseemssimilaras we had done with our communication initially and we had exactly similar problems. We had the following done to prevent such data losses. At any one cycle only one telegram (one AG_SND was active). This was done byenabling a bit when one AG_SND was active and thendisablingwhen DONE bit for that SEND was complete. Any telegram is sent only when this bit is was not enabled. By the way did you use AG_SND or AG_LSND. There is a limitation of 240 bytes for AG_SND. Additionally what you should be aware that the CPU to CP communication is limited to 240 bytes only and so one activation fo AG_LSND only 240 bytesis done. That means it needs more than one cycle to send more than 240 bytes or you need to call it in loops. The CP buffer is also 6KB. If you exceed it then you will loose the data also. Hope this helps you to diagnose your problem. Krish

Suggestion To thank Quote Answer

6/13/2009 9:34 AM	Rate (0)
Kramps Posts: 66 Rating: (2)	Dear all, Thanks for your answers and sharing your experience. By saying only one send block must be activated at time, do you mean the ACT input of the block or the enable of the block itself ? What I plan to do is : - Use a counter to organise sending. - Each send block has its corresponding number and can only operate whenever the counter is set to this value. - Once a request to send a message is given to the send block, send block must first wait that the counter is equal to his dedicated value. - Once it is the case, BUSY signal will be set and message sent. - Once AG_LSEND block has done the sending or if error occurs, BUSY will be reset and counter will be set to the next value. - If one send block receive the counter and he doesn't have any send request, he sets the counter to the next value in order to authorize next send block. - For reception I am not going to do anything as there is only one AG_LRCV block so there is no ressource sharing problems. Seems better to me. Any opinion ? The size of the buffer of the CP is for the total or for one connection ? Is it managed automatically by AG_LSEND/AG_LRCV (once you are configuring it correctly of course) ? Best Regards, Julien FREUND.
Kramps Posts: 66 Rating: (2)
Suggestion To thank Quote Answer

6/13/2009 8:51 PM	Rate (0)
Krish Silver Member Joined: 5/24/2007 Last visit: 4/24/2024 Posts: 284 Rating: (27)	Dear Julien Well activates once means the function AG_LSEND is being executed. Normally this is once in scan cycle. But you could also use loops to call it again in one scan cycle itself. Your idea is like a token based system which is quite ok. The CP buffer size is the memory size the CP has for TCP/IP connections. So if you have more connections, it willbe shared. But 6kB is quite OK fortypical applications. Krish.

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on