Preliminary Profinet Review

1 The Profinet driver code is big and bloated compared to Ethernet/IP. The Profinet driver is a big as all the other Ethernet drivers together. That includes Etherent/IP, FINS, Mitsubishi, Modbus TCP and our own DMCP.

2. Cyclic I/O should/could be fast. About as fast as Etherent/IP and perhaps a little faster. The cyclic I/O is done using raw Ethernet packets. This is very lean and mean which I like for I/O.

3. Acyclic messages are big and bloated. They use RPC or remote procedure calls so there is about 140 bytes of header before getting to the actual data. So far I haven't figured out if very large data requests ( >1536 ) are possible from one read or write.

4. It doesn't look like it is that much different from getting Profibus to work, but Profinet will be much more flexible than Profibus. I can see that the need for Profibus will go down a lot as Profinet grows in popularity.

5. Writing a Profinet driver is much more complicated than writing an Ethernet/IP driver. I know a lot of people thought Ethernet/IP was bad.

The jury is still out. I will update this as I get more info.

We have got our product communicating with a S7 using ProfiNet now using SFC14, SFC15 for I/O transfers and SFB52 and SFB53 for message transfers. The S7 seems to have a transfer limit of 63 32bit registers using SFC14 and SFC15. So far it looks like the SFB52 or SFB53 limit is the size of a DB.

I like the way SFC14 and SFC15 make ProfiNet I/O data transfer work much like ProfiBus I/O data transfers. This keeps the learning curve down and will mean there shouldn't be too many tech support calls when changing to ProfiNet. Having the ability to transfer an extra 31 registers will be a plus too. I wonder what happened so that 64 registers couldn't be transferred.

SFB52 and SFB53 aren't any faster than the T-blocks but they are a LOT easier to use.

So you went to the darkside

http://www.plctalk.net/qanda/showpost.php?p=330933&postcount=126

and see post 127

We had no option

JRW said:

So you went to the darkside

http://www.plctalk.net/qanda/showpost.php?p=330933&postcount=126

and see post 127

Click to expand...

I have a good memory but that wasn't a solution.

Customers wanted an Ethernet solution but one can not quikly implement a ProfiNet solution. I implemented the T-Block solution to provide a temporary solution but the customers didn't like the complexity and decided to stay with Profibus so that was a waste of time. Developing ProfiNet takes time ( many months ) even if you know what you are doing. Developing ProfiNet is much more costly than developing Ethernet/IP. Buying ready made solutions don't fit in product we have.

The S7 seems to have a transfer limit of 63 32bit registers using SFC14 and SFC15.

Click to expand...

That's enough to make me want it. I have not seen any advantage that Profinet had over Profibus until now. With a loaded up RMC150 32 is just not enough.

So far it looks like the SFB52 or SFB53 limit is the size of a DB.

Click to expand...

I'll have to look into these. Does it break it down into multiple read/write blocks? Does this work along with the SFC14 & 15 or is it one or the other?

CharlesM said:

Does it break it down into multiple read/write blocks? Does this work along with the SFC14 & 15 or is it one or the other?

Click to expand...

SFC14 and SFC15 are used for the ProfiNet I/O just like the Profibus I/O. The only difference is that one can transfer 63 words instead of 32.

SFB52 and SFB53 work more like Rockwell MSG blocks. The transfers are slower but they can be much longer. A long transfer is broken down into many sequential transfers but you don't see that. All you need to do is activate the block and wait for the done bit to become active. NO STL REQUIRED!!! Yippeee!

Subscribed.

I'm a big Peter fan.

[that didn't sound right]

Paul
Now that's scary.

Now if his controllers can do profinet peer to peer and control
I/O he might have something.


Jay