Schneider Electric Exchange Community

Discuss and solve problems in energy management and automation. Join conversations and share insights on products and solutions. Co-innovate and collaborate with a global network of peers.

Register Now
Knowledge Base
cancel
Showing results for 
Search instead for 
Did you mean: 

BCX Controller can use Comm 1, Comm2, or both ports for Modbus RTU X-Driver

Issue

With the BCX Controller you can use either the Comm 1 or Comm2 port for the Modbus RTU X-Driver or you could use both simultaneously.

Product Line

Andover Continuum

Environment

  • BCX Controller
  • Modbus RTU X-Driver

Cause

Enable Comm port for X-Driver

Resolution

Use either Comm port for the Modbus RTU X-Driver as per page 16 of the Modbus RTU user guide.

If you use Comm2 you forfeit the Infinet or MSTP port, you must also create the Communications Configuration Point (Function 99) to tell the X-Driver if it should use RS232 or RS485 on Comm2.

This point is required because on the BCX Comm 2 the X-Driver needs to tell the BCX to use the RS485 port (if that is what you want to use) not the RS232 port it defaults to in its Operating System. If you did not create the point the driver would default to the RS232 port.

RS485 is half duplex so when transmitting data out the RS485 port, the driver needs to turn off the receiver so that it does not receive its own transmission. Also normally RS232 is full duplex and does not have to do this.

However be aware that on BCX's Comm2 both the RS232 and RS485 ports are Half duplex, which although does not normally cause issues with Modbus because it is a Master / Slave network where we never get unsolicited data, it could cause an issue on other protocols.

You can have X-Driver enabled on either or both ports, and there is nothing to stop you from having 2 Modbus networks, one on Comm1 the other on Comm2. You could even use a RS232 to RS485 converter on Comm1 if necessary (An Infilink200 would work fine). NOTE: The ability to enable 2 comm ports using Xdrivers can be done, but is not recommended by the Xdriver developers nor supported by PSS.

The RTU Xdriver is poll on demand. This type of driver can request a lot of data and starve the CPU on the controller which then makes the polling irregular. If 2 ports are being used then there are typically more devices being added and therefore more points increasing the requests and demand on the controller's CPU.

Use one program to control the polling on both ports. Two programs attempting to control the polling asynchronously will cause communication issues.

The BCX is able to run 2 X-Drivers but will be a little slower than having 2 BCX's. It is really down to the individual project. If it has big networks connected or update speed is critical then split across 2 controllers. If you just have a few devices on each port and the update time is not critical then you would be fine with 1 controller.

Tags (1)
Labels (1)
No ratings
Contributors