Modbus tcpip v Profi

[danieluy]

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

i believe you're right... anyways.. i'm gonna create a new thread for that coz i have several questions...

 

[danieluy]

hey... just noticed that this thread is "Modbus TCP vs Profi" and not any specific Profi Standard... so i guess we can continue... with this thread..

i have only used Modbus TCP/IP and would really like to know more about Profibus/ProfiNet. since not many people here locally uses them... however i want to get an good comparison between them.

and another recent advances in our field is the Wireless Tech...

most of us knows that we can use the "off-the-shelf" equips for modbus. but can it be used in industrial areas? what are the "ADD'L" features of industrial grade wifi/AP?

and does ProfiNet have wireless solutions?

does anybody know the price comparison in your own areas?

 

[danieluy]

ohh...

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.

Basically how does the more expensive switches avoid this? by internal BUFFERING?

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.

"OP"?
yes, you are right the data gathering of DeviceNet is too slow... i'm only using it to change speeds and such... So is "ProfiBus/ProfiNet" better at this? faster response times?

It TCP has an error it will retry to send old data.
There should be a Modbus/UPD as part of the standard.

that's cool for Profibus. is this the same with ProfiNet?

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

What the message size of Profibus?
Is it 500bytes for Modbus TCP/IP?

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

Smarter? How?

are there any good articles that discusses about these standards?

 

[Peter Nachtwey]

ohh...
Basically how does the more expensive switches avoid this? by internal BUFFERING?

That can be one way. That is called store and forward. When a slave produces data on the network it goes to every other device unless you have a managed switch were the data can be configured to go to just the nodes that need the data.

"OP"?
yes, you are right the data gathering of DeviceNet is too slow... i'm only using it to change speeds and such... So is "ProfiBus/ProfiNet" better at this? faster response times?

If devicenet can be set up so the slave only generated data on a change of state then devicenet can be fast and challenge Profibus DP. Profibus DP is dumb because it sends all the data all the time but the Profibus network is so much faster. I/my customers have had good luck using Profibus to control over 100 axes of motion control. I had to start and stop all the axes at the same time. I couldn't afford delays so that one axis would more before the other. Profibus DP made it possible to move all the axes together.
ftp://ftp.deltacompsys.com/public/PDF/Tamglass#101.pdf
I doubt that can be done with DeviceNet but I haven't tried. I don't want to take the chance.

that's cool for Profibus. is this the same with ProfiNet?

I don't know about ProfiNet yet. It is on our development schedule.

What the message size of Profibus?
Is it 500bytes for Modbus TCP/IP?

Profibus DP claims to be able to send 244 bytes of IO. It can but the data will not be 'consistent'. That means the data may not update all at the same time. This mode is not useful for motion control where the command and the data must be sent at the same time. It would be a disaster to send a command with another command's data. Profibus DP can only send 64 words with data consistency. That is why we have 64 word limits on our older 16 bit controllers and 32 32 bit words limit on our 32 bit controllers.

Modbus and Modbus/TCP is limited to packets less than 256 bytes. I believe the MSTR block limits the transfers to 100 or 120 words. That isn't much. A AB MSG block can send 32768 words in one command. However, that data is actually sent in smaller blocks.

Smarter? How?

Device can be smarter by configuring the slaves to send data on a change of state ( COS ) instead of all the time. Profibus DP sends all the data all the time but the Profibus DP's bus speed is MUCH faster and its packet efficiency is much higher.

are there any good articles that discusses about these standards?

I don't know now. I have the specifications and equipment necessary to implement all these protocols. I don't think you want to buy the specifications. They aren't light reading. The ProfiBus/Net guys can't write a clear specification.

 

[LadderLogic]

Does EtherCAT somehow fits into this discussion?

 

[Peter Nachtwey]

Yet another protocol

Does EtherCAT somehow fits into this discussion?

Is isochronous Ethernet required for general I/O as per the OP's needs? I don't think so.

 

[danieluy]

When a slave produces data on the network it goes to every other device unless you have a managed switch were the data can be configured to go to just the nodes that need the data.

ah.. yes... that is a good point... if Modbus will broadcast the message for all this will be a problem... but if Modbus is intelligent enough to embed the destination's IP into its packet then it shouldn't be a problem... hmm... gonna try this one out...

Has anybody tried this using DD-WRT firmware?

I/my customers have had good luck using Profibus to control over 100 axes of motion control.

WOW!... that surely speaks for the Profibus... and less points for Modbus.. gonna wait for the right project for us to try implement this on Modbus..

This mode is not useful for motion control where the command and the data must be sent at the same time. It would be a disaster to send a command with another command's data.

Why is this so? isn't the Command and the Data within the same packet? so it should arrive within the same packet.

Profibus DP can only send 64Words...
Modbus and Modbus/TCP..... MSTR block limits the transfers to 100 or 120 words... A AB MSG block can send 32768 words in one command. However, that data is actually sent in smaller blocks.

hmm.. in that case then Profibus=64 and Modbus=120 words... yes Modbus gets this one... yes the data should be sent in smaller blocks.. maybe because of the MaxMTU...

Device can be smarter by.... send data on a change of state ( COS ) instead of all the time. Profibus DP sends all the data

hmm... isnt sending the data's advantage is reliability over Dropped Packets or Errors?..

I don't think you want to buy the specifications. They aren't light reading. The ProfiBus/Net guys can't write a clear specification.

yeah... most impt parts are in the actual field.. and these can only come from the industry itself... anyways... at least this forum can help...

 

[Peter Nachtwey]

Why is this so? isn't the Command and the Data within the same packet? so it should arrive within the same packet.

If the data is 'consistent' then it all data will be sent and received at the same time. This can only happen with Profibus DP if the packets are 128 byte, 64 words or 32 dwords or less.

 

[GeoffC]

When a slave produces data on the network it goes to every other device unless you have a managed switch were the data can be configured to go to just the nodes that need the data

It was my belief that an unmanaged switch also achieves this.

Another point for any ethernet based system are the additional services provided at the lower level of the protocol stack. Examples being 'plug and play' of devices, faulty device replacement, network statistics, ftp file transfer, device address resolution (ARP), device address assignment (DNS and DHCP), CIP also provides a significant number of extra services. These are all provided as services, no extra effort required.
Not all of the ethernet systems support all of the above, but I am pretty sure profibus supports even less.
The benefit is being able to browse to a drive, plc i/o drop, transmitter, etc, and open it's own web page to read its network statistics, or read and write the device configuration, read its status (or even display those pages directly within a SCADA application). Using faulty device replacement means a device (drive) regularly updates the server with its current configuration, and if this drive fails and is replaced with a new drive that saved configuration will be automatically downloaded to the new drive.

 

[Peter Nachtwey]

It was my belief that an unmanaged switch also achieves this.

For Modbus/TCP it does. For the multicast of Ethernet/IP it doesn't.

Another point for any Ethernet based system are the additional services provided at the lower level of the protocol stack. Examples being 'plug and play' of devices, faulty device replacement, network statistics, ftp file transfer, device address resolution (ARP), device address assignment (DNS and DHCP), CIP also provides a significant number of extra services. These are all provided as services, no extra effort required.
Not all of the Ethernet systems support all of the above, but I am pretty sure profibus supports even less.

Profibus DP doesn't need to because it only supports level 2 which is equivalent to sending raw Ethernet packets like the Host Engineering Protocol that AD uses. However, that also is a limitation too. There is no messaging. Just packets. This is a limitation when my customers want to download 8K dwords of graphing data.