Dear List Members,

I am in charge of the project of high speed packaging machine and I found that CANOpen fieldbus is working fine for my application, but a lot of customers want to use Profibus or DeviceNet instead of CANOpen. The CiA (Can In Automation) organization is working hard on standardization and diffusion, but every time I introduce this subject to my customers I find resistence not due to technical reasons but because the well known "Big Names" as Rockwell, Siemens and so on, do not use this system.
Actually my question is the following: why do I have to move to a different and, for my application, less powerful fieldbus, only because the actual one is not sponsored by an important company ?

Many thanks in advance

Francesco Riti

Eurosicma

Italy

PS 1. I am not a CiA member
PS 2. Please do not answer "because this is market request!".

 

Your assumption that Profibus DP is less powerful than CanOpen is in general an error. There are cases but in general Profibus DP can update more I/O per millisecond than a CAN type bus just due to the 12MHZ verses 1MHZ bus. Unless the CanOpen slaves are programmed to generate their own change of state messages there is no comparison. Profibus DP can update 6000 I/O points per millisecond using brute force polling (Using a SST Profibus DP Master).
There are many PLCs that support Profibus DP and DeviceNet. That is a good enough reason to consider using these buses. I agree DeviceNet will probably not give you a performance increase. I hate to say absolutely because different Profibus DP masters, DeviceNet masters, or CanOpen master execute more or less efficiently.

 

You have to change from CANOpen because there is a difference between Engineering and Marketing. Engineers tend to be focused on the technical
solution and what they want. Marketers and Market-Driven organizations are focused on what the customer wants.

Remember, DeviceNet and Profibus are more than just a collection of components. Rolled up into products based on these standards are customer
expectations, service considerations, training, etc.

Jeff Pinegar (Engineer and Marketer)

 

I don't want to start a war, but the same is valid for CANopen: there are much more than only components. And mostly the customer wants "A brand name" but he also wants a cheap and reliable solution that fits exactly the application. Things should change sometimes, in the other case we would stay for ever at Siemens at al. And we engineers should sometimes try better solutions, shouldn't we?

with best regards / mit freundlichen Gr=FC=DFen

Heinz-J=FCrgen Oertel (sometimes also a Marketer ;-)

Heinz-J=FCrgen Oertel
port GmbH phone +49 345 77755-0
Regensburger Str. 7c fax +49 345 77755-20
D-06132 Halle/Saale mailto:[email protected]
Germany http://www.port.de

 

I agree. I don't want to start a war either. I did not mean to imply that CANOpen was somehow less than DeviceNet or Profibus and regret that my reply clearly implied a second class status for CANOpen. The point that I intended to make was that many times technical issues are only one element of a customer's decision. Furthermore, I believe that market-driven organizations are more likely to recognize and weigh these additional
factors then technology-driven, product-driven or sales-driven organizations.

Jeff Pinegar

 

>Your assumption that Profibus DP is less
>powerful than CanOpen is in general an error.
>There are cases but in general Profibus DP can
>update more I/O per millisecond than a CAN type
>bus just due to the 12MHZ verses 1MHZ bus.
You mean Mbit/s.

>Unless the CanOpen slaves are programmed to
>generate their own change of state messages
>there is no comparison. Profibus DP can update
>6000 I/O points per millisecond using brute
>force polling (Using a SST Profibus DP Master).
This is probably only true for a network with all
those I/O points concentrated on a few slaves,
not for a system with a lot of slaves each
having a few I/O points.

Some simple calculations: the max message
length of DP allows 1928 I/O points per slave,
lets round it down to 1500 for easy divide.
We require thus 4 slaves. Per slave there
will be one Profibus message with 1500 bits data
(188 bytes) and 9 bytes overhead, that sums up
to 197 bytes. Each byte is 11 bits, thus
requiring in total 11*197 = 2167 bits.
Per slave is also needed one request message of
6 bytes (66 bits), one sync delay of 33 bits,
a slave delay of 30 bits (forgot the exact #),
and a master idle delay of 75 bits.

This all adds up to 4*(33+66+30+2167+75)=9484
bits divided by 12M = 0,79 msec.

In a more typical situation, with a lot of
distributed I/O instead of using DP to collect
data from other PLCs, lets do the same
calculations. Assume that we have 60 I/O points
per module. This gives 100 slaves.

Per slave 8 bytes I/O, add 9 byte overhead.
I/O message size is thus 17*11=187 bits.
Total time needed is 100*(33+66+30+187+75)/12M
= 3,2 msec. Still very fast, but not near 1 msec.

Lets now calculate what CAN would need in the
same situation. Again 100 slaves needed.
Each slave sends a message with 60 bits I/O
points (rounds up to 64 bits = 8 bytes). Add
47 bits of overhead per message, totalling
111 bits per slave.
Total bits needed is 100*111 = 11100, divide
by 1M, giving 11,1 msec.

So CAN does not look so bad after all...
One saves on the request/reply messages that
DP requires, delay times, and 3 bits overhead
per byte.

Moral: bitrate does not say anything.


Rob Hulsebos