S7300 <-> S7400 con via CP's. S7 connection not compatible ?

[userxyz]

S7300 <-> S7400 con via CP's.

Local partner does not support S7 connections, that"s the message I get when I try to add an S7 connection on a 6ES7 316-2AG00-0AB0 v1.1 CPU.

So now I builded the communication on an other way: 'ISO on TCP':
https://support.industry.siemens.com/cs/document/47885440?lc=en-US

PUT and GET were replaced by AG_Lsend in the 400 CPU and AG_Recv in the 300 CPU. This works, but I do get errors on the LSend function... it sends several times without error and every... let's say 5 sends ... an error occurs. The data is transferred, so the sending from 400 to 300 CPU works, I'm just wondering why it gives errors on the LSend function.

Questions:
- Why is an S7 connection not supported in the 316 CPU ?
- The LSend errors, what could be the cause ?

Thanks,
Combo

 

[Thomas_v2]

It depends on the CP. If you've got two CPs which only supports S7-Communication as server (CP 343-1 Lean for example), then a S7 connection between these is not possible, as one of them has to be client.

How fast are you calling the AG_LSend, and the AG_Recv? Maybe the send block is called faster than the partner reads out the buffer with AG_Recv, and then the buffer inside the CP runs full.
I usually call the AG_Recv as fast as possible, and the send block using combined the status outputs of the blocks with and a time trigger (2s, 5s, ...).

 

[userxyz]

Call

Hi,

Thanks for your reply.
It's triggered with a clockbit at 100ms.
Should I try 2s ?
And use the status as well combined like you say ?

2s = seems like a very slow communication...

Regards,
Combo

 

[Thomas_v2]

Checking the Done / Error flags before triggering a new send, is always a good ides. But I think the Done flag is set when the CP has overtaken the job from the CPU, and not when the partner has acknowledged the data.

I would try to go down with the trigger cycle, and see if this the communication gets more stable.

The best way would be, to send a cycle counter to the partner, and the partner sends this value back. If you detect the same value, then you can be sure the partner has successfully read in the complete data, and trigger a new SEND call.

 

[userxyz]

..

I checked a little closer and...

I have statusvalue 7000hex when the error occurs, 8181 when job busy.

From the help:
7000H The condition code is possible only with S7-400: The FC was called with ACT=0; the job has not yet been processed.

So I connected a permanent ONE/TRUE to the ACT input parameter. And now it sends data on the highest speed possible (CPU cycle time).

I don't get this, I tought the function worked on edges, but it seemd to be working with a constant true... ?

Any seggestions or corrections ?

I don't have any errors anymore.