Both arrangements work. One port carries IDE downloads and PROFINET cyclic frames on the same segment; two ports separate them, which keeps downloads from disturbing cyclic data. The steps below cover interface binding, the DCP scan, station naming and the watchdog, ending in stable cyclic data.
Both work. One Ethernet port can carry the engineering link and PROFINET IO on the same wire, and plenty of installed systems run that way. Two ports, the onboard port plus a USB-to-Ethernet adapter, are the better arrangement: the IDE talks to the runtime on one segment, and cyclic PROFINET frames keep the other segment to themselves. This page gives that decision first, then the steps that take a bus coupler from a dark cable to stable cyclic data. Each check stops at the first hop that fails, so you fix one thing at a time.
One port or two
Three kinds of traffic sit between the engineering PC, the runtime host and the coupler:
| Traffic | What it does | Layer | Needs an IP route |
|---|---|---|---|
| IDE to runtime | download, online change, debug | TCP/IP | yes, one reachable subnet |
| PROFINET DCP | discovery, station name and IP assignment | layer 2 multicast | no |
| PROFINET RT | cyclic input and output data | layer 2, on a schedule | no |
On one port, all three ride the same switch. On two ports, the USB adapter carries DCP and RT to the coupler, direct or through a plain small switch, and the onboard port carries the IDE. Pick two ports when the engineering PC and the coupler cannot share a switch, or when a download disturbs cyclic data.
One documented limit shapes the two-port design: with standard Ethernet adapter hardware, each interface works as a single port, so two interfaces form two separate segments with no forwarding between them. The controller add-on's own documentation states this directly. The engineering PC cannot reach the coupler through the runtime host, and that isolation is the point of the second port. Splitting the engineering channel from the field channel is also the first decision in PLC parameter lookup over Ethernet.
What you need
- The runtime host, with the PROFINET controller add-on licensed and installed on it.
- The coupler's GSDML file, taken from the coupler manufacturer.
- A USB-to-Ethernet adapter for the two-port arrangement.
- Two straight Ethernet cables, and a plain switch only if a segment needs one.
- The engineering PC with the IDE, on the same subnet as the onboard port.
Bring the coupler online
- Link up on every hop. Watch the link LEDs at the adapter, at any switch and at the coupler. On the host, run
ip linkand read the state of the interface cabled to the coupler; it must show UP. An adapter missing from that list is an OS problem: fix the driver or the enumeration first. Nothing above layer 1 works until the link is up. - Bind the controller to the right interface. The PROFINET controller in the project has its own network interface selection, and the runtime opens that interface at layer 2 for DCP and RT frames. If the selection points at the onboard port while the coupler hangs on the adapter, the runtime transmits into the wrong segment and the coupler looks dead. USB adapters usually enumerate under a name different from the onboard port, so confirm which name is which before you select.
- Set a static address on the PROFINET interface. For example 192.168.10.1/24 on the adapter. Do not run DHCP on that interface; the coupler receives its address from the controller later in the sequence.
- Run the device scan. The scan sends a DCP multicast, which only crosses hops that forward layer 2 multicast:
| Scan result | What it means | Next step |
|---|---|---|
| Coupler listed with name and MAC | binding and path are correct | step 5 |
| Listed with an empty or default name | reachable but unnamed | step 5, assign the name |
| Nothing listed | wrong interface, filtered multicast, or another VLAN | redo step 2, then test with a direct cable |
A direct cable from the adapter to the coupler removes every intermediate hop and isolates the fault in one move. If ports stop answering after traffic has already run, PROFINET ports not detected after a ping covers that failure.
- Write the station name. The controller connects by station name only, never by MAC or IP. Read the current name from the scan result, then use the assign-name function to write the project's name to the coupler. Use lowercase letters, digits and hyphens. Write it as a permanent set so it lands in the coupler's non-volatile storage: a name written without that option is gone after a power cycle, a classic PROFINET fault that vendors document in their knowledge bases.
- Set the coupler address in the project. Subnet mask and gateway in the same subnet as the PROFINET interface, for instance 192.168.10.10/24. The controller pushes the address through DCP once the name matches.
- Match the module list to the terminal stack. Import the GSDML into the device repository, then add modules in the exact order and count of the terminals plugged into the coupler. A connection can come up and still fail parameterization when the list and the stack disagree. Read the coupler's diagnostic LEDs and the controller's device diagnostics; the LED meanings are printed in the coupler documentation.
- Build, download and start. Watch the device status in the IDE as the application runs.
Check it worked
- The device status shows connected, with no diagnostic entries.
- Toggle one output in the online view and watch the matching terminal LED. Forcing an output actuates real hardware, so confirm the machine side is safe before you toggle anything.
- Drive one field input and watch the value change in the online view.
- Pull the coupler cable, then reconnect it. The device must return to connected without restarting the application.
Update time and watchdog
Each device receives cyclic data once per update time. The watchdog defaults to 3 times the update time; the device and controller documentation describe that default and when to raise it. At a 4 ms update time, the default watchdog tolerates 4 ms x 3 = 12 ms without cyclic data before the connection is reported dead.
If the connection drops intermittently, lengthen the update time or raise the watchdog factor in the device's IO cycle settings, then repeat the cable-pull test. A USB adapter adds jitter compared with a native port, so leave headroom. On a single-port arrangement, downloads share the wire with cyclic frames, so repeat the stability test after every download.
Example: one coupler, eight terminals, two ports
A controller host runs the I/O for a palletizer: one bus coupler, eight terminals in the stack.
- Onboard port: 192.168.1.20/24, cabled to the engineering switch, IDE PC at 192.168.1.5.
- USB adapter: 192.168.10.1/24, direct cable to the coupler.
- The scan lists the coupler with an empty name. Assign-name writes io-coupler-01 as a permanent set; power-cycle the coupler and scan again to confirm it kept the name.
- GSDML: the coupler plus 8 modules, entered in stack order, terminals 1 through 8.
- Update time 4 ms, watchdog factor 3: 4 ms x 3 = 12 ms of tolerance.
- Cable pull at the adapter: status drops inside one watchdog window, 12 ms, and returns to connected after you replug, with no application restart.
The same station on one port runs with the PC, the host and the coupler on one switch and one subnet. The 12 ms watchdog is unchanged; only the download traffic now shares the wire.
What to choose
Recommendation: Use two ports whenever you can add the adapter: onboard port for the IDE, adapter for the coupler, direct cable between them, and nothing else on the coupler segment. Use one port for bench bring-up and for small fixed installations where the PC, the host and the coupler share one plain switch, and re-run the stability test after every download while the station is in service.
Showing the values on the floor
Once cyclic data is stable, the values reach people two ways. A dashboard bound to the controller suits live numbers and trends; a signage screen suits notices and planned content. The trade is laid out in live factory data display: signage or dashboard. For the screen itself, the shop-floor signage displays category covers units that play content from a card, with the software included and no subscription.
Questions
Why does the coupler show in the DCP scan but never connect?
The controller connects by station name only. When the name stored in the coupler differs from the name in the project, the connection will not come up even though the scan lists the device. Write the project name with the assign-name function as a permanent set, and respect the name rules: lowercase letters, digits and hyphens, no leading or trailing hyphen, and a name made only of digits is refused.
How much time does the PROFINET watchdog allow by default?
The watchdog defaults to 3 times the update time. At a 4 ms update time that is 12 ms of tolerated silence; at 8 ms it is 24 ms. Raising the factor or the update time tolerates jitter from a USB adapter or a busy segment, and it slows the report of a genuinely dead device by the same amount.
Can the engineering PC reach the coupler through the controller when both ports are used?
No. With standard Ethernet adapter hardware each interface is a single port, so the two cables sit on two separate segments and nothing forwards between them. When you need a browser or a vendor tool pointed at the coupler, connect from a PC on the coupler's own segment or move the cable to that segment.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.