A Pixel controller can become unavailable to SMLogix after a network project enables Modbus master requests on its only COM port. In the reported configuration, Pixel address 0, panel address 1, 38400 baud, firmware 271, and project communication all share RS-485.
Observed communication states
| Pixel configuration | F11 detection | Engineering implication |
|---|---|---|
| Master requests enabled | Controller is not detected | The shared RS-485 port is occupied by active master communication. |
| Master requests disabled | Controller is detected | SMLogix can use the port for project communication. |
The evidence ties the loss of F11 detection to enabling master requests, not to a mismatch in the stated node addresses or baud rate.
Why active master requests block debugging
Pixel uses the same COM (RS-485) port for SMLogix project transfer and Modbus network communication. Configuring master requests on that port therefore makes project loading and online access difficult. The stated architecture does not provide multi-master operation on this one-port Modbus connection, so the engineering workstation cannot take over the same channel while Pixel continues acting as the active master.
Restore RS-485 project access
- Disable Pixel master requests with the configuration control identified as “OK” for disabling or enabling those requests.
- Use F11 to detect the controller through SMLogix.
- Load or debug the application while master requests remain disabled.
- Re-enable master requests when returning the controller to panel communication.
This procedure interrupts active master polling during engineering access. Account for that interruption before using it on an operating machine.
Debug without disabling network operation
Use a separate Network Module path when the application must remain an active Modbus master. The reported case successfully entered debugging through an Ethernet card, confirming that a separate Ethernet communication path avoids contention on the shared RS-485 port.
Verify the result in two stages: first confirm that F11 detection returns when master requests are disabled; then confirm that the independent Ethernet path permits debugging while RS-485 master requests remain enabled. If only the first test succeeds, the shared-port limitation is confirmed and the separate engineering path still requires configuration checks.
FAQ
Why does F11 stop detecting a Pixel controller?
F11 detection fails in the reported setup when Modbus master requests are enabled on the same COM (RS-485) port used by SMLogix. Disable the master requests and retry detection.
Can I debug Pixel over RS-485 while it is the active Modbus master?
Not through the same one-port connection described here. Project communication and Modbus master traffic share that port, and the network is not operating as a multi-master system.
How can I debug Pixel without stopping Modbus polling?
Use a separate Network Module communication path. In the reported configuration, debugging succeeded through an Ethernet card while avoiding the shared RS-485 engineering channel.