The controller connects to device-plc, yet every input remains zero even while the device-side InOut_64 Byte mapping shows changing output values. The connection indication and startup handshake prove that discovery and connection setup progressed; they do not prove that the device application copied its variables into the cyclic provider buffer.
Stop repeating the quick fixes
Do not spend another shift adding container privilege, restarting both runtimes, or changing controller inputs at random. Both containers already run with --network host --privileged, Layer 2 communication works between the Ubuntu VMs, and the controller reports device-plc connected. Those facts move the fault boundary past basic reachability.
| Observation | What it proves | What it does not prove |
|---|---|---|
Startup handshake appears in tcpdump
|
Frames cross the selected Layer 2 path | Cyclic output bytes contain application data |
device-plc shows connected |
The controller established a relationship with the named device | The device provider image is being refreshed |
| Device mapping current value changes | The displayed application-side value changes | The same object is bound to the transmitted submodule bytes |
| Device trace contains zero payload | Zeros exist before the controller application reads them | The controller input mapping is the original cause |
Save the working project versions and record the interface, device name, module layout, and role assigned to each runtime before changing anything. Pass check: reproduce one connection in which the controller is connected and the captured cyclic payload is still zero.
Give each runtime a definite Layer 2 interface
PROFINET uses Layer 2 services for discovery and real-time exchange. Host networking exposes the VM host namespace, while privileged mode grants broad access; neither setting selects the correct NIC or guarantees that the virtualization path accepts every source MAC used by the runtime.
A working deployment method for this class of setup is to use Deploy Control SL against the Debian server and select a MACVLAN as the virtual PLC NIC. Apply that as a controlled comparison on the Ubuntu VMs: assign each runtime a dedicated MACVLAN endpoint on the NIC connected to the PROFINET network. Keep the two endpoints in the same Layer 2 domain and prevent duplicate MAC, IP, or station-name identities.
Check the VM networking layer as well. A hypervisor or virtual switch can pass ordinary traffic yet reject additional source MAC addresses, forged transmit frames, or promiscuous receive traffic. Match its MAC-security settings to the MACVLAN design. Do not leave host networking and MACVLAN paths active as competing PROFINET interfaces during the test.
Pass check: capture on the parent NIC and the selected virtual interface, then confirm that discovery, connection establishment, and cyclic frames use the intended MAC addresses in both directions.
Bind each PROFINET role to the intended NIC
Configure one runtime only as the PROFINET Device and the other only as the PROFINET Controller for this test. Bind each PROFINET stack to the interface just proved. A runtime may find device-plc through one interface while cyclic traffic is configured against another, especially when a VM exposes loopback, management, host, bridge, and MACVLAN interfaces together.
- Confirm that the device runtime owns the station name
device-plc. - Confirm that the controller configuration targets that exact name.
- Compare the device MAC seen during discovery with the source MAC of its cyclic frames.
- Remove or disable stale duplicate device identities from the test network.
- Inspect both runtime diagnostic views for an active data exchange state, not merely a discovered or configured device.
A successful handshake establishes communication relationships and negotiates modules. It does not move application values by itself; cyclic exchange uses the configured module and submodule layout after startup completes. Pass check: the controller identifies the expected device, interface, and configured module without a mismatch diagnostic.
Trace all 64 bytes from the producer variable
Treat the device application, the device provider image, the network frame, and the controller consumer image as four separate points. The first point where the test pattern disappears identifies the subsystem to repair.
- On the device, write a visible nonzero pattern across the mapped
InOut_64 Byteoutput area. Change more than one byte so a byte-order or offset error cannot look like all-zero data. - Watch the exact mapped objects online. Confirm that the task writing them continues to run and that no later logic clears or overwrites them.
- Open the device I/O mapping and confirm that these variables occupy the device-to-controller direction. A label such as input or output is always relative to the local node: device output becomes controller input.
- Compare the configured submodule order and 64-byte length on both projects. A matching total size does not correct a different slot order or a mapping attached to the wrong module instance.
- Confirm that the controller variables read the same configured input area rather than a similarly named local object in .
| Point | Expected result | Action if zero |
|---|---|---|
| Device application variable | Test pattern changes online | Repair task execution or application assignment |
| Device I/O mapping current value | Same pattern and direction | Repair the device mapping or module instance |
| Device egress frame | Pattern appears in cyclic payload | Check provider update, interface binding, and runtime diagnostics |
| Controller ingress frame | Same payload arrives | Repair the VM, virtual-switch, or NIC path |
| Controller mapped variable | Pattern reaches | Repair controller module order, offsets, or variable mapping |
Pass check: the chosen pattern appears in the device egress capture before any controller-side mapping changes are accepted as a fix.
Capture cyclic data at both ends
Run simultaneous captures on the device VM and controller VM while the pattern changes. Capture on the interfaces proved earlier, not on an arbitrary default interface. Discovery and connection-management packets can look healthy while the cyclic provider payload remains unchanged.
If the device-side capture already contains zeros, leave the controller alone. Return to the device application-to-provider boundary: mapping direction, task execution, provider state, selected submodule, and runtime interface binding. If device egress contains the pattern but controller ingress contains zeros or no matching cyclic frames, inspect MACVLAN attachment and virtual-switch filtering. If controller ingress contains the pattern but stays zero, repair the controller’s input mapping and check its I/O status.
Use packet sequence and source/destination MAC addresses to pair the same traffic flow across captures. Do not treat unrelated management packets as process data. Pass check: classify the fault into exactly one boundary—device production, network transport, or controller consumption.
Prove startup and end-to-end operation
MACVLAN-based virtual PLC startup has shown irregular behavior, so test startup as a state sequence rather than hiding it with an arbitrary delay. Bring up the network attachment, start the device runtime, wait for its interface and PROFINET role to become ready, then start the controller. Repeat with the controller started first. Record which state fails and read the runtime diagnostics at that point.
- Cold-start both VMs and runtimes.
- Confirm the selected MACVLAN interfaces and identities.
- Confirm
device-plcreaches active cyclic exchange. - Drive the nonzero 64-byte test pattern from the device.
- Verify the same bytes in the device mapping, both packet captures, the controller mapping, and .
- Reverse selected bits or bytes and confirm that stale data is not being displayed.
- Repeat the restart test in both startup orders.
Pass check: values survive repeated application changes and both restart orders without manual rebinding or remapping.
FAQ
How do I fix connected CODESYS PROFINET inputs that stay zero?
Write a nonzero pattern to the device’s mapped InOut_64 Byte output and trace it through the device mapping, device egress frame, controller ingress frame, and controller mapping. Repair the first boundary where the pattern becomes zero.
How do I choose the NIC for a CODESYS runtime container?
Bind the PROFINET role to one dedicated Layer 2 interface. A MACVLAN selected through Deploy Control SL provides a distinct virtual PLC NIC, but the VM switch must accept that MAC address and its traffic.
How do I know whether the controller mapping is wrong?
If the controller VM capture contains the changing device pattern while the mapped controller input and remain zero, compare module order, byte length, direction, offsets, and variable binding on the controller.
When should I stop troubleshooting CODESYS PROFINET containers?
Stop when the device runtime reports active exchange but its egress cyclic payload stays zero after the application mapping, task execution, module layout, role binding, and NIC selection have been checked. Save both projects, runtime diagnostics, interface configuration, and paired packet captures, then escalate to official CODESYS support; also involve the VM platform’s official support if frames change or disappear between VM interfaces.