Modbus tcpip v Profi

[JRW]

Just to add a point-
Siemens drives do have profibus peer to peer mode. It uses the master for a clock, but the values are sent directly from drive to drive.
Also- don't forget about profibus isochronous mode.

 

[BobB]

Interesting discussion.

Have used Profibus and found it worked quite well. Has quite good speed.

Have used Modbus RTU (not many have not these days) and works reliably although slowly. Have not used other flavours of Modbus.

Have used Device Net extensively because my preferred PLC manufacturer supports Device Net very strongly - also supports Profibus because you are dead in the water in Europe if you do not.

I do not use Ethernet based networks, including Ethernet IP, due to collisions and variable arrival times, although many claim IP is good. Ethernet is good for SCADA systems to extract data from PLCs but prefer to use deterministic networks for peer to peer. The peer to peer network I use is Token Ring based and very reliable. I have also heard claims that managed switches improve performance and stop collisions but have no experience there.

Device Net is extremely reliable and very well supported by most manufacturers. There is plenty of good product out there for Device Net. The disadvantages are that it is not very fast and one has to be careful to install the network correctly - including wiring the power supply into the middle of long Device Net runs - Device Net will not tolerate voltage drops of any degree outside the specified limits over the length of the run. It just will not work properly - have been there.

 

[Steve_D]

I will answer as best as I can... thanks for the input guys!

So lets do this like engineers and not salesmen. Lets ask Steve_D
1. How many nodes are there?
Around 200 devices, flow meters, remote bases, VSD's etc
2. How frequently must the nodes be updated?
We are controlling a water filtration plant so technically not fast but still, request to stop mustn't take seconds.
3. How much data is being transfered?
Some VSD's will have parameter data but generally only flow rates, pH etc
4. Is the data message data or I/O data?
I/O data
5. Is there a need for peer to peer?
Yes but that is to be handled differently
6. Is there a need for multi-master?
Not sure what you mean here.
I'm leaning towards profi

Again thanks for your help!

 

[PeterW]

Ethernet is good for SCADA systems to extract data from PLCs but prefer to use deterministic networks for peer to peer.

Thats about where I sit.

Ethernet is a must for higher level communications and data gathering and where required PLC to PLC, although (as I'm mainly a Siemens user at the moment) I would prefer DP couplers for PLC interfacing.

Profibus DP for PLC to PLC, I/O (in panels) and devices.

ASi for actual I/O in the field (not in panels).


For other PLC types there may be other options to Profibus, such as Modbus, Devicenet etc..




From earlier part of thread, for testing and commissioning the profibus network tools (distance measuring, line breakage, swapped cores etc) is a must for quicker checking.

 

[GeoffC]

With regards to the Ethernet 'collisions' issue. A couple of points usually there is a small percentages of the devices on a network actually requesting data. From the list of devices Steve_D gave most of these devices are dumb simply responding to data requests. So not much chance of collisions
Also my understanding of Ethernet networks is they have improved dramatically with the use of managed switches and full duplex comms. Read an interesting post on this topic on another forum, have a look at the following http://modbus.control.com/user/1026191579/index_html specifically the post by Dick Caro where he argues that todays ethernet is Deterministic

 

[GeoffC]

Also fault finding. I would much prefer a star based topology to a bus based system. Have had to try and find a bad node on a bus system a number of times and would not wish it on anyone (remove node..check performance..replace node..try next node..repeat..after checking all nodes twice find bad cable connection)

And also media conversion (not sure about Profibus) but can't be easier to convert to fibre or radio from ethernet

And also as well Jesper you might like to Google ModbusTCP (or Modbus TCP) you might be surprised just how many vendors support ModbusTCP, as for drives try ABB, SEW, Control Techniques, Mitsubishi, Schnieder, Automation Direct, Toshiba...and lots more

 

[JesperMP]

as for drives try ABB, SEW, Control Techniques, Mitsubishi, Schnieder, Automation Direct, Toshiba...and lots more

You are right. SEW and ABB are definitely important amongst the drives suppliers.

 

[JesperMP]

Also fault finding. I would much prefer a star based topology to a bus based system. Have had to try and find a bad node on a bus system a number of times and would not wish it on anyone (remove node..check performance..replace node..try next node..repeat..after checking all nodes twice find bad cable connection)

I think that it is not proper comparison to pick out one example where Modbus TCP worked better for you than Profibus.
You can find similar examples where Ethernet would give problems where Profibus would not.
Ethernet is more complex than Profibus, but also more performant and scalabe.

 

[JesperMP]

I have to admit that Modbus TCP is getting more widespread than I imagined.
I drilled a bit down into it, and discovered that even Siemens S7 supports Modbus TCP:
http://www.industry.siemens.com/it4industry/EN/solution_services/SIMATIC_ADDONS/PROTO_MOD.HTM
You have to purchase a license per installation, but at least it is possible.
Also, WinCC Flexible supports Modbus TCP, but that I knew.

It doesnt change my opinion about Profibus vs. Modbus TCP though.

 

[Ken M]

Have had to try and find a bad node on a bus system a number of times and would not wish it on anyone (remove node..check performance..replace node..try next node..repeat..after checking all nodes twice find bad cable connection)

Yeah, I wouldn't wish that way of fault-finding on anyone either. You can't say that's a fault of a bus-based system. That's bad use of diagnostics or tools.

Here's an example which is admittedly a little more advanced than the basic tools I described earlier. I saw this in a plant with Manufactuere A's CPUs and Manufacturer B's I/O connected on DP. There were intermittent errors and drop-outs with some I/O and Manufacturer B was called in to fix it. Their engineer arrived on site with a some network analysis software on his laptop. Within about 10 minutes he said "OK the problem's somewhere downstream of node 20. Let's go and check from there." We walked off through the plant to a row of control cabinets where some of the DP nodes were located, including 20. He hooked up once again. "OK, here we go. The cable distance between here and the next node is too great for the Baud rate the network's running at." This seemed weird to everyone present. Node 20 was in one cabinet and the next one (numbered 21!) was only an arm's length away in another cabinet facing it across a narrow corridor. The engineer was adamant - "Look, I can measure the response time here and there's all sorts of delays in this section." Even allowing for cable going up in to the trunking in the ceiling, across, and back down again we couldn't see more than 10-15 metres would have been used. Eventually we got some ladders and had a look up in the ceiling. And guess what? A drum of Profibus cable sitting up there, with probably 250m still it, connected between nodes 20 and 21! What on Earth had the installer been thinking of? Fixing the problem was dead easy. But the point is thanks to Manufacturer B's engineer, we were told where the problem was, and then what the problem was, despite all the visible evidence being against it.

With the right tools, every job becomes easy.

Regards

Ken

 

[GeoffC]

Ken merely trying to illustrate that a bus system is inherently harder to fault find than a star based topology. Had a bus system once where some form of noise was being injected affecting all nodes (error counts all over the place), made even worse as half the bus was in an underground mine, and we were 900km from anywhere. Only available diagnostic tool available at the time (yes I know there are more tools available now) showed error counts for each node and as I said these where all over the place.
Anyway in a choice between star and bus give me star anytime. A fault on one branch normally only affects one branch. Cutting a cable results in a single node failure. Adding a node is only a matter of plugging it in.

 

[sarathlal]

hello

I am going take datas from enercorn 6400 energy meters using abb ac31 series plc .please some one help me to complete this project.i hope some of u may have the ladder and schematic diagram related to this .help me

 

[danieluy]

<bump>

I believe this is a good topic... but it is old... anybody care to update?

Actually some of you will be right for the wrong reason.

1. How many nodes are there?
With lots of nodes collisions become a problem. Our biggest applications with the most axes are Profibus DP.

Yes, i believe this is the downside of Ethernet because it is collision detection. but why is Profibus better than this? what about DeviceNet?

4. Is the data message data or I/O data?
If the data is message data I favor Ethernet.
If the data is I/O data then Modbus TCP may work but it is not a good choice. This is Modbus TCP's weak spot and Profibus DP's strength. Ethernet/IP would be better than Modbus TCP.

Why is Modbus not suitable for remote I/O? is it because of it CSMA/CD? how does Profibus do it? is DeviceNet Better?

 

[Peter Nachtwey]

<bump>
Yes, i believe this is the downside of Ethernet because it is collision detection.

The collisions can be largely avoid by using expensive switchs. The more expensive switches are necessary with protocol like Ethernet/IP were the slave devices can produce data on their own.

but why is Profibus better than this?

The slaves do normally produce data on their own. The master polls each slave in turn so there are no collisions. Even in Profibus DPV2 there is a time slot where the slaves can produce data but as JRW pointed out above, there is a time slot allocated for the slaves that produce data.

what about DeviceNet?

Way too slow for many applications. DeviceNet may not be too slow for the OP. For motion control I find DeviceNet too slow unless the motion controller or drives are very smart.

Why is Modbus not suitable for remote I/O? is it because of it CSMA/CD?

Now you are getting to why I don't like Modbus/TCP.
It TCP has an error it will retry to send old data. This is fine if the data is parameters but if the data is I/O it should retry with new data.
There should be a Modbus/UPD as part of the standard.

how does Profibus do it?

Profibus retries with new data. Profibus DP's weakness is its lack of ability sending messages or large amounts of data.

is DeviceNet Better?

DeviceNet is smarter but MUCH slower. Profibus DP wins by brute force ( higher bit rates 12 MB vs 500K ).

 

[Nick B]

I think a better comparison would be Profinet vs Modbus TCP/IP.


Nick