difference between field bus and profibus

S

Thread Starter

sathesh

Dear friends,
I am sathesh.I am working in automation field.
i want to know about some communication protocols.

what is the differnce between field bus and profibus.
And the difference between profibus with MPI.
I am more interested to learn about MPI and profibus. i dont know how to get more information about those two.

Anybody please give me a good solution.

i am awaiting for your kind reply.
with regards,
Sathesh.
 
A

A PLC Programmer

Dear Satesh,

It's more better if you concentrate on the following protocols:

RS 232
RS 422
RS 485

What these PLC and DCS making firms did is that they used the above-mentioned protocols and changed Software as well as Hardware for the above protocols to make their own proprietary protocols.

To make things simple just stick to their useage, not go in detail about what is actually happening because some protocol Software and Hardware are so much secret that even employees of the respective companies even do not know how these protocols work...
 
J
RS 232, RS 422, RS 485 are not complete protocols. There are thousands of different protocols using RS232, thousands of protocols using RS485, and some using RS422 and none of these will talk to the other so finding out the details is important.

Cheers,
Jonas
 
J
Getting information on PROFIBUS is easy: http://www.profibus.com

I have also tried to find information on MPI which is a Siemens protocol but could not find what I was looking for.

FDL, FMS, MPI, PPI, and PPI+ are protocols that exist on the same wire as the PROFIBUS (DPv0, DPv1/PA, DPv2/ProfiDrive) protocols if you use a Siemens system. I believe they are used for peer-to-peer communication and redundancy, etc.

By fieldbus I assume you are referring to Foundation fieldbus, sometimes called just Fieldbus or "FF". It is easy to find: http://www.fieldbus.org

In my personal opinion, the main differences between Fieldbus and PROFIBUS are (most of these differences boil down to differences in the "data link layer" of the protocols):

1. FF is "scheduled" and therefore has dedicated real-time (RT) and non-real-time (NRT) channels (time slots) ensuring that non-critical NRT communication does not interfere with time-critical RT communications. This ensures communication/sampling is precisely periodic (isochronous). This is important for PID control because the "I" and "D" terms contain a "dt" which must be precisely periodic. This precise period is called the "macrocycle" and it set to 250/500/1000/2000 ms depending on the process requirements.

Isochronous operation is important for motion control so PROFIBUS DPv2/ProfiDrive communication is also scheduled. But PROFIBUS DPv0 and DPv1/PA are not scheduled and therefore not so suitable for PID control. If you run DPv0 or DPv1 at 12 Mbit/s you can do oversampling to reduce this effect, but for PA at 31.25 kbit/s you can't. I therefore personally believe this is why FF is preferred in petrochemical and chemical industries that have a lot of high performance PID loops.

2. FF has function blocks based on IEC 61804-2 that can be selected and linked together to build control strategies distributed among field devices, just like you build control strategies in your DCS. There are several advantages of doing Control-In-the-Field (CIF) using FF, but you don't have to. Also with FF central control is possible. CIF in my personal opinion advantages include faster loops (because less communication), slightly higher reliability (fewer parts involved), and somewhat greater resistance to noise (fewer links to upset). An important characteristics of the FF blocks is that they are also part of the "schedule" meaning that the communication and control execution are synchronized to each other. This means that communication of the measurement is scheduled precisely after the AI block finishes execution, and the execution of the PID block is scheduled to start precisely as the measurement value arrives, the communication of the manipulated variable is scheduled precisely after the PID block finishes execution, and the execution of the AO block is scheduled to start precisely as the manipulated variable arrives. Firstly, this means dead-time is minimized. Secondly, it means sampling is precisely periodic with minimum of jitter. All of this is good for PID control. Like point 1 above, it improves performance, reducing process variability so setpoint can be moved closer to optimum. Throughput increases and so does quality. The links between the function blocks contain status that tells the validity of the measurement, if it is limited (e.g. to prevent rest windup), and a clever mechanisms to shut the loop down on sensor failure plus a mechanism to ensure bumpless transfer and prevent windup when control valves are operated manually and some other neat stuff.

Some argue that PA also has function blocks, and indeed there is something called "function blocks" but they don't do PID, signal selection, computation, limiting, or dynamic compensation etc. and cannot be linked together like the FF blocks, and in your DCS CPU, to form a control strategy. This is a big difference. PROFIBUS DPv0 and DPv1/PA do not have this ability to synchronize control and communication, and therefore cannot perform like DPv2 or FF.

3. FF has automatic addressing. Apart from plug & play being very convenient, it eliminates human errors such as address duplication. All devices have a unique ID similar to Ethernet MAC address used to resolve conflicts automatically.

PROFIBUS has manual address assignment, either using software or DIP switches.

4. FF supports peer-to-peer communication called publisher/subscriber. For example from transmitter to valve positioner directly without going through a DCS/PLC. This enables CIF. This is the primary of three modes of FF communication. It also allows a transmitter mounted in an inconvenient spot to send a value to a field display at eye-level. Publisher/subscriber is multicast so control system, valve positioner, and display get the value in a single communication.

PROFIBUS is master-slave, that is the PLC master polls device slaves. This is another reason CIF is not possible.

5. FF supports alarm & event notification. This is the third mode of communication. It allows the device to tell the system if there is an alarm or failure, so the system need not constantly poll for status. Moreover, alarms and events are time-stamped at source (in the device) so you know exactly when it happened. FF supports clock synchronization. That is every device has an internal real-time clock to support the "scheduling" and time-stamping.

PROFIBUS does not have this capability

6. FF supports firmware download so you can upgrade devices. Downloading these huge files without impacting control is possible because FF provides separation between this non-time-critical communication and the real-time communication for control. Moreover, valve positioners have a mechanism to switch bumplessly from old to new firmware version.

There is no other means to achieve a comparable result

Having said all that, there is no variable speed drive or motor starter using FF, but with PROFIBUS-DP there are plenty so you actually need to use both FF and PROFIBUS-DP. That is, look for a system that support both. Both FF and PROFIBUS support EDDL (as does HART). EDDL makes it easy to get the best of both worlds. Use FF for instruments and PID loops, and use PROFIBUS for drives and starters. IEC 61804-3 (sister standard to the FF function blocks) http://www.eddl.org for more information.

To learn more about fieldbus and PA and stuff you did not know about HART take a look at the yellow book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" buy online: http://www.isa.org/fieldbuses

Also check out fieldbus courses at: http://www.plantwebuniversity.com

Cheers,

Jonas
 
RS-232, RS-422, and RS-485 are technically not protocols but are line interface standards. They describe the physical characteristics such as connectors (not always followed), signaling (voltage, timing, single-ended, differential, etc.)

The protocol is the structure of the bits being transmitted (the organization of the octets, transparency techniques, etc. forming the message, frame, etc.) or in other words the rules the transmitter uses to compose the message and the rules the receiver uses to decompose the message and extract the information.

Many protocols have been developed for each of the line interface standards. Consequently, it is usually easy to connect interfaces together correctly and still have each end not understand the other. As Jonas said below.

Some protocols specify a particular line interface standard, others do not. For example, it is possible for to PCs to communicate using a particular protocol, like Kermit, via Com ports that are RS-232 or RS-485. And protocols such as IP can be carried by network as well as RS-xxx. Like many things, the devil is in the details, and the details can get deep.

Bill Code
 
Dear Jonas,

Thanks for your kind reply.

I went to profibus.com webpage, and I searched for something. But I couldn't get the full information about what I need.

Can you please tell me how can I get my requirements on that webpage? Where do I have to search on that page? Please give me the good solution for my confusion. I am waiting for your kind reply.

With Cheers,
Sathesh
 
Hello satesh,

Profibus is nothing but Fieldbus. Fieldbus is not a product but it's a group of standards that all PLC and DCS making companies follow for their field communications. Profibus is a Fieldbus, which follows the standards of Fieldbus so that it could be compatible with all manufacturers, that's all. Thanks.
 
J

James Ingraham

"...the difference between Profibus and MPI..."

Great question. No good answers, I'm afraid. But here's a rough idea.

Profibus is a network, with lots of devices hanging off it. The network is designed to continuously scan all the devices to get and send pre-set information. If something is missing, or the information the system has been set up to look for doesn't look right, you know there's a problem. That's different from an office network, where people plug and un-plug all the time, and the amount of traffic jumps up and down as people print, start a download, or shut down.

MPI doesn't do the continuous scan. It's more like an office network, where the traffic goes up and down, and the timing isn't as critical. It's used for things like programming the PLC, connecting to HMIs, etc.

Less wordy:

Profibus = networked control of devices with pre-defined parameters (I/O, drives, etc.)

MPI = non-time critical unsolicited communications (programming, PLC-to-PLC comm, HMIs, etc.)

As an aside, there are lots of annoying names in the industrial network arena. Things like Profibus are often referred to as a "fieldbus." But then along comes Foundation Fieldbus and now we don't know if you mean FF or generic if you use the word "fieldbus."

How about we switch to "device-level network?" Nope, Allen-Bradley already took "DeviceNet." "Controller Area Network," or CAN, to go along with LAN, WAN, WLAN, etc? Nope; CAN is a specific beast. So is ControlNet (another A-B gem).

A-B is really good at messing up names, btw. They caled one of their earliest networks "Universal Remote I/O," inevitably shortened to "Remote I/O" whenever anyone talked about it. But "remote I/O" is a CONCEPT. So we had that whole, "Do you mean the generic idea of having I/O mounted in a location away from the controller or do you mean A-B's specific network?" Fortunately, Universal Remote I/O is essentially dead at this point.

The confusion gets even worse with Ethernet. I've spent the last ten years trying to get my sales guys to understand that just because two devices have Ethernet ports that does NOT mean they can talk to each other. There are dozens of protocols that run on top of Ethernet. Some of them use TCP/IP to get them where they're going, some don't. Some use UDP/IP, which is pretty straight forward if you're used to TCP, but it's still different. And some use something else entirely. And note (here comes A-B's genius again) that "EtherNet/IP" is a specific thing. It's not "Ethernet TCP/IP." The "IP" in "EtherNet/IP" stands for "industrial protocol." The "IP" in "TCP/IP" stands for "Internet Protocol." EtherNet/IP (note the capital N) is actually a SET of protocols, some of which use TCP/IP and some of which use UDP/IP. It uses multi-cast or uni-cast. It has peer-to-peer and scanner-node functionality. So even if you tell me two devices have "EtherNet/IP" I *STILL* can't t
ell you if they'll talk to each other.

To say nothing of Modbus/TCP, Ethernet PowerLink, Profinet (in NRT, RT, and IRT flavors), EtherCAT, SERCOS III, SynqNet...

-James Ingraham
Sage Automation, Inc.
 
Top