QUESTION:
Is there are risk of errors when setting up a diagnostics connection via the LAN if the MAC address has been changed beforehand?

ANSWER:
The following information holds for all Industrial Ethernet CPs whose MAC address (media access control) can be configured with STEP 7. This module supports the ISO transport protocol amongst others. Some new CPs do not support the ISO protocol and therefore it is not possible to configure an MAC address. These modules use the factory-set MAC address. The defective diagnostics connection described concerns the following CPs:

• 6GK7 343-1EX10-0XE0 (CP 343-1)
• 6GK7 343-1EX11-0XE0 (CP 343-1)
• 6GK7 443-1EX10-0XE0 (CP 443-1)
• 6GK7 443-1EX11-0XE0 (CP 443-1)

Initial situation:
The station and the CP 443-1 have been configured with the following address parameters:

• IP address: 140.90.36.1
• MAC address: 08.00.06.01.36.01

The station is in RUN. All the modules in the rack are working perfectly. Now the MAC of the CP is to be changed to 08.00.06.01.36.02. The IP address is retained. The loading procedure is to be done via the LAN interface (local area network) with the TCP/IP protocol.

Behavior when loading:
The loading procedure is interrupted temporarily. The dialog shown in Fig. 1 is displayed. The interruption happens just when the Industrial Ethernet CP restarts. This happens through receipt of the new configuration and can be recognized by a brief RUN-STOP-RUN sequence of the LEDs.
The brief STOP of the module is a standard procedure. Normally the programming device sets up a new PG channel connection with the IP address stored in the project. This remains the same, because only the MAC address has been changed. So the message box depicted below should not really appear.

Fig 1: Error box, indicating that the target system cannot be reached

Press the "Details" button to open the following dialog:

Fig. 2: Details of the error box (Fig. 1)

The messages indicate that the programming device could no longer set up a connection to the module just as the system data block SDB1003 was supposed to be sent to the CPU. An NCM diagnostics connection via TCP/IP is no also no longer possible with this PG.
If you now set up a diagnostics connection to the CP 443-1 via MPI (MPI address of the CPU and slot of the CP), then the following figure shows quite clearly that the CP has already adopted the configured change.

Fig. 3: NCM S7 diagnostics window  

Remedy:

• The whole configuration can be loaded via the MPI interface.
• The whole configuration can be loaded once again from another PG/PC via the LAN with the TCP/IP protocol.
• The whole configuration can be loaded once again from the same PG/PC via the LAN with the ISO protocol.
• After a delay of a few minutes – without accessing the interface used for loading – the loading procedure via TCP functions again with the same PG.

Recommendation:
Always load the configuration changes which include a change of MAC address via the MPI interface of the associated CPU module.

Technical explanation:
After starting the first loading procedure the PG first uses the ARP protocol provided (address resolution protocol) to determine the MAC address for the IP address 40.90.36.1 which is to be used for loading. The CP responds with an ARP response with its MAC address 08.00.06.01.36.01.

The configuration can now be loaded via the TCP/IP protocol. After restarting of the module however the CP has a different MAC address. The PG has internally stored an MAC address once determined as an IP address in the so-called ARP cache.
That is why when setting up a connection again with the PG, the ARP protocol must no longer be used. Nevertheless the PG is still using the old MAC address that no longer exists. The proof of this is provided by the following figure showing the ARP cache of the PG that has been read out after abortion of the loading process and subsequent failure of the diagnostics connection via TCP/IP.

Fig. 4: Display of the IP and MAC addresses

The old MAC address is stilled entered for the IP address. This entry is deleted automatically when the IP address is not used for a certain period of time by the interface. As a quick remedy here you can delete individual entries of the ARP cache also in the PG. Then the ARP protocol is used again when accessing the IP address and access via TCP/IP is possible.