Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

AG_SEND/AG_RECV data sent in one cycle?

Created by: V4Friend at: 1/25/2010 2:46 PM (6 Replies)

Rating (0)

Thanks 0

7 Entries

1/25/2010 2:46 PM	Rate (0)
V4Friend Advanced Member Joined: 11/30/2007 Last visit: 12/20/2024 Posts: 44 Rating: (1)	Hello communication-experts I have successfully created ISO Transport connections between an S7-400 cpu and a Simatic TI505 (using AG_SEND and AG_RECV). The number of bytes is limited to 240 bytes and (for now) that is sufficient. The question I have is this: are all of the 240 bytes communicated in one 'cycle', so I can count on it that all the data arrives in the other PLC at the same time? Thanks in advance...
	Last edited by: V4Friend at: 1/25/2010 2:46 PM It's life Jim, but not as we know it...
Suggestion To thank Quote Answer

1/25/2010 3:00 PM	Rate (0)
smiffy Platinum Expert Joined: 1/17/2007 Last visit: 12/5/2024 Posts: 1548 Rating: (538)	I suppose it would depend on how fast your cycle is. It will take a finite period of time to send / receive the data. The time required will be dependent on the link speed and the ammount of data to be send / received. If your cycle time is less than this time, then I expect that it will take several cycles to complete.
	Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. So far, the universe is winning...
Suggestion To thank Quote Answer

1/26/2010 9:25 AM	Rate (0)
V4Friend Advanced Member Joined: 11/30/2007 Last visit: 12/20/2024 Posts: 44 Rating: (1)	Hello Smiffy, Thanks for your answer. The reason for my question is the fact, that I send setpoints and commands for an Equipment Module to the TI505 PLC. I want to be sure that the setpoints are all written, before the command is executed... If I understand correctly, I should build a sort of check to verify all data is 'valid'?
	It's life Jim, but not as we know it...
Suggestion To thank Quote Answer

1/26/2010 10:31 AM	Rate (0)
smiffy Platinum Expert Joined: 1/17/2007 Last visit: 12/5/2024 Posts: 1548 Rating: (538)	Well that is quite simple to acheive. Simply setup the AG_SEND with the total packet size you want to send. Make the first call to AG_SEND with ACT:=1. This will initiate the transaction. Then repeat the AG_SEND call above every cycle but with ACT:=0. This just updates the DONE, ERROR and STATUS outputs and does not interfere with the current transfer. Once all the data has been sent, the DONE or ERROR flag with be set for successful or unsucessful transfer respectively. If there is an error, you can read the STATUS value to find out the error code. So when DONE or ERROR is set, you can be sure that the transaction is complete (successfully or not). First call (to be done once):- AG_SEND(ACT:=1,ID:=ID,LADDR:=LADDR,SEND:=DB1,LEN:=TXLEN,DONE:=DONE,ERROR:=ERROR,STATUS:=STATUS); Subsequent check calls (to be done cyclically):- AG_SEND(ACT:=0,ID:=ID,LADDR:=LADDR,SEND:=DB1,LEN:=TXLEN,DONE:=DONE,ERROR:=ERROR,STATUS:=STATUS); For AG_RECV, you use the NDR flag. This flag will be set when the ammount of data received is greater than or equal to the LEN parameter (the ammount of data you wish to receive). So you just keep calling the block cyclically until you see the NDR or ERROR flag set. If NDR set, you have sucessfully received your data, if ERROR set, the data was not received correctly so check the STATUS value for the error code. Just one word of caution. Be careful what OB you call the functions in cyclically. Fast OB's (especially OB1) can lead to saturation of the communications link and can impact on other communications on that link (e.g. the HMI interface). My suggestion is to perform the cyclic call every 10ms as that will not cause to much saturation, but will still give you prompt indication of when the data has gone/arrived (low data latency).
	Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. So far, the universe is winning...
Suggestion To thank Quote Answer

1/26/2010 2:54 PM	Rate (0)
V4Friend Advanced Member Joined: 11/30/2007 Last visit: 12/20/2024 Posts: 44 Rating: (1)	Hello Smiffy, Thanks again The method you described is pretty much how I implemented it. The problem lies on the TI505 side of the story. I have checked the data by putting a counter in the blocks that are sent to the TI505 by the S7. The value of this counter is present twice: on the first integer of the DB and on the last integer of the DB. By checking if the value of the two is equal, I can see if the complete DB has arrived in the TI505. I guess this will suffice? Greetings.
	It's life Jim, but not as we know it...
Suggestion To thank Quote Answer

1/26/2010 3:54 PM	Rate (0)
smiffy Platinum Expert Joined: 1/17/2007 Last visit: 12/5/2024 Posts: 1548 Rating: (538)	That should be OK. My only worry is that if there is any fragmentation of the packet (which can happen over Ethernet), the packet may be broken down in a several smaller packets that can arrive in any order. I am no expert in how the S7 CP firmware is functioning, but I assume that the DONE / NDR indications will only be given when the whole packet has been sent / received (i.e all fragments). Maybe someone on here can confirm this. Your method relies on the premise that the whole packet to be sent in one lump, or a least if fragmented, the fragments go in fixed order of first byte to last, or last byte to first. If for example, the packet is sent as 3 fragments (we will call these "beginning", "middle" and "end") and they are sent in a random order, with the "beginning" sent first, then the "end" sent second and the "middle" sent last. You will detect that the data packet has arrived before the "middle" packet has arrived. It is unlikely that the packet will be fragmented though as your data packets are very small. So maybe it is not a problem. The article below shows that fragmentation limits for different protocols. Ethernet Fragmentation Limits Hope this helps.
	Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. So far, the universe is winning...
Suggestion To thank Quote Answer

1/26/2010 9:10 PM	Rate (0)
V4Friend Advanced Member Joined: 11/30/2007 Last visit: 12/20/2024 Posts: 44 Rating: (1)	It does! Thanks...
	It's life Jim, but not as we know it...
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on