To whom it may concern

We‘d like to know about the criteria for choosing a suitable bus among different kinds of Buses from the instruments to PC via PLC for dairy industries. Since this is perhaps a complex question, maybe it is best that we ask a consultant. If so, please recommend some suitable contacts to us. We are located in iran.

Alternately, if any of you is willing to discuss your experiences with different Buses in this type of application, please reply here or
contact us directly at 0098-021-6817461 . The Buses we are considering are

1- from instruments
a- Profibus DP/PA
b- Foundation Fieldbus
c- Asi
d- Lightbus
e- S908
f- ….
2- from PLC to PC :
a- Ethernet
b- Modbus
c- Fiber Optic
d- …..
The parameters we are interested in are as follows :
1- applicable standards
2- bus powered
3- intrinsic safety
4- media supported
5- communication technique
6- data rates
7- typical applications
8- ….

Thanks for your cooperation.

Yours truly
Masoum

 

Hi All

Yes you should use a consultant, the pitfalls in making these decisions can live with you for a very long time, and cause you a great deal of downtime and unwanted expense later on in the life of your plant.

I would be happy to discuss the commercial aspects of the job with you off the list.

I know someone up your way who may also be able to help.

[email protected]

If you wish

Regards
Donald Pittendrigh

 

Not particularly fond of Profibus.

ASI is designed for digital I/O.

Device Net works very well.

Ethernet is OK as long as the traffic does not bog it down and cause collisions.

Modbus RTU works well as it polls each I/O separately as often as you program it to poll but is serial and slow.

I would always prefer a deterministic style of communications as there are no collisions and data rates are always at the same speed. My preference would definately be Device Net. I have used it many times and have not had a problem with it yet.

Intrinsic safety is normally used between the instrument and the sensor not between the instrument ant the PLC but it can be done.

 

Hmmm - difficult to say that DeviceNet (8 byte packet size, so fragmentation has to be used for anything larger than that, max baud rate 500K) is without collisions, or indeed deterministic, except in very small scale installations. In fact the timing of messaging on DeviceNet is pretty difficult to work out (which of course is not to say it doesn't work, because self-evidently it does).

I've worked with both Profibus and Devicenet, desiging them into slave products, and my preference is definitely for the former. It's very simple to understand, works like clockwork, and has sufficient network bandwith (244 byte packets, 1.5 or 12 Mbaud depending on distance tradeoffs) to solve the determinism problem by brute force. The great advantage is that all slave manufacturers tend to use the same chipset and protocol stack, so things *tend* to work sufficiently alike to allow straightforward mixing and matching. For what it's worth, if it were my plant or my machine, DP would be what I would use.

Tim Linnell

 

> Ethernet is OK as long as the traffic does not bog it down and cause
> collisions.

...snip...snip...

> I would always prefer a deterministic style of communications as there
> are no collisions and data rates are always at the same speed.

Collisions are easily controlled using low-cost devices called "switches". A typical Ethernet collision will take only a few microseconds to resolve and is extremely unlikely to cause any problems in the vast majority of automation applications, even with a moderate number of collisions occuring. It is very easy to build a properly constructed Ethernet network that either completely eliminates collisions, or at least reduces them to an inconsequential number. I would even go so far as to say that using decent equipment (like switches instead of hubs) and with just a small amount of common sense that is easily gleaned from free web sites, it is hard to build a improperly designed system with Ethernet.

The pursuit of strict determinism at the data link level is a red herring for the vast majority of applications. Performance is the real issue. With the probability of an Ethernet access attempt failing to succeed after 4 consecutive collisions approaching the bit error rate of twisted pair copper wire and given that these collisions are only a few microseconds in duration on a 100Mbs Ethernet network, the probabilistic uncertainties inherent in Ethernet are completely overshadowed by its raw performance.

Collisions are nothing to be feared when you have a system that can deliver 10 or 100 times the performance of a typical deterministic system.

There are many reasons that make DeviceNet (or any other bus for that matter) well suited for a specific application (like having the right equipment available) but determinism isn't one of them.

Regards,

Ralph Mackiewicz SISCO, Inc.

 

A main criteria is the application. Like you have already realized, you need one type of bus at the instrument level and another type of bus at the
controller level. If you are doing process automation, you will find that devices such as transmitters for pressure, temperature, flow and level support only three protocols: HART, FOUNDATION(tm) Fieldbus and PROFIBUS-PA. These are bus powered and also satisfy the need for intrinsic safety. If you are doing discrete type of factory automation need optical type switches
etc. then a bus like AS-I or DeviceNet is better.

1a Profibus-DP is not used in field instruments, these use Profibus-PA. Profibus-DP is used between the remote I/O subsystem and the PLC controller, or a drive.
1b FOUNDATION(tm) Fieldbus H1 is ideal for process control instrumentation like transmitters and valves, but I/O boxes ensure that you can also connect discrete like proximity switches, buttons, motor starters, on/off valves, and solenoids etc.
1c For buttons, switches and starters

2a Ethernet does not mean much. It is critical to select a network with a standard application layer such as FOUNDATION(tm) Fieldbus HSE or Modbus/TCP. FF HSE provides an excellent redundancy scheme which is an important aspect of the host-level network.
2b Modbus is OK. To connect to PC I suggest you use Modbus/TCP i.e. TCP/IP on Ethernet instead of the Modbus/RTU on RS485
2c Fiber optic does not mean much. Make sure it is Ethernet, i.e. 10Base-FL or 100-Base-FX etc. Also, chose a standard application layer as mentioned in 2a above.

Jonas Berge
==================
[email protected]
www.smar.com