An ABB controller must determine whether every configured PROFINET participant is exchanging cyclic data and identify any missing device. The project uses Automation Builder 1.2 with source opened in CODESYS V2.3, while the field devices include SICK and SEW equipment. Use controller-side PROFINET diagnostics as the primary status source; an IP response alone does not prove that cyclic PROFINET communication is operating.
Separate PROFINET Health from IP Reachability
The PROFINET controller already communicates cyclically with each configured field device and therefore must track whether that communication is running. Obtain the device-level diagnostic or communication-status interface from ABB for the controller and runtime in use. The available evidence does not identify the applicable ABB function block, command, or diagnostic variable, so do not substitute a guessed identifier.
| Signal | What it establishes | Limitation |
|---|---|---|
| Controller PROFINET status | Whether the configured participant is communicating through PROFINET | The ABB access method remains undocumented in the available evidence |
| SICK life bit | Whether the application is receiving the changing device signal | Requires evaluation logic in the controller application |
| IP ping | Whether an IP endpoint answers the reachability test | Does not establish working PROFINET cyclic communication |
| HTTP request | No relevant diagnostic behavior is established by the evidence | Do not treat an HTTP response as PROFINET health |
Build the Missing-Device Decision Path
- Enumerate every configured PROFINET participant that the application must supervise.
- Request the ABB controller's per-participant PROFINET diagnostic interface, specifically for Automation Builder 1.2 and the CODESYS V2.3 source environment.
- Map each participant's controller-reported communication state to its configured device identity so the application reports which participant is absent.
- For the SICK device, evaluate the manufacturer-recommended life bit as an additional application-level check.
- For the SEW device, rely on controller-side PROFINET status unless SEW or ABB supplies another documented signal.
- Use ping only as a secondary network-reachability test when controller diagnostics show a failure; never use ping success to clear a PROFINET fault.
Verify the Diagnostic Result
During commissioning, disconnect or otherwise remove one participant at a time and confirm that the controller reports the correct device rather than only a general bus fault. Restore the participant and confirm that the PROFINET communication state recovers. For the SICK participant, also verify that stopping the life-bit activity produces the intended application alarm.
Do not proceed with OSCAT Net.Lib functions such as IP_Control or HTTP_Get as the primary solution until their role is explicitly limited to secondary reachability testing. The evidence provides neither their required connections nor proof that they expose PROFINET communication state.
FAQ
Can ping prove that a PROFINET device is working?
No. A successful ping establishes IP reachability only; it does not prove that the device is exchanging cyclic PROFINET data.
How can an ABB PLC identify which PROFINET device is missing?
Read the PROFINET controller's per-participant communication diagnostics and map each reported state to the configured device identity. Ask ABB for the interface applicable to Automation Builder 1.2 and the CODESYS V2.3 source environment because the evidence does not identify its block or variable.
Should I use the SICK life bit or PROFINET diagnostics?
Use controller-side PROFINET diagnostics for bus communication state and evaluate the SICK life bit as an additional application-level health signal. Test both by removing communication and confirming the correct alarm.