First thread :-): Issue with CP communication (Siemens)

Hi all,

I have an issue and I don't know how to proceed with it.
So my problem is...

I have several UDP connections.
And all communication with AG_SEND and AG_RECV is handled in OB34 (200ms). At first, everything works. But I have the empression that after a power break of the complete closet that my connections get lost... I'm not sure that that's the cause... one connection remains without problems. When I do a power-off, power-on on the PSU on the rack, all connections are back okay...
Maybe in the weekend the switch where all connections are connected to is off... I don't readlly know what the cause is. I don't understand why it does not re-establish good connections without a power shutdown on the rack.
The weird thing is, receive data works, only send fails...
But send from other CPU's is no issue... weird...

Any ideas and help with this issue ?





Thanks in advance,

Kind regards,
Ghan

I found some more information

Sender CP:



Receiver CP:

Hi an welcome to the forum !

GHan said:

And all communication with AG_SEND and AG_RECV is handled in OB34 (200ms).

Click to expand...

Why OB34 ?
As far as I know AG_SEND and AG_RECV must run continously, at least as long until the data is fully sent.
Not sure what the consequence is of "chopping" the update like that.

Just try to run all you AG_SEND/AG_RECV code in OB1 and see if it fixes it.

UDP Buffering

Hi JesperMP,

Reason for not putting it in OB1:


https://adegis.com/media/asset/05bd5747899d32578da1d4ec16147c930efb1a81d7a2d33af6b080bc640eabeb.pdf


I did find something odd on the CP settings:

This was set Enabled, so I check-marked this to disable it...
Thge other CP's in the network do not have this feature as they are older CP's... so maybe this buffering is not a good thing... ?

Kind regards and thank you for your reply,
GHan

JesperMP said:

Hi an welcome to the forum !
Why OB34 ?
As far as I know AG_SEND and AG_RECV must run continously, at least as long until the data is fully sent.
Not sure what the consequence is of "chopping" the update like that.

Just try to run all you AG_SEND/AG_RECV code in OB1 and see if it fixes it.

Click to expand...

I would also move the AG_send and AG_recv to OB1. They run asynchronously meaning they may take several program cycles before actually finishing the transmission. I don't know how they behave in cyclic OB.

I cannot see the pictures you uploaded, so you may answer my next question already there, but are you sure sending is initiated correctly after start up? It has happened to me couple of times, that everything runs smoothly during normal operation, but I have left some stupid condition in the program, that the communication does not start properly after power cycle.

EDIT: After managing to load the pictures I see your reasoning for having them in cyclic OB. Interesting chapter. I had to do some data exchange with AG_SEND and AG_RECV not too long time ago, the only mention I could find was that the send and receive FBs should be in OB1. I stand corrected.

I think that 200 ms between updates of AG_SEND and AG_RECV is very long.
I suspect the advice is relevant when the CPU cycle time is very short, i.e. 1-2 ms. Then maybe calling the AG_SEND/AG_RECV blocks every 20 ms could be reasonable.

I dont understand the argument in the Siemens manual that constant calls to AG_SEND/AG_RECV can cause overflow of the comms between CPU and CP. If this is true, then I am disappointed that the AG_SEND/AG_RECV blocks do not handle this internally.

The other advise about minimum cycle time and "cyclic load due to communication" are known remedies that sometimes helps.

Is it possible that after power cycle other partners become available slower than the PLC you are working on? Do you try to re-establish the connection, if it fails the first time? Or maybe you should add delay before trying the establish the connection for the first time.

I'm curious how Siemens wants to detect a connection status on UDP, as UDP has no connection, so there is no connection that could be lost. In UDP you can send a datagram to an IP address which does not listen on any UDP port, it wouldn't make any difference and there is no way to detect this on UDP layer.

Better

Hello,

Well... to make things better, would a S7 connection be more stable than UDP ?
I have used UDP connections before without issues... so I don't really understand the problem that I experience right now.

An S7 connection has an active side... maybe that kind of connection is re-established without issues... ?

The UDP connections work 100% well at the moment. But, it happens when they shut off the electrical main switch of the electrical cabinet. So... I'm concerned about the current UDP connections...

One thing I setted, is the disable buffering, I hope that solves something...

I did found this manual:
https://support.industry.siemens.com/cs/document/47885893/how-do-you-configure-a-udp-connection-for-data-exchange-between-s7-300-and-or-s7-400-by-way-of-industrial-ethernet-cps-?dti=0&lc=en-CN

They mention to use AG_LSEND and AG_LRECV... I have used the AG_SEND and AG_RECV blocks... could that coause something ?

Kind regards,
Ghan

Another thing

One other thing,
I setted the ports identical in each connection, I hope that is not a prob:

Ag_send ag_recv

No the functions are okay:

Have you looked at this?

https://support.industry.siemens.co...e-lengths-via-the-tcp-protocol?dti=0&lc=en-WW

I find it interesting as this guidance instruction goes against what you are doing and the manual pages you pasted. Additionally, I believe there are more instructions from Siemens where they create a sequencer to send out communications in order to never go above the capabilities of the processor.

If it eases your mind, there is a silly amount of drilling rigs out in the Ocean with their drilling PLCs talking UDP to each other. Some at rates faster than 200ms too.

If I am not mistaken, in that sample project the AG_SEND block is called cyclically.
Each sending is started with a rising edge on the ACT input.
The calling block must not create the rising edge as long as BUSY is still on.
So in that way there will be no 'overflowing' of the CP.
It is very simple actually.
Important though is that AG_SEND is called cyclically, not by a timed interrupt.
If one wants to decrease the comms load, one can then delay the start of the next sending by not creating the rising edge immediately when BUSY is low. For example by the 200 ms, but it must be by a timer that delays the rising edge of ACT, not by suspending the call of AG_SEND.

So I am waiting for GHAN to try that out.

Hi

Hi,

Thanks for your reply.

I have 4 UDP connections. 3 with 441 CP's and 1 with a 341 CP of other stations. WHen the problem occurs is still not clear, but we think that is occured when the technicians did a main power cutoff. We can also see this on a switch its info. However after power on the 3 connections with 441 CP's try to send but cannot send anymore. Receive still works. WHen I check the other CP diagnostics I can see that they refuse the sends from my PLC. And if it isn't weird enough, the connection from my 441 CP to the 341 CP does not fail, this one works all the time without issues. When all this happens, I change the swith on the PSU to zero and to one and everything works again... this is kinda weird. The other stations never went down. There is a switch in this network that also shuts off when they do a main cutoff, maybe that's something.... ?

UDP should be the simplest connection, so I don't know if I should move to an S7 connection or TCP connection at this moment... UDP should work as well ??

Hietsu said:

Is it possible that after power cycle other partners become available slower than the PLC you are working on? Do you try to re-establish the connection, if it fails the first time? Or maybe you should add delay before trying the establish the connection for the first time.

Click to expand...

Hmm

Hi,

Thanks for your reply.
Yes I did.

But if you send every 200ms, then such a mechanism is not needed, because you do not get errors. If you do it in OB1 (wich is not advised by Siemens) then you lust wait for the done bit. ANd you lust send a rising edge to the ACT and notlonger or you get error 7000.
Anyway, the way it is programmed is not the cause imo.
If I look in netpro at the moment it fails, then I can see that the UDP connections are closed and established and closed and established and so on... so I see errors everytime I refresh. And in NCM I can see that every send is blocked by the partners. After PSU off/on every connection works fine again...

Kind regards,
Ghan

cardosocea said:

Have you looked at this?

https://support.industry.siemens.co...e-lengths-via-the-tcp-protocol?dti=0&lc=en-WW

I find it interesting as this guidance instruction goes against what you are doing and the manual pages you pasted. Additionally, I believe there are more instructions from Siemens where they create a sequencer to send out communications in order to never go above the capabilities of the processor.

If it eases your mind, there is a silly amount of drilling rigs out in the Ocean with their drilling PLCs talking UDP to each other. Some at rates faster than 200ms too.

Click to expand...