A second RS-485 port is not required for the stated three-controller architecture. The supported design uses the Pixel's built-in Modbus RTU interface for one connection and a Modbus TCP network module for the other. The exact topology depends on which controller coordinates the network and whether the controllers must form a chain.
Confirmed Interface and Protocol Capabilities
| Controller | Confirmed interfaces | Supported protocols | Design consequence |
|---|---|---|---|
| Pixel | One built-in data port | Modbus RTU | Add a network module when the Pixel must connect to a second network. |
| Pixel with network module | Built-in port plus module interface | Modbus RTU plus either Modbus TCP or LonWorks, depending on the module | Use different interfaces to connect the upstream and downstream networks. |
| SMH-2Gi | Three built-in data ports | Modbus TCP and Modbus RTU | The stated architecture can use its existing communications resources without adding an RS-485 interface to the Pixel. |
A controller can operate as both Modbus master and Modbus slave when its hardware provides the required communication interfaces. Do not infer dual-network capability from protocol-role support alone: a one-port controller still needs another physical interface to connect an additional network.
Choose a Parallel or Chained Topology
The evidence supports two architectural patterns for an SMH-2Gi and two Pixel controllers.
| Pattern | Supported communication paths | Use when |
|---|---|---|
| Parallel | SMH-2Gi < Modbus TCP > Pixel 1 SMH-2Gi < Modbus TCP > Pixel 2 |
The SMH-2Gi communicates directly with both Pixel controllers. |
| Parallel alternative | SMH-2Gi < LonWorks > Pixel 1 SMH-2Gi < LonWorks > Pixel 2 |
The project has already selected the required LonWorks modules and proprietary software. |
| Chained | SMH-2Gi < Modbus TCP > Pixel 1 < Modbus RTU > Pixel 2 | Pixel 1 must coordinate communication between the upstream controller and the downstream Pixel. |
| Chained alternative | SMH-2Gi < Modbus TCP > Pixel 1 < LonWorks > Pixel 2 | The downstream network specifically requires LonWorks. |
The evidence identifies Modbus TCP as the economic choice between the available network modules: the Modbus TCP and LonWorks modules have similar hardware costs, while LonWorks also requires proprietary software. No evidence-supported need exists to develop or add a Modbus RTU network module for this scenario.
Assign Controller Roles Before Selecting Hardware
Map the required front-end, coordinating, and control functions to actual controllers before ordering modules. The original requirement does not identify which position uses the Pixel, so hardware selection cannot be finalized until those roles are assigned.
- Identify the controller that initiates each Modbus transaction and the controller that responds on each network segment.
- Choose a parallel topology if the SMH-2Gi can communicate directly with both Pixel controllers.
- Choose the chained topology if Pixel 1 must communicate upstream and downstream.
- For a chained Pixel, retain the built-in Modbus RTU port for one segment and add the Modbus TCP module for the other.
- Confirm that each selected controller has a separate hardware interface for every network it must join.
Control Modbus Device-Integration Risk
The evidence raises a project risk involving third-party Modbus equipment such as a variable-frequency drive, but it provides no register map, supported function list, serial settings, or test results. Therefore, compatibility cannot be approved or rejected from the protocol name alone.
Before procurement, obtain the device's documented Modbus implementation and compare it with the available controller commands or blocks. If the controller does not provide a user-configurable protocol-building block, confirm that its existing Modbus functions can perform every required transaction. Treat discrepancies in device documentation or observed behavior as integration issues requiring a bench test, not as proof that another RS-485 port is needed.
Verify the Selected Architecture
- Verify that every required network segment is assigned to a distinct physical interface.
- Confirm the Modbus master and slave role required on each interface and that the selected controller hardware can support those simultaneous roles.
- Test each controller-to-controller path independently before testing the complete chain.
- For third-party equipment, execute every required transaction against the documented data representation and confirm the returned values.
- Run the complete architecture and verify end-to-end communication between the SMH-2Gi and both Pixel controllers.
If the chained design passes these checks using Modbus TCP upstream and Modbus RTU downstream, a second RS-485 port provides no demonstrated benefit for the stated task.
FAQ
Does Pixel need a second RS-485 port for a three-controller Modbus network?
No. For the stated SMH-2Gi plus two-Pixel scenario, connect SMH-2Gi to Pixel 1 over Modbus TCP and connect Pixel 1 to Pixel 2 over the built-in Modbus RTU interface.
Can a Pixel act as Modbus master and slave at the same time?
Yes, when the installed hardware provides the interfaces required for both roles. Protocol-role capability does not give a one-port controller a second physical network connection.
How do I verify a Modbus drive will work with Pixel?
Compare the drive's documented Modbus transactions and data representation with the controller's available commands or blocks, then bench-test every required transaction. The supplied evidence does not provide enough device-specific information to guarantee compatibility before that test.