【Weekly Question 20090525】Please list the characteristics and application methods of control system communication that you are familiar with

The system we use most frequently is the AB Logix hybrid control system; redundant ControlNet communication is employed between the I/O devices and the controllers, while redundant Ethernet communication is used between the controllers and the host computer. Currently, we also often encounter problems with communication between the control system and third-party controllers. Last year, for our control system, a third-party module was used to communicate with the Siemens 315 PLC, using the MODBUS protocol ； This year it is also used with a Siemens 315 PLC, but via Ethernet. It seems that the PLC of AB has very powerful communication capabilities; there is nothing it can’t do, only things that haven’t been thought of yet. Also, I think the AB software is very user-friendly.

For the Siemens S7400, PROFIBUS DP networks are used to connect the PLC control stations; the total number of points is around 1000. Communication with higher-level systems is carried out via Ethernet. Remote stations use both DP buses and Ethernet; Ethernet is more convenient for communication with computers, though it offers somewhat excessive capabilities for low-level control tasks.

I tried using a PLC equipped with a loading quantity meter to communicate via the 485 bus with the CS3000 bus PLC card, but it turned out to be quite difficult; either data couldn’t be read or written. At that time, the manufacturer of CS3000 hadn’t managed to solve this issue either. Later, I skipped the loading instrument and wrote my own program to use the CS3000 to control loading.

Siemens 300, 400, and CNC systems use PROFIBUS for communication between PLC control stations, which offers fast speeds; the 200 series uses MPI for communication

In a somewhat emotional way of putting it, AB’s communication capabilities are practically child’s play compared to those of Honeywell. From the CPU station to the IO station. AB’s CLX5000 is ControlNet. HW’s PKS C200 is also ControlNet. However, the CNET main site for AB can only have 1 pair, while that for HW can have up to 3 pairs. ----It’s not just a matter of redundancy; there is a function for accumulating the number of connections, and redundancy and fault tolerance are merely the most basic features. The CNET IO connection count for AB is 64, while it is 128 for the new version of CN2R. The CNET module of HW is still manufactured by AB, but HW manages to achieve 128 IO connections through its own unique redundancy and accumulation methods. Meanwhile, in AB’s redundancy system, the number of CNET IO stations is less than 2; when there is only one such station, a CPU redundancy switch can lead to catastrophic consequences – the IO connections will be reset first, before the system returns to its state before the switch occurred. The CNET module on the master station of HW requires a minimum of 2 pairs. This situation will not occur. The CNET communication module CNBR at AB’s CNET IO station can have only one CNBR. Cable redundancy on CNBR can be achieved at most. The HW’s CNET IO station is equipped with 2 CNET communication modules, namely CNI (which is the OEM version of AB’s CNBR); this provides both cable redundancy and communication module redundancy, resulting in a total of 4 communication links. The Ethernet communication between AB’s CLX5000 CPU main control station and the computer stations \"must not be redundant\"! Even if you use 2 pairs of ENBT on the CPU, redundancy cannot be achieved! Because any break in one of the ENBT connections will cause the CPU to switch, so it’s useless to use 8 ENBTs. And HW’s FTE is 2 Ethernet modules and 4 links. In addition to redundancy in the Ethernet communication modules, the network cables are also redundant. It is a very high level of fault tolerance. If there is anything still lacking in the modification of AB’s CLX5000 using HW’s C200, it is the fact that AB’s IO modules still cannot achieve IO redundancy, and HW is unable to do anything about this. As an additional note, connecting the controller of AB to Modbus is extremely cumbersome, and that damned MVI device is very difficult to debug. Connecting to Profibus is even worse. SST-PFB-CLX is very difficult to debug. It is recommended to use a network manager for communication with third parties. For example, CNET to Profibus DP, or CNET to Modbus.

ABB AC800F system: Ethernet of only 10M for controller-to-controller and controller-to-computer HMI stations. But data communication is optimized very well. By using data stream monitoring software, it can be seen that the data transfer speed is below 5M most of the time. Also, I’m not sure what ABB is thinking. Yokogawa, Siemens have already moved towards 1000M. ABB is still sticking to 10M; you should know that Ethernet devices at 10M are actually more expensive than those at gigabit speeds. It’s not that 10M is that great; the main issue is that all of these components are no longer produced. Each computer station can be connected to 10 controllers simultaneously, and each controller can be connected to 10 computer stations at the same time. It’s okay. It’s just that the data traffic at the OPC Server station isn’t large enough. 1400 variables. Communication between controllers is very simple. AC800F is a standard global database. The AC800F can be connected to third parties via Profibus DP and Modbus. Communications are not complicated. The AC800F can also be connected to an FF system. There are already several achievements in the domestic market.