What Is PROFINET Fast Startup (FSU)?

Back to Blog

What FSU Removes From a Normal Startup

A normal Ethernet port powers up and negotiates speed and duplex with its link partner, a handshake that costs time, and a normal PROFINET device then works through its full initialization before it is ready to exchange data. Fast Startup targets exactly those delays. The port speed and duplex are configured to fixed values so auto-negotiation is skipped, and the device streamlines its initialization so it reaches the ready-to-exchange state far sooner after power is applied.

Because FSU fixes the port settings, both ends of the link must agree on speed and duplex - you cannot rely on auto-negotiation to sort it out. That is a design constraint: the switch or partner port feeding an FSU device must be set to the matching fixed configuration, or you get the classic duplex mismatch. This is the same fixed-port discipline discussed for any industrial Ethernet switch carrying deterministic traffic.

Where Fast Startup Belongs and What It Costs

The signature application is a robot tool changer, where the robot docks a tool that carries a PROFINET device, powers it up, uses it, then drops it and picks up another. Without FSU, each tool change would wait on a full device boot; with FSU the tool rejoins the network fast enough to keep cycle time low. Any station that is deliberately powered down between operations and must come back quickly is a candidate.

The trade is flexibility and a little robustness margin: fixed port settings mean the link is less forgiving of a mismatched partner, and the feature has to be supported and enabled on the device and configured consistently in the engineering tool. FSU is not something you turn on network-wide for its own sake; you apply it to the specific devices whose repeated power cycles would otherwise cost you production. Everywhere else, ordinary startup is fine.

Configuring FSU: GSDML, DCP, and Fixed Port Settings

Fast Startup is not a network-wide mode; it is enabled device by device, and the configuration has several pieces that all have to line up. The device's GSD and GSDML file declares whether FSU is supported at all and on which ports. In the engineering tool you activate the feature on the device, fix the port to a set speed and duplex, and disable auto-negotiation - and because automatic crossover detection is part of the negotiation the device skips, the crossover function of the port is usually fixed as well, which means the cabling between switch and device must be correct by construction rather than corrected automatically.

Address assignment matters just as much. A normal device may wait after boot to be assigned its device name and IP address over the Discovery and Configuration Protocol (DCP), and any waiting defeats the purpose of FSU. A Fast Startup device therefore stores its name and address configuration retentively so it can come up without asking the network for anything first. If a tool or a replacement device arrives blank, it will still join the network eventually - it just will not join fast until the stored configuration is in place.

Commissioning Checklist for a Fast Startup Station

Because FSU trades away the self-correcting behavior of auto-negotiation, commissioning is mostly about proving that every fixed assumption is actually true on the installed hardware. A sequence that works well in practice:

1. Confirm in the GSDML and the device manual that FSU is supported on the specific port you are using, not just somewhere on the device family.
2. Set the switch or controller port feeding the device to the same fixed speed and duplex, with auto-negotiation disabled on both ends.
3. Verify the cabling and crossover arrangement against the fixed port configuration, since the port will no longer adapt to a swapped pair.
4. Store the device name and IP configuration in the device so no assignment step runs at power-on.
5. Power-cycle the station and measure the time from power applied to cyclic data exchange, then compare it against the machine's cycle budget.
6. Repeat the measurement over many docking or power cycles, because a startup that is fast once and slow occasionally still stalls production.

When Fast Startup Is Not Fast: Diagnosing the Delay

The classic failure is a partner port that quietly went back to auto-negotiation - after a switch replacement, a firmware update, or a configuration restore - which either reintroduces the negotiation delay or produces a duplex mismatch that shows up as CRC errors and dropped cyclic frames under load. The second classic is lost address configuration: a swapped tool or a replacement device that boots blank and waits to be assigned an identity. If tool changes stall intermittently, look also at the physical interface, because docking contacts wear, and a link that bounces during mating forces the startup to begin again. A device that has forgotten who it is behaves much like the naming problem described in fixing a PROFINET device name mismatch.

Diagnose with a stopwatch mentality: measure power-on to link-up, then link-up to data exchange, and compare each interval against a known-good station. A slow link points at port settings or contacts; slow data exchange after a fast link points at address assignment or controller-side configuration. And if a correctly configured FSU device still cannot meet the cycle budget, the honest answer is usually mechanical or architectural - keep the device powered through the change, or move the function off the tool - rather than hunting for a faster boot the hardware cannot deliver.

Frequently Asked Questions