LADX
Start free
← Resources
Networking·7 min read·

Diagnosing a PROFINET network that mostly works

Device names, update times, the difference between a lost frame and a lost device, and the tooling that finds intermittent faults.

Short answer

Start with the device name, not the IP address: PROFINET assigns addresses by name at start-up, so a name mismatch prevents connection entirely. For intermittent faults, look at discard counters on the switch ports and at the update time configured against the device's minimum. Most persistent PROFINET problems are cabling and topology rather than configuration, and a wire test plus a topology review finds them faster than a protocol analyser.

Which protocol sits whereENTERPRISEOPC UAMQTTCONTROLEtherNet/IPPROFINETModbus TCPDEVICEIO-LinkPROFIBUS DPModbus RTUEthernet carries most of it now, which is why the layers blur.

A PROFINET network that has never worked and one that works most of the time are different problems, and the second is much more common and much harder.

The device name comes first

PROFINET does not identify a device by its IP address. It identifies it by name, and assigns the address at start-up over DCP.

So a device that has been replaced, factory reset, or previously used on another machine will have the wrong name, and the controller will look for a name that is not present and find nothing. The device sits there with a link light, apparently healthy, not connected.

Before any protocol analysis, browse for devices, list the names on the wire, and compare them with the names in the project. This single check resolves the majority of connection failures.

Update time, and what it costs

The update time is how often the controller and device exchange their cyclic data. Every device has a minimum it supports.

The temptation is to set everything fast. It costs bandwidth and controller load, and it gains nothing on a device whose data changes every few seconds.

  • Motion and fast interlocks: 1 to 4 milliseconds.
  • Ordinary distributed I/O: 8 to 16 milliseconds.
  • Anything reading a temperature: as slow as the device allows.

The watchdog is derived from the update time, usually three missed cycles. Setting a very fast update makes the watchdog very short, which means a network that is fine at sixteen milliseconds starts dropping devices at one.

Lost frame is not lost device

A distinction worth holding onto while diagnosing.

A missed frame is normal and expected occasionally; the watchdog exists to tolerate it. A device drop means enough consecutive frames were missed to exceed the watchdog.

If devices drop, the question is whether frames are being lost steadily, in which case it is physical, or in bursts, in which case something is flooding the network.

Read the switch counters

The most useful and least used tool. A managed switch counts, per port, the frames it discarded, the CRC errors it saw, and the collisions.

A port with a rising discard count identifies the segment without any analysis of the protocol. A port with CRC errors identifies a cable.

Read them, note the values, wait an hour under production conditions, read them again. Intermittent faults show up as a rate, and they will not show up if you only look once.

Topology matters more than people expect

PROFINET IRT and fast update times care about the physical topology, not just the logical connectivity.

  • Line topology is common on machines and means one failed device or cable takes out everything downstream of it.
  • Ring topology with media redundancy survives a single break, and needs a redundancy manager configured. A ring wired without one is a broadcast storm waiting to happen.
  • Unmanaged switches in a PROFINET network are a persistent source of trouble. They do not report, do not prioritise, and do not participate in LLDP so the topology view has a hole in it.

The physical layer

Last on the list of things people check and first among causes.

  • Cable rated for the environment and the flexing. A fixed installation cable in a drag chain will fail, on a schedule.
  • Connectors terminated properly. A wire tester that verifies pairs, length and attenuation, not just continuity.
  • Separation from motor cable. Covered at length elsewhere and it applies here as much as anywhere.

Common questions

Why does my PROFINET device not connect?
Nine times in ten the device name does not match the name in the configuration. PROFINET identifies devices by name and assigns the IP address at start-up, so a device that has been swapped, factory reset or configured elsewhere will not be found however correct its IP looks.
What update time should I set?
The slowest that meets the requirement. Every device has a minimum it supports, and setting a fast update time across a large network consumes bandwidth and CPU for no benefit. Motion axes need one to four milliseconds; a remote I/O rack reading valve positions is fine at eight or sixteen.
How do I find an intermittent PROFINET fault?
Read the discard and error counters on the managed switch ports over a period rather than watching for an event. A port quietly discarding frames identifies the segment immediately. If the counters are clean and faults persist, check the topology for a ring or a marginal cable run.

Keep reading