Profibus

Fieldbus Protocol

Definition

Profibus (Process Field Bus) is an IEC 61158 international standard fieldbus, including Profibus-DP (Distributed Peripheral, high speed) and Profibus-PA (Process Automation, intrinsically safe), etc. It is widely used in DCS, PLC, variable frequency drives, and instrument interconnection. Protocol converters can convert Profibus data to Modbus, OPC UA, etc., enabling interoperability between legacy devices and newly built systems.

Protocol Variants

Profibus-DP: High speed (up to 12 Mbps), used for interconnection between PLC and I/O, frequency converters, servos, and other devices, using RS485 physical layer; Profibus-PA: Intrinsically safe, used in hazardous areas of the process industry, using IEC 61158-2 for power supply and communication; Profibus-FMS: Message-oriented, less commonly used. PROFINET is the Ethernet successor of Profibus, competing with EtherNet/IP and others. European manufacturers such as Siemens widely adopt Profibus/PROFINET.

Applications and Integration

Profibus is widely deployed in petrochemical, electric power, metallurgy, and automotive manufacturing industries. Industrial gateways and protocol converters can convert Profibus data to Modbus, OPC UA, and MQTT, connecting to SCADA, MES, and cloud platforms. Profibus gateways are often needed for upgrading old production lines and collecting data to the cloud.

Token Holding and Slave Configuration

Masters take turns holding the token to reach their slaves

Masters on the bus do not speak at the same time. The token passes from master to master. Only the master holding the token may access its own slaves, and only for a limited time, after which it must pass the token on. A slave does not seize the wire. Cycle time for the whole network is therefore the sum of the time each master holds the token. More slaves, and longer input and output bytes on each slave, stretch the cycle. What looks "live" on the screen is in fact the previous round. If a programmer that also needs the token is inserted during debugging, the cycle suddenly slows. That is not a damaged slave.

The distributed-peripheral variant runs on RS485. The rate can be high, but the higher the rate, the shorter the allowed distance, and segments are extended only by the repeater rules. The process-automation variant is a low-speed bus that powers instruments in a hazardous area. Waveform, power, and intrinsic-safety parameters are all different. The two variants cannot have their wires twisted together. They have to pass through a dedicated coupler, and the coupler also has to be counted in the power load.

The DP and PA physical layers cannot be mixed

Using DP assumes a unique address on every slave, matched termination at both ends, the shield grounded at a single point, and a module arrangement in the master project that matches the slave's actual slots. Using PA assumes the bus can supply the quiescent current of every instrument plus the communication current, and that branch lengths follow the instrument instructions. Either variant depends on a device description file. The file tells the master which modules this slave has and how parameters are numbered. If the file version and the slave firmware disagree, the module can be recognized while parameters will not write, or what is written is the neighboring parameter.

It suits production lines and process stations whose equipment is already packaged, whose cycle time has to stay fixed, and whose schedule is set by the master. A slave cannot report a sudden fault whenever it wants. Alarms also wait for the next poll. If the collector only needs a few points in the cloud, it is more stable to take process values that are already arranged at the master or at a gateway, rather than hanging another master on the bus to fight for the token.

GSD version and termination

The termination resistor is the most common field error. Both physical ends of the bus have to be matched. If a slave in the middle also switches its termination on, the waveform is attenuated more than once and far slaves come and go. Termination at one end only leaves the near end healthy and far addresses dropping now and then. Second is an address clash. Replacing an instrument and forgetting to change the switches makes two slaves answer together. The master reports a checksum error, not "duplicate address." Third is grounding the shield at both ends. The ground potential difference drives a circulating current, and communication drops when a large motor starts.

Casually replacing the device description also leaves a latent fault. A new file adds a module, the old project still exchanges data at the old length, every later byte shifts, and a valve position is read as a temperature. After a slave firmware change, check the description file and the module configuration again, and compare a real value once in the master. When cycle time exceeds what the process allows, shorten slave data and reduce the number of masters first. Do not raise the rate without a ceiling. A higher rate makes both distance and noise immunity worse.

After a slave loses power and comes back, if the master does not parameterize it again, the module answers in the factory arrangement. Data length no longer matches the configuration in the project, and every following byte shifts. The power-up sequence should include one parameter check. Do not stop at seeing the slave address reappear on the bus.

Related Terms

Return to hardware knowledge base