S7 400 with CP synchronize program with UDP data packet

For an application I have the following setup:

- S7 400 PLC with CP card
- 1 PC with ethernet card sending data via UDP to the PLC

The PC sends data (500 bytes) every 10 milliseconds to the CP card.

I need to synchronize my data processing in the CPU with the data packets received. Having an OB which runs every 10 ms is not good enough, because than the data receiving and data processing is not synchronized, resulting in occasionaly loosing data packets or processing data packets twice.

Due to other program parts, I expect the OB1 cycle time to be significantly higher than 10 ms.

Is there a way to have my program synchronized with the received data? Would it be possible to let the CP card generate an interrupt, which triggers an OB when new data received?

Your help is very much appreciated.

What is it that needs to send data every 10 ms from a PC ?
As far as I know the minimum update time for normal programs on a PC is 10 ms. I think maybe services can have shorter update times.

Besides 500 bytes is not trivial. No matter the method used, I am not sure the PLC can handle that much consistently.

Anyway, I would suggest to use Profinet IRT. An update time of 10 ms is not impossible.
You probably need a dedicated Profinet hardware in the PC plus dedicated library to use the Profinet hardware. OPC will not do.
Siemens has the CP1616 card and also an API.
Hilscher has the CIFX 50E-RE card, and an API.
And there are others, look at www.profinet.com.
edit: I tried to find something on softing's website, but their main page ends blindly. Strange. Apart from that softing is quite well-renowned in the industry.

On the PLC side you simply setup the CPU as a PN IO Controller, or a PN I-device.
Then you have to use OB61 to handle the data in "isocronous mode".

Some ideas to try.
1. Make sure that you are using Speed send and Speed receive.
2. Make sure that the setting UDP buffering is not disabled. (Setting in the HW config for the CP card).
3. If application allows raise the % for scan cycle load from communication (Setting in the HW config for the CPU).
4. Call AG_SReceive more than once each cycle this should empty the buffer if there is more than one UDP frame buffered in the CP card.

UDP is an unreliable protocol if you want to protect against duplicate message you must handle this yourself on application level or switch to TCP or ISO-ON-TCP

Thanks for your replies!

@Jesper:
The PC is on customer side and is a setpoint generator for my closed loop controller. The closed loop itself is within my own system. The amount of data can be reduced to 32 bytes for this specific task. For other projects I also have used devices which send UDP packages every 10 ms. However, the PLC in that setup did no other tasks, and then OB1 just waits for a package and completes its data processing within a few milliseconds.

@Brett:
Thanks for that, these settings should help once I have found a setup for my program.

Would it be possible having a cyclic OB running on 1 ms, which on data receive triggers another OB, this way preventing timeouts on the cyclic OB? Just an idea..

Can you provide some more details on what you did on the other project where you managed to receive data syncronously every 10 ms ?

There is a tool on Siemens website to estimate transfer times with various devices, amount of data and protocol used. I used it to try to see if I could find some combination that could get transfer times below 10 ms.
For 240 bytes I got between 10 - 30 ms no matter what combination I used. Never below 10 ms.

edit: I think that the tool does not really cover Profinet IRT (isochronous realtime). I have a hunch that you can get update times that are much shorter than what the tool estimates. The tool only mentions "PN IO", not "PN IO IRT".

JesperMP said:

Can you provide some more details on what you did on the other project where you managed to receive data syncronously every 10 ms ?

There is a tool on Siemens website to estimate transfer times with various devices, amount of data and protocol used. I used it to try to see if I could find some combination that could get transfer times below 10 ms.
For 240 bytes I got between 10 - 30 ms no matter what combination I used. Never below 10 ms.

edit: I think that the tool does not really cover Profinet IRT (isochronous realtime). I have a hunch that you can get update times that are much shorter than what the tool estimates. The tool only mentions "PN IO", not "PN IO IRT".

Click to expand...

A CPU317 together with a CP343-Lean card receives UDP packages of 40 bytes every 10 ms on the CP. In OB1, FC_AG_RECV is called. When new data received (NDR) output indicates new data, data processing is started which finishes after, say 2ms. If no new data, jump to end of OB1. I am not sure whether this can be qualified as "syncronously", but the results are satisfying.

The way you have done it already is probably OK.
The difference with Profinet IRT is that it gives you a guaranteed performance, even if there is other traffic on the ethernet LAN.
Also, in your example with the 317+CP343-1LEAN, the data passes over the MPI backplane. If there is any other MPI data transfer it will affect the data transfer via UDP to the CPU. Why not via an integrated PN port on a 317-2PN/DP ?

As Bratt pointed out in a previous post, UDP isn't a reliable protocol because delivery isn't guaranteed.

If the data refresh really needs to be 10mS then UDP wouldn't seem appropriate.

If the 10mS update isn't critical then can it be slowed down?

Just a thought.

Nick

He should program a telegram counter, to be included in the transferred data. By checking if the counter skips numbers, he knows if there are lost telegrams.

@Jesper:
As far as I know, an integrated PN-port cannot be configured for UDP connections.

UDP is not as reliable as TCP, however communication is faster. And indeed, a telegram counter is used to check for lost or duplicate messages.

Check this out:
How do you program the communication blocks FB67 "TUSEND", FB68 "TURCV", FB65 "TCON" and FB66 "TDISCON" in order to use the UDP protocol for data exchange by means of the integrated PROFINET interface of a CPU?

So it is possible to receive UDP packages on the integrated PN-port, indeed. However, I am not sure that the customer can implement this CP1616 card. When he does have this card, then I would be able to have OB61 triggered on each data block received?

The SEND-RECEIVE via UPD on the integrated PN port does not depend on who is sending. If you have managed to send UDP packets via SEND-RECEIVE before, you should be able to do it again using the same method.

The OB61 I mentioned has to do with PROFINET IRT, not SEND-RECIVE via UDP.
If you want to switch to PROFINET IRT, you have to use a dedicated card (such as the CP1616) and probably an API for that card.