Skip to Content

SiePortal

The integrated platform for your product selection, buying and support workflow - bringing together Industry Mall and Online Support.

SiePortalDeutsch

Search

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menu temporary not available
- Menue temporary not available
- {{item.title}}

Products & Services
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Cart ({{apiData.CartCount}})

Navigation

CP343-1 Advanced - Ethernet Communication - Multiple sends, receive.

Created by: EyKo at: 6/17/2008 1:13 PM (11 Replies)

Rating (0)

Thanks 0

Result pages:: |; 1 | 2; |

12 Entries

Entries per page: 10 | all

6/17/2008 1:13 PM	Rate (0)
EyKo Posts: 10 Rating: (0)	Hello, I am a French student who is making a 3 months internship, so I am quite new at Step7 programming. I have to establish a communication between a PLC and a PC using cp343-1 Advanced. I have read the faqs and the forum but Istill havesome problems. What I would like to do is to send a string from the PLC to the PC. The PCreceives the string, decodes it, and sends back an other string with the result of the operation. I use FC6: ag_recv to get the reply from the PC. All of this works well, I manage to receive the reply and to store it in a DB, but only if I have the LEN parameter for ag_recv function exactly equal to the length of the reply message. Is there a way to change this? I noticed that if the LEN parameter of ag_recv is smaller than the length of the message, I only receive a part of the reply, and it doesn't store it in the good memory area. I have read that there are two possibilities. Either we add into the reply a header with the length of the message, or we receive the reply byte by byte, until detecting the end of the string (with a carriage return for example). The replies don'thave any of this formatand I can't change them. Are there any other possibilities? Moreover, I have to send multiple requests. It works fine, but I'm not able to receive all the replies with different lengths. How can I do? Thank you in advance for any information you can provide.
EyKo Posts: 10 Rating: (0)	Last edited by: EyKo at: 6/17/2008 2:44 PM
Suggestion To thank Quote Answer

6/17/2008 3:09 PM	Rate (0)
J_Bell Posts: 5822 Rating: (412)	Dear EyKo, I am sorry, but as you found out yourself already this is not possible with the CP. The only Ethernet interface that is able to decode variable length of received Telegrams is the PN CPU with T-Communication. As you are not able to change something in the transmitting PC I fear the change on the PLC side is your only chance. Best regards J_Bell
J_Bell Posts: 5822 Rating: (412)
Suggestion To thank Quote Answer

6/18/2008 8:52 AM	Rate (0)
EyKo Posts: 10 Rating: (0)	Dear J_Bell. Thank you for your reply. I will study this possibility. Regards
EyKo Posts: 10 Rating: (0)
Suggestion To thank Quote Answer

6/18/2008 10:43 AM	Rate (0)
EyKo Posts: 10 Rating: (0)	Hello, There are maybe two morepossibilities. Can you tell me what are you thinking about them? The first one relies on the fact that we may only need the beginning of the reply string. So we may use a fixed length for the ag_recv function (the length of the shortest possible reply) and so i could only receive a certain amount of characters. With these characters Imay be able to extrapolate the good message. Will there be a problem with the characters I have not received? Will they stay in a buffer or somewhere? I have tried this before, but I had some strange results. Do you know anything that can help? The second one is to make different calls of ag_recv. The first call will detect if the message is finished or not. If it isn't, we may call an other function ag_recv. But it supposes that the message is not lost after the first call of ag_recv. What do you think about that? I agree that it is not the proper way to do this, but if it works... Best regards.
EyKo Posts: 10 Rating: (0)
Suggestion To thank Quote Answer

6/18/2008 11:24 AM	Rate (0)
J_Bell Posts: 5822 Rating: (412)	Dear EyKo, well, the issue is that the storage of each connection works like a circular buffer. So if you collect some bytes of a Telegram the left data will stay in the Buffer until you empty it of the next Telegram fills the Buffer that far that the next receive can collect as much data as it requires. To get rid of the data that is still in the buffer there are two strategies. First would be to poll the Buffer byte wise to get the Buffer emptied. The second one would be to flush the buffer. As I sadly not know if the Advanced CP you have supports this function I would try to study the manual of the CP if the AG_CNTRL Function is supported with your CP. If this is the case this would be your solution. Best regards J_Bell
J_Bell Posts: 5822 Rating: (412)
Suggestion To thank Quote Answer

6/18/2008 3:19 PM	Rate (0)
EyKo Posts: 10 Rating: (0)	Thank you :) I think it can work with this method. All I have to do is to flush the buffer. I have looked for the AG_CNTRL FC but I didn't find anything in the manuals. I have then tried to implement it directly in my program, but it didn't compile. I guess there is no way to use this function with CP343-1 Advanced. What do you mean by "poll the buffer byte wise" ??? I don't understand this sentence :/ Best regards
EyKo Posts: 10 Rating: (0)
Suggestion To thank Quote Answer

6/18/2008 4:02 PM	Rate (0)
J_Bell Posts: 5822 Rating: (412)	Hello EyKo, what I wanted to say with "poll the buffer byte wise" is the following: If you received a certain amount of data and stored it to your DB than the Buffer in the CP is still not empty. To get the DB empty you can call an AG_RECV with only one byte length and you call this AG_RECV as long as you get data. As soon as you wait, maybe about a second and the AG_RECV did not receive anything you go back and call the AG_RECV with the minimum length to identify the content. I hope I made my point more clear right now. Best regards J_Bell
J_Bell Posts: 5822 Rating: (412)
Suggestion To thank Quote Answer

6/19/2008 9:56 AM	Rate (0)
EyKo Posts: 10 Rating: (0)	Thank you J_Bell. I tried it this morning and I managed to have good results. Best regards.
EyKo Posts: 10 Rating: (0)
Suggestion To thank Quote Answer

6/19/2008 10:02 AM	Rate (0)
J_Bell Posts: 5822 Rating: (412)	Dear EyKo, these are good news. I am lucky that it works right now. Best regards J_Bell
J_Bell Posts: 5822 Rating: (412)
Suggestion To thank Quote Answer

7/14/2016 4:49 PM	Rate (0)
Kharadi Gaurav Regular Member Joined: 9/1/2010 Last visit: 3/20/2025 Posts: 4 Rating: (0)	Dear J-Bell, I am using CP 343-1 Lean for Communication with Third party device over Ethernet (Not Modbus TCP/IP). Response received from third party device varies from 64 bytes to 200 bytes. If i set length less than 64 bytes, i am not getting data. If I set length >=200, data circulates in receive DB. How to reset CP buffer after receiving data or How to get data without circulating in DB? Please help. J_Bell Dear EyKo, I am sorry, but as you found out yourself already this is not possible with the CP. The only Ethernet interface that is able to decode variable length of received Telegrams is the PN CPU with T-Communication. As you are not able to change something in the transmitting PC I fear the change on the PLC side is your only chance. Best regards J_Bell

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on