1788-EN2DNR EtherNet Networks Communication PLC Module

Product Introduce

1788-EN2DNR is an EtherNet/IP and DeviceNet network connection module that can connect up to 63 DeviceNet slave devices to the EtherNet/IP architecture and has complete DeviceNet master functions; it also supports device level ring (DLR), can support CIP secure connection transparent transmission, and can also achieve 32 Class 0 CIP secure connections with an internal delay of ≤5 milliseconds; built-in web server, equipped with USB port, equipped with 255K Memory can realize automatic replacement of equipment and reduce downtime caused by equipment failure.

FAQ:

1.1788 – What are the specific interfaces equipped with EN2DNR? What connection purposes do each interface correspond to?

1788-EN2DNR is equipped with RJ45 Ethernet interface, DeviceNet interface, USB interface and power interface:

1. RJ45 Ethernet interface: needs to be used with Category 5e and above network cables. The core purpose is to access the EtherNet/IP network to realize communication between the module and controllers, host computers and other equipment under the EtherNet/IP architecture. At the same time, relying on this interface to support the device level ring (DLR) function, improve the fault resistance of the industrial network and ensure the stability and continuity of data transmission.
2. DeviceNet interface: adapts to 0.52mm² (20AWG) cable, corresponding to the relevant wiring specifications of 1485C-P1-Cxxx models. As a key interface to connect to the DeviceNet network, it assumes the DeviceNet master function of the module and can access up to 63 DeviceNet slave devices to realize data interaction between the two types of networks, allowing the EtherNet/IP side device to control and read the data of the DeviceNet side slave device.
3. USB interface: This module is equipped with a USB port, mainly used for local configuration operations. By connecting the computer and the module, with the help of supporting software such as RSLinx, the module parameter configuration, program debugging, and local troubleshooting can be completed, and basic operation and maintenance of the module can be realized without relying on the network.
4. Power interface: adapts to 0.25 – 2.5mm² (22 – 14AWG) copper cables with a temperature resistance of 105°C and above. The purpose is to connect to a 24V DC power supply to power the module itself and DeviceNet-related circuits. The module itself consumes 150mA and the DeviceNet part consumes 60mA. It complies with Class 2/SELV standards and is adapted to conventional industrial power supply systems to ensure stable operation of the module.

2.1788-What is the upper limit of the number of DeviceNet slave devices connected to 1788-EN2DNR? How to expand after the quantity is exceeded?

The upper limit of the number of DeviceNet slave devices connected to 1788-EN2DNR is 63. When this number is exceeded, use the following methods to solve the problem:

1. Adding modules of the same model and networking: additional 1788-EN2DNR modules can be added. Let the new modules and the original modules be connected to the same EtherNet/IP network. Each new module can be connected to up to 63 DeviceNet slave stations. This method can ensure the communication stability of each slave network, and the configuration logic is consistent with the original module. Subsequent configuration and management can be unified through supporting software such as Studio 5000 and RSNetWorx without the need to significantly adjust the overall system architecture.
2. Use DeviceNet repeaters and multi-master architecture expansion: On the one hand, use DeviceNet repeaters to first expand bus coverage and signal strength to solve the signal attenuation problem when connecting multiple slave stations; on the other hand, build a multi-master network architecture. In addition to 1788-EN2DNR, it can be used with DeviceNet scanner modules such as 1756-DNB as additional master stations. Each master station independently carries a certain number of slave stations. This method is suitable for scenarios where slave devices are distributed widely. It can not only break through the load limit of a single module, but also improve network stability by managing slave stations in different areas.