Some thoughts on fieldbus

Thread Content

I started working not long after graduating, and I have been involved in the automation of ironmaking blast furnaces for some time now. I’ve learned a bit since starting work. Today, with some free time, I browsed the forums and found that there are some peers who, like me, have only been working in the field of automation for a short time and don’t know much about industrial control buses, communication standards, and similar topics. In fact, I too started from knowing nothing at all. Because my major in college wasn’t automation. But I want to say to all my classmates who are in the same situation as me that, if you want to excel in automation, there are just two things to do: first, be interested in automation; second, be willing to actively learn* everything you don’t know. By that I mean not only aspects related to automation, such as processes, equipment, electricity, selection of components, and on-site experience, but also other things as well. Back to the topic, I’d like to briefly share my views on buses. If there’s anything wrong in what I say, please point it out. An industrial control bus, in simple terms, is something that enables data exchange between field devices such as instruments, and lower-level systems like PLCs and DCSs, as well as higher-level systems such as WINCC and other HMI systems, thereby facilitating communication. It mainly consists of three major parts: communication standards, electrical standards, and mechanical standards. Common buses include PROFIBUS, MODBUS, industrial Ethernet, serial ports, MPI, etc. There is also CANOPEN; I haven’t used it though, so I can’t comment much on it. Take PROFIBUS-DP, which I use most often, as an example: the hardware includes shielded twisted pair cables and conversion adapters, while the software refers to the communication protocols. This is not something we need to worry about, and the reason for that will be explained later, as we are not after all involved in protocol development. If I want to set up a PRO bus now, I just need to install the network cable and connectors as required, connect them to the interfaces of the devices that need to communicate with each other, and then select the appropriate interfaces and communication protocols in the software – that’s it. For example, if I connect the CPU of a Siemens S7-300 PLC that has a DP interface to a host computer equipped with a CP5611 card, then some people might ask why communication is not possible when connecting to the serial port of the industrial computer Well, this brings us to the issue of electrical interface standards, as the PRO bus must communicate via an RS485 interface; in other words, RS485 is the foundation of the PRO bus. The serial port on the industrial computer is RS232, which does not meet PRO’s electrical requirements, so communication is not possible. Simply put, the difference between 485 and 232 is as follows: First, 232 can only be used in PTP communication, that is, for data exchange between one device and another, while 485 allows multiple devices to be connected together (I can’t remember exactly how many; it seems to be 16). Additionally, the communication distance for 485 is greater than that of 232 – 232 has a range of only about 10 meters (I really don’t bother to remember such details, so the figure might not be accurate), whereas 485 can support communication over distances of several hundred meters. Second, the voltage for 232 is 12V, while that for 485 is 5V. Returning to the bus, then can the PRO bus be used as long as it is a 485 interface? Answer: No. Because you cannot ignore the existence of communication protocols; for example, if you connect a Siemens DP CPU to a Schneider MODBUS+ interface, you cannot use PRO bus communication, as Schneider CPUs do not support the PRO protocol. In such cases, it is necessary to add a PRO communication adapter to convert the PRO signals sent by Siemens into signals that Schneider can understand. Those familiar with Siemens PLCs are likely well aware of the DP/MPI interfaces found on some CPUs. The reason for this is that these interfaces are of the RS485 type, which means they meet the requirements of both MPI and DP standards. By selecting different communication protocols in the software, it is possible to use the same communication cables for communication. The same principle applies to other buses such as MODBUS and MODBUS+, so I won’t go into further detail. As for OPC, some people might be confused again. How come there’s another OPC? It is essentially a software interface, as well as a form of communication; it is a unified solution introduced by the OPC organization to address the differences in communication methods among various manufacturers. Although OPC is also referred to as a bus, it does not involve hardware. Enough about this; typing each word one by one is so exhausting. To master buses, it is sufficient to first understand their hardware standards and electrical interfaces; mechanical standards need to be figured out through actual use on site, as the data provided by manufacturers is usually not practical for this purpose. Of course, if you want to study communication protocols, you need to understand them first before you can use tools such as C language to develop communication software on your own. I hope it will be helpful to everyone.