Device bus comparison?

K

Thread Starter

Kowal, John - IND

Can anyone point me toward a good comparison of device bus speed, functionality, etc.?

Thanks in advance,
John Kowal
 
D

David Leese Dresser Valve Div., Hallibur

"Understanding Device Level Buses: A Tutorial"
by Bob Svacina

This booklet summarizes more than a dozen buses. It may be available at technical bookstores. It is also available as promotional literature through Turck, Inc.
 
E
The Synergetic slide rule is a cool tool but please be careful - it is hard to tell if you are comparing apples with apples. For example, if
you compare the data rates for Profibus-DP with DeviceNet you will see that Profibus-DP has a max. of 12 Mbps and DeviceNet is 500 Kbps. Does this mean that Profibus-DP is 24 times better? NO!!!

First of all, Profibus is very distance limited at the maximum rate and usually needs to be slowed down to 500 or 187.5 kbps for the
typical working distances in most plants. Second, the Profibus protocol uses async framing which means approx. 30% of all data bits are overhead. DeviceNet overhead is usually around 5-10%.
Finally, the response rate is nearly always limited by the host/device throughput and not the network bandwidth. So in practise you'll find the two system pretty close to equal... but you'd
never be able to tell that from the baloney poured out by the various field network marketing teams. Good luck.

Regards
Eric Byres, P.Eng.
ISA Instructor - TS05 Industrial Data Communications
[email protected]
604-682-6030
 
R

Rob Hulsebos

>The Synergetic slide rule is a cool tool but please be careful - it is
>hard to tell if you are comparing apples with apples. For example, if
>you compare the data rates for Profibus-DP with DeviceNet you will
>see that Profibus-DP has a max. of 12 Mbps and DeviceNet is 500
>Kbps. Does this mean that Profibus-DP is 24 times better? NO!!!
>First of all, Profibus is very distance limited at the maximum rate
>and usually needs to be slowed down to 500 or 187.5 kbps for the
>typical working distances in most plants.

Devicenet (=CAN) too! Every network has this trade-off (except Interbus). And CAN is more tricky than Profibus because of its timing
requirements.

>Second, the Profibus protocol uses async framing which means
>approx. 30% of all data bits are overhead. DeviceNet overhead is
>usually around 5-10%.

Right, but this is not the complete story. It depends on how much data you want to send. The CAN-overheas per frame with max. 8 bytes is 47 bits, and Profibus has 9 bytes overhead + 3 bits per byte but can send max. 246 databytes per frame. So, to send 246 databytes, on Profibus you'd need (246+9)*11=2805 bits, and on CAN you'd need 31 frames, each of 47+8*8 =111 bits, totalling 3441 bits, and then I assume that all 8 bytes in a CAN message can be used for the application data (reality is different of course).

So there is a break-even point somewhere; below this CAN is more efficient, above it Profibus is more efficient, even when it is asynchronous.

>Finally, the response rate is nearly always limited by the
>host/device throughput and not the network bandwidth.

Right; sw is often the most important factor!

>So in
>practise you'll find the two system pretty close to equal... but you'd
>never be able to tell that from the baloney poured out by the various
>field network marketing teams. Good luck.

Yeah, but that's what this list is for?

RH
 
R
> So there is a break-even point somewhere; below this CAN is more efficient,
> above it Profibus is more efficient, even when it is asynchronous.

This ignores CAN's low latency for random point to point messages, which is unparalelled by PROFIBUS.

This is the main feature of CAN, and the reason the electrical level deviates from RS485, and also why the timing is tricky. If you do not need this feature, you do not need CAN. If you do need it, you cannot use PROFIBUS (or at least you would need a MUCH higher bandwidth to get the same result).
 
C

Curt Wuollet

Subject: Re: COMM, INFO: Device bus comparison?

Hi all

What we discovered in actual testing is that the fieldbus is often rendered moot by the PLC design. The high wire speed of the bus doesn't mean much if you can only send one packet per scan. We were unable to accurately sample a 50 hz square wave (requires a 100 hz sampling rate per Nyquist) on a 12 mb/sec profibus. We noticed the same behaviour on their Devicenet implimentation.

Moral: Don't believe anything that you haven't seen. Yes the physical network
ran at 12mb/sec, just not very often.

Curt Wuollet



> From: [email protected]
>
> >The Synergetic slide rule is a cool tool but please be careful - it is
> >hard to tell if you are comparing apples with apples. For example, if
> >you compare the data rates for Profibus-DP with DeviceNet you will
> >see that Profibus-DP has a max. of 12 Mbps and DeviceNet is 500
> >Kbps. Does this mean that Profibus-DP is 24 times better? NO!!!
> >First of all, Profibus is very distance limited at the maximum rate
> >and usually needs to be slowed down to 500 or 187.5 kbps for the
> >typical working distances in most plants.
>
> Devicenet (=CAN) too! Every network has this trade-off (except Interbus).
> And CAN is more tricky than Profibus because of its timing
> requirements.
>
> >Second, the Profibus protocol uses async framing which means
> >approx. 30% of all data bits are overhead. DeviceNet overhead is
> >usually around 5-10%.
>
> Right, but this is not the complete story. It depends on how
> much data you want to send. The CAN-overheas per frame with max. 8 bytes
> is 47 bits, and Profibus has 9 bytes overhead + 3 bits per byte but
> can send max. 246 databytes per frame.
> So, to send 246 databytes, on Profibus you'd need (246+9)*11=3D2805 bits,
> and on CAN you'd need 31 frames, each of 47+8*8 =3D 111 bits, totalling
> 3441 bits, and then I assume that all 8 bytes in a CAN message can be
> used for the application data (reality is different of course).
>
> So there is a break-even point somewhere; below this CAN is more efficient,
> above it Profibus is more efficient, even when it is asynchronous.
>
> >Finally, the response rate is nearly always limited by the
> >host/device throughput and not the network bandwidth.
>
> Right; sw is often the most important factor!

...<clip>

------- End of forwarded message -------
 
Hi Rob

I agree with all your points. As you mentioned, each of the buses have strengths and weaknesses that are very application dependant. I wasn't trying to pick on Profibus in particular, I was just using it as an example of marketing hype vs.
reality. I guess what I was trying to say is that all these buses have to follow the same laws of physics, so be very careful if one bus looks significantly better than the others. There is always a tradeoff between data rate, distance
and reliability.

Regards
Eric
 
R
>I agree with all your points. As you mentioned, each of the buses have
>strengths and weaknesses that are very application dependant. I
>wasn't trying to pick on Profibus in particular, I was just using it as
>an example of marketing hype vs. reality.

Yeah, everybody thinks "That 12 M of Profibus is better than that 0.5M of Interbus, so I'd better forget about that one". What I always say in my seminars, bitrate is not important, cycle-time is.

>I guess what I was trying to say is that all these buses have to follow
>the same laws of physics, so be very careful if one bus looks significantly
>better than the others.

Right. We know, but them users take the highest bitrate from the table, connect it to the longest distance, and off you go. If life were only that simple ;-)

Greetings,
Rob
 
Top