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

Actually I did

Actually I did.
The result is the same.

It was like that in the beginning. Then I had the issue. And I was searching in manuals what could be wrong. Then I found that I should not call it in OB1 in that manual I showed. So I putted in OB34. This works as well and the blocks never give an error, so both methods work. And both methods do not overload the communication with the CP if you delay it with 200ms. WHen calling in the interrupt you don't need to work with BUSY, just permanent 1 on ACT and call it every 200ms works perfectly as the function does not need 200ms to have sended that data.

But, like I said before, the way it is programmed is not what causes the issues. The weird thing is that the Send to the 300 CP does not fail, never. The 400 CP's all fail by a certain cause, and I think the cause is a main cut off of the power, because since the cutoff the UDP connections didn't fail anymore. At some point something happens during a send (closet cutoff) and the receivers then refuse to receive data after a power on. After that we need to do a power off of the PSU again to reset something ... I don't know and I'm still not 100% certain about how it happens at this point.

I'm wondering, would a S7 connection be more reliable... ?

Kind regards,
Ghan

JesperMP said:

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.

Click to expand...

As others noted, it is odd that "connection-less" UDP comms fail when the network is up.


Maybe there is something hanging around in the instruction from the previous comms, like a stale f@rt. If so, I wonder if connecting to a different, non-existent hostort, and failing, and then going back to the correct hostort would clear the air. If it does work, having two addresses, and having a failure trigger a toggling of which is used, would be one way to implement the correction.

Noticed

One thing I've noticed, I have another cpu in my network that uses 6GK7443-1EX30-0XE0 for the udp connections. Never had problems with this one, silar set-up. On my cpu I have 2 CPs a 6GK7443-1EX30-0XE0 for my profinet devices and a 6GK7443-1EX20-0XE0 for ly udp connections. So Im thinking, maybe I should replace the CP with its succesor 6GK7443-1EX30-0XE0...

drbitboy said:

As others noted, it is odd that "connection-less" UDP comms fail when the network is up.


Maybe there is something hanging around in the instruction from the previous comms, like a stale f@rt. If so, I wonder if connecting to a different, non-existent hostort, and failing, and then going back to the correct hostort would clear the air. If it does work, having two addresses, and having a failure trigger a toggling of which is used, would be one way to implement the correction.

Click to expand...

I found something OMG

In my hardware config I have...
A CP 443-1EX20-0XE0
And a CP 443-1EX30-0XE0.

But this is wrong... it are botj 1EX30 cards...
So I guess things go wrong by this mismatch. The hardware config did not complain wich is weird... but I tjink this will be the cause of this odd issues.

Siemens

Siemens called me today.
They are not sure that a mismatch will be the cause of UDP connections that fail... hmmm...

However I will download the corrected hardware config and wait until this happens again. If that is the case I will search for more details.

Thanks,
Kind regards,
Ghan

GHan said:

In my hardware config I have...
A CP 443-1EX20-0XE0
And a CP 443-1EX30-0XE0.

But this is wrong... it are botj 1EX30 cards...
So I guess things go wrong by this mismatch. The hardware config did not complain wich is weird... but I tjink this will be the cause of this odd issues.

Click to expand...

Downloaded

Hi,

I have downloaded the corrected hardware configuration. UDP connections are online and everything works. Fingers crossed on the next power-shutdown