【Daily Question 20090327】--What is everyone’s understanding of a bus?

Seeing the moderator’s daily question, I happened to be working on a water treatment project outside recently – two sets of 414-2DP systems, each with an additional DP expansion module. There were nearly a hundred stations in total (all using PLC modules, without any driving mechanisms). When setting up the DP network, it almost always worked right away upon power-up. However, I encountered one problem, and it was again due to issues with the DP heads installed by the construction team. I tightened the string again, and that’s it. Let me provide some guidance and also summarize the reasons why this attempt to connect to the DP network went smoothly: 1. I conducted numerous experiments at home, carefully studying each station’s couplers and templates. Don’t be afraid of the hassle; it’s much better to face some trouble at home than to run into problems on site. 2. When configuring the hardware, indicate the names of each station clearly to facilitate dialing the station addresses. 3. Before powering on, carefully checked the power supply, station address, and the ON/OFF settings on the DP header to ensure they were correct. 4. Let’s talk about the problem with that DP header: The phenomenon at that time was that, starting from that station, the subsequent stations could not be detected. I took the DP header apart and checked the cables; there was no issue with them! I went to the next station to check the DP header and measure the cables; everything was fine. Later, it was suspected that the distance was too great, so the speed was reduced, but it still didn’t work. There’s no other choice; I need to check the DP connector carefully one more time. If that doesn’t work, I’ll disconnect the subsequent networks and try them one by one. This time I finally managed to identify the problem. It turns out that one of the two wires was tightened, while the other wasn’t; so when pulling back and forth, nothing could be noticed, but when pulling side to side, the issue became immediately apparent. It’s my fault for not checking carefully; after tightening it, everything was fine. 5. A friend called me a couple of days ago and said that the DP network he had set up, which included a 315-2DP unit along with two ET200 units, wasn’t working. Since I wasn’t at the site, I could only suggest several possible solutions based on what he told me, but none of them worked. The next day he called me and said the network was working now; it turned out the problem was that the DP cable was connected only at the output side of the DP connector, while it wasn’t connected at the input side. I’m sure experienced users are well aware of this, but I’d like to remind beginners: if only one DP cable is connected to the DP port, it must be connected to the input side of that port! (I remember that this problem also caused me a lot of trouble back then; it took several attempts before I figured out what was going on.) Actually, once you write it down, it seems like it’s not that complicated after all – there’s nothing special about it. As long as you follow the steps carefully, no matter how many stations there are, it shouldn’t be a problem.

You are referring to FieldBus, right? It is an open, fully digital, two-way, multi-station communication system used between field instruments and control room systems. There are many types of them, such as: FF, ProfiBus, ControlNet, DeviceNET, WorldFIP, P-NET, InterBus, CAN, AS-i, etc

In the past, whether in power plants or chemical industries, traditional DCS systems were used as control systems. Now, both power plants and chemical industries are starting field bus projects. I guess the use of fieldbuses will become more widespread in the future. Currently, when people talk about fieldbuses compared to traditional DCS systems, they mention that fieldbuses save on cables, rack space, and debugging time. In my opinion, what’s most important is the fact that there are increasingly more smart instruments and devices today, all of which have self-diagnosis functions; therefore, online maintenance and monitoring of field devices is also a major advantage of fieldbuses.

The common pathway for transmitting information between components is called a bus. When the bus is idle (with all other devices connected to the bus in a high-impedance state) and a device wishes to communicate with a target device, the device initiating the communication drives the bus to send out the address and data. Other devices connected to the bus in a high-impedance state will receive the data on the bus once they receive (or are able to receive) an address identifier that matches theirs. The transmitting device completes the communication and releases the bus (the output goes into a high-impedance state). Based on function, they can generally be divided into address buses and data buses. Based on the method of transmitting data, they can be divided into serial buses and parallel buses. Based on whether the clock signal is independent, they can be divided into synchronous buses and asynchronous buses.

A bus is an internal structure that serves as a common channel for the transmission of information between the CPU, memory, and input/output devices. The various components of the computer are connected to each other through the bus, while external devices are connected to the bus via corresponding interface circuits; this constitutes the computer hardware system. In a computer system, the common pathway for transmitting information between different components is called the bus, and microcomputers rely on a bus structure to connect their various functional components.

A fieldbus is a digital network used in process control environments; it facilitates not only the exchange of process control information but also the exchange of device management information. Through fieldbuses, various intelligent devices (smart transmitters, controllers, analyzers, and distributed I/O units) can exchange data conveniently, and process control strategies can be implemented entirely at the field device level. Currently, the most commonly used fieldbuses are the FUNDATION Fieldbus Foundation fieldbus (FF bus) and the Profibus fieldbus. The application of fieldbus technology enables the easy connection of various intelligent devices and I/O units located at the control site, thereby forming a control system; this structure has become the trend in the development of DCS. Fieldbus overcomes the drawbacks associated with communication in DCS systems, where such communication is handled by closed, proprietary network systems, by transforming solutions based on such proprietary standards into ones based on open standards ； At the same time, the DCS distributed control structure, which combines centralized and decentralized elements, is transformed into a new fully distributed structure; the control functions are completely delegated to the field, with the on-site intelligent devices themselves handling the basic control tasks. The commonly used systems at present are SIEMENS’ S7 and ABB’s Freelance2000, with PROFIBUS being the fieldbus used in them.

Fieldbus control systems are known as the fifth generation of control systems and represent the future direction for the development of such systems. At present, they are not yet widely recognized in China, and fieldbus instruments are relatively expensive. However, large chemical companies in China have already started to use fieldbus control systems, such as Huizhou Ethylene and Shanghai Saike Company.

The main problem with fieldbuses is the lack of standardization in protocols. Unlike analog signals such as 4–20 mA, which can be used in any system, although interconnection between different systems is possible through protocol conversion, the cost of doing so is very high. As a result, the application of fieldbuses is limited to some extent

My understanding of FiledBus. It might differ from IEC standards, haha. But it seems to be more recognized by ABB and Siemens. When discussing fieldbuses in the chemical industry these days, I classify them in this way. 1. Device-level bus. Such as Devicenet promoted by AB, and ASI promoted by Siemens. CAN, strongly promoted by Bosch. 2. Control-level bus. --It turns out that some people in China call it a device-level bus. I don’t think it’s appropriate. Such as Profibus DP from the Profibus camp, and ControlNet from the ODVA camp. Wait. 3. Instrument-level bus. Such as Profibus PA from the Profibus camp, and FF from the FF camp. 1. Device-level bus. Buses assigned to this category are used to connect sensors and detection devices to the CPU. They’re basically all quite simple. The distance of their communication media is also very short. The rates are also relatively low. It does not have any function for on-site control. 2. The control-level bus is primarily used to connect CPU stations to IO stations, and it can also be used to connect CPU stations to each other, thereby enabling communication between control stations. It can also be used to enable communication between the CPU station and the computer monitoring station. (However, at present, Ethernet is relatively more popular in CPU stations compared to computer monitoring stations.) The characteristic is a relatively high relative velocity. For Profibus DP, the theoretical value is 12 M, but in practice it often reaches 500 K or 1.5 M. ControlNet is 5M. For longer distances, such as Profibus DP, it can reach 1200 meters. Controlnet can reach 1KM. Adding relays can extend the range even further. It has good real-time performance. A high level of real-time performance is necessary; otherwise, stable control cannot be ensured. One of the most important features is that it is primarily used to connect control CPUs, whether it is from CPU to CPU, from CPU to an IO station, or from a CPU station to a computer station. It is mainly centered around the CPU. It’s all centered around control – the CPU handles the services. 3. Instrument-level buses such as PA and FF. PA and FF are very different from each other. FF is evolving in the direction of FCS. Its concept is one that moves away from the core of control – the CPU – and delegates control functions to the field devices. Assume that, whether it is dual CPU redundancy or quad redundancy, if all CPUs fail, as long as the field bus is not powered off or disconnected. Then the field device will carry out its own control automatically. It also comes with the most basic chaining function. This is the greatest charm of FF. PA is a meter version of Profibus. At present, it is not yet possible to achieve an autonomous function such as FF’s “self-control by the field device”. The current situation is that the instrument bus ultimately has to be connected to the CPU station. Therefore, there is usually an interface module from the instrument bus to the CPU. PA relies on the DP/PA gateway. It goes over to Dp, and then communicates with the CPU. FF generally involves multiple H1s converting to HSE, and then to the CPU. Overall, the speed of the instrument bus is low. . . 31.25K is enough. 2-wire power supply with data transmission; simple. Explosion protection can be easily implemented. The cost difference between explosion-proof and non-explosion-proof versions is almost negligible. --Of course, the price difference of the instrument itself is not included in this calculation, haha. At present, control systems based on instrument buses still all come equipped with CPUs. There are no systems that rely entirely on a CPU as the central processing unit; in other words, pure FCS systems simply do not exist at present. To put it simply, people are talking about FCS replacing DCS and things like that. Well, among the 8 bus types defined by IEC worldwide, plus another around ten bus types such as CAN and Modbus that are no longer part of the IEC standards, only FF is the one that truly moves in the direction of FCS systems and greater \"autonomy\" for field devices. So, if a fieldbus is used in a DCS, is it called FCS or still DCS? The criterion for differentiation is not what is used, but rather the core of control and its philosophy – whether the approach relies on a CPU-based control system in the DCS style or on self-control by the field devices. Furthermore, the fieldbus landscape is too chaotic, with a multitude of manufacturers taking advantage of the situation. There are yet more people who know absolutely nothing, but who still consider themselves scholars, and they are misleading the public. Spreading some wrong ideas. It can only be said that this water is too deep and too turbid. It’s not easy to really sort things out. So it’s best to discuss which bus to use first, and then talk about that specific bus. Just going through all the major buses would be unrealistic and superficial without 2-3 days of time.

The bus is just a concept; the structure of cable television is also a type of bus. Therefore, it is necessary to decide which type of bus to use based on the actual conditions in the field. Consider factors such as one’s own specific circumstances, the technical support available for terminal devices, overall control requirements, and process requirements when selecting a control bus