show the entry list
Industrial Ethernet S7-300/400 CPs -- Configuring and programming communication -- Configuring connections
How do you check a TCP or UDP connection if there is no communication partner?
How do you configure a connection with the multiple port 502 for the Modbus/TCP function block MB_REDSV?
What should you watch out for when configuring fault-tolerant S7 connections over ISO-on-TCP?
How do you configure an ISO transport connection for data exchange between S7-300 and/or S7-400 by way of Industrial Ethernet CPs?
How do you configure a UDP connection for data exchange between S7-300 and/or S7-400 by way of Industrial Ethernet CPs?
How do you configure an ISO-on-TCP connection for data exchange between S7-300 and/or S7-400 by way of Industrial Ethernet CPs?
Where can you find sample S7 programs and documentation for communication via PROFINET on the SIMATIC NET Quick Start Collection?
How do you send/receive data to/from multiple communication partners via the IE CP of an S7-300 or S7-400 station using the UDP protocol?
How do you configure a PC station as PROFINET IO controller for connecting to a S7 station (as PROFINET IO device) for the SIMATIC NET OPC server with the SIMATIC NET PC software?
How do you configure S5-compatible communication to the SIMATIC S7 via Industrial Ethernet for the SIMATIC NET OPC server with the SIMATIC NET PC software?
How do you configure an S7 connection for data communication between an S7-200 and an S7-300 or S7-400 on the Industrial Ethernet?
Establishing a connection from a PC to the S7-400 
What differences are there when configuring S7 connections?
What restrictions are there with Industrial Ethernet CPs when the communications service ISO-on-TCP is being used in parallel via the open TCP/IP communication and the SEND/RECEIVE interface?
What do you have to watch out for, in particular, in the assigning of TSAPs in ISO transport connections and ISO-on-TCP connections?
Procedure and meaning of multicast connections with Industrial Ethernet CPs
How do I set up an ISO connection between a SIMATIC S7 (CP343-1) and a SIMATIC 505 (CP1434) via INDUSTRIAL ETHERNET?
How do you configure the WRITE and FETCH services via Industrial Ethernet (ISO transport connection, ISO-on-TCP connection) for the S7-300/400 with Industrial Ethernet CP343-1 or CP443-1?
Commissioning and Configuring an ISO Transport Connection between the SIMATIC S5 and SIMATIC S7 via Industrial Ethernet
How do you configure a specified and an unspecified S7 connection for data exchange between S7-300 and/or S7-400 by way of Industrial Ethernet CPs?
Configuring a TCP connection via Ethernet (TCP native) between a SIMATIC S7 and a PC with Socket Interface
How do you configure a TCP connection for data exchange between S7-300 and/or S7-400 by way of Industrial Ethernet CPs?
Procedure and meaning of multicast connections with Industrial Ethernet CPs
Part number:

QUESTION:
What should you watch out for when using multicast connections and how are they configured?

ANSWER:
Multicast is a special connection option that with Industrial Ethernet CPs is only supported or can only be configured with UDP connections (UDP = User Datagram Protocol). There is often the wish to send a message from one station to multiple partner stations. The important thing here is that the messages are sent simultaneously and are received almost simultaneously by the partner stations. Sending and receiving of broadcast messages is therefore always demanded. In the case of a broadcast message, the message is really received by all the stations on the network. Broadcast messages are also needed, for example, for finding an MAC address to an IP address (ARP request). Therefore a communications module must always accept broadcast telegrams and evaluate them with an appropriate software. If there are too many broadcast messages in the network, the network performance drops. This is because the individual modules have to process all the broadcast telegrams to ascertain whether or not they are meant for them.

The following 2 points are to be noted for Industrial Ethernet CPs with regard to broadcast:

  • In all Industrial Ethernet CPs the broadcast messages are filtered out as high priority upon receipt. All messages that are not messages that can be used (e.g. ARP Request) are discarded immediately. This prevents the negative influence of broadcast messages on the other connections.
  • Modules that cannot receive any broadcast messages, can however be used to send broadcast messages into the network.

To ensure a synchronous sending of a message to multiple station, the connection option "Multicast" has been introduced. By means of a definition (via configuration as of SIMATIC STEP7/ NCM V5.1 + SP2), reserved Multicast partners are enabled to send a message directed to a certain number of communication partners.

Behavior of the communications processor:

The communications processor is usually also locked for multicast messages. One exception is the time. If a multicast group is now activated in the configuration, it is also activated in the LAN controller. Only this one particular group is activated and the communications processor continues to be impervious to broadcast messages from the network. Each multicast group configured must be noted in the LAN controller.
This is why multicast is always the better solution when messages are to be sent to groups of partner stations.

  • You can configure up to 48 multicast groups in one communications processor.
  • The data length is limited to 2048 bytes as for UDP.
  • The communications processor continues to be impervious to broadcast loads.
  • Requirement is of course that all partner stations also support multicast.
  • The messages are sent without any security mechanism (acknowledgment).

The messages are sent without acknowledgment, because there is no provision for acknowledgments in the UDP protocol. An acknowledgment could cause problems if, for example, a message is sent to 100 partners, then 100 acknowledgments (one per partner) would arrive at the same time. Such a surge of data could not be evaluated by the sender module.

Configuring multicast connections:

  1. Creating a connection in NETPRO:
    As usual the multicast connection can be created using the standard dialog. A UDP connection is selected as Connection Type and "All multicast stations" as Connection Partner (see figure below):

Figure 1: Integration of a new connection

  1. Filling in the "Addresses" dialog:
    In this dialog, the multicast range is chosen whereby the IP addresses 224.0.1.0 through 239.255.255.255 are reserved for multicast circuits. This address range is recognized by every block as a multicast frame and is not used for communication via standard communication connections.
    The local and remote ports can be assigned unlimitedly, as small port numbers are reserved for special tasks (well known ports). When the first multicast circuit is created, as a default the circuit 224.0.1.0 is offered.

Fig. 2: Properties of the UDP connection

  1. What a connection created in NETPRO should look like:
    In NETPRO, a connection is displayed with the common procedure. It can be distinguished from a common transport connection by the field "Partner". If it is a multicast connection, "All Multicast Nodes" is entered.

  IE-CPs_Multicast_03_e.gif ( 17 KB )  

Recommendations for project development:

To ensure smooth communication, the following develompent instructions must be observed:

  • Local and remote port of a multicast connection must be identical.
    The multicast circuits that are configured are registered in the LAN controller. This way, the incoming telegrams are not ignored, but processed by the CP.
    As soon as the telegrams have passed the LAN controller, the only relevant information left is the number of the port in use!

    Example: 
    Between two stations, exactly one multicast connection is configured.


      Station: 1 Station: 2
    IP address 140.90.36.1 140.90.37.1
    MC circuit 224.0.1.0 224.0.1.0
    local port 2000 8000
    remote port 8000 8000

    Case 1: Station 1 sends data from the multicast circuit 224.0.1.0.
    This works, as the remote port 8000 of station 1 corresponds to the local port 8000 of Station 2

    Case 2: Station 2 sends data to the multicast circuit 224.0.1.0.
    The telegram cannot be received by Station 1, although it is a node in the multicast circuit, because the local port 2000 of Station 2 is not identical to the remote port 8000 of Station 1.

    To manage both cases, remote and local ports must always be identical.

     

  • Special issue about the choice of multicast addresses
    In this example, a multicast telegram is to be sent from Station 1 to Station 2 as well.


      Station: 1 Station: 2 Station: 3
    IP-address 140.90.36.1 140.90.37.1 140.90.38.1
    MC circuit 224.0.1.0 224.0.1.0 225.0.1.0
    local port 8000 8000 8000
    remote port 8000 8000 8000

    As all port numbers are identical in this case, a bidirectional data transfer between these two stations is possible without restrictions.
    But, interesting enough, this telegram is also received by Station 3. At first sight, this is not supposed to work, as Station 3 is no node in circuit 224.0.1.0.
    To understand this, you have to look at the mechanism of building the multicast MAC addresses:

    Display of the multicast addresses on the LAN:

    For multicast, the last 3 bytes of the IP address are copied to the last 3 bytes of the MAC address 01.00.5E.00.00.00. This is the MAC address which is registered for the various circuits in the LAN controllers. This way you ensure that the telegrams can pass the respective LAN controller. Additionally, the highest bit of the first copied byte of the address is ignored and is always 0.
    The MAC address that has been created is also visible as destination address in the telegrams in the LAN.

    Result:
    The following three multicast circuits all lead to the same entry in the LAN controller, resp. to the same MAC address:
    224.0.1.0
    225.0.1.0
    226.128.1.0
    MAC address = 01.00.5E.00.01.00

    This shows that different multicast IP addresses actually represent the same multicast circuit. You should observe this when assigning multicast circuits to avoid unwanted messages on unaddressed stations.
    This is an instruction that follows valid RFC (internet standard).

Blocks that support multicast connections:


No.

First delivery

Block

Type of block

Firmware version

1 Dec. 2002 6GK7 343-1EX10-0XE0 CP 343-1 starting from Version V2.1

2

Apr. 2002

6GK7 343-1EX11-0XE0

CP 343-1

starting from Version V2.0.x

3

Dec. 2002

6GK7 343-1EX20-0XE0

CP 343-1

starting from Version V1.0

4

Aug. 2001

6GK7 443-1EX10-0XE0

CP 443-1

starting from Version V2.0.31

5

Aug. 2001

6GK7 443-1EX11-0XE0

CP 443-1

starting from Version V2.0.31

6

May 2004

6GK7 443-1EX40-0XE0

CP 443-1 Advanced

starting from Version V1.0

7

Dec. 2001

6GK7 343-1GX00-0XE0

CP 343-1 IT

starting from Version V2.0.x

8

March 2002

6GK7 343-1GX11-0XE0

CP 343-1 IT

starting from Version V2.0.x

9

Feb. 2004

6GK7 343-1GX20-0XE0

CP 343-1 IT

starting from Version V1.0

10

Dec. 2001

6GK7 443-1GX10-0XE0

CP 443-1 IT

starting from Version V2.0.x

11

Dec. 2001

6GK7 443-1GX11-0XE0

CP 443-1 IT

starting from Version V2.0.x

12

Nov. 2001

6GK7 343-1HX00-0XE0

CP 343-1 PN

starting from Version V1.0.x

Table 1: Blocks overview

Keywords:
network protocol, Gateway, TCP/IP, Frame

 

 Entry ID:9822272   Date:2004-10-29 
I regard this article....as helpfulas not helpful                                 
mySupport
My Documentation Manager 
Newsletter 
CAx-Download-Manager 
Support Request
To this entry
Print
Create PDF 
Send to a friend
QuickLinks
Compatibility tool 
Help
Online Help
Guided Tour