QUOTE(Corben @ Nov 26 2008, 06:07 PM) [snapback]76273[/snapback]
First of all, thanks everybody for all these answers i appreciate.
Third of all, could be good to analyse the existing traffic i'm agree with you.
Someone told me that the maximum numbers of modules possible on ethernet/ip network is 128? don't know if it's true?
Can we use RSlinx like sniffer to analyse traffic? Is it a good tool to do that? If not what kind of tool can i use?
As to 128 devices: False. You could run into a limitation of IP addresses but this depends on how your network mask is programmed. If your mask is 255.255.255.254, then you can only handle 2 IP addresses on the local network.
As to traffic analysis, the term you want to know is "wireshark". This is free. It is just as good or better than the commercial ones. The best way to use it is to have two Ethernet ports on your PC. Plug one port on your PC into a spare port on the switch attached to the PLC. The other port is to maintain communication with the rest of the plant. Go into the switch configuration and set up port mirroring so that the extra port on your PC sees the same traffic that the PLC sees. Then boot up wire shark, point it at that port, and start sniffing away.
There is broadcast traffic happening all the time on Ethernet, some intended for the PLC or IO, and some not. As long as the amount of broadcast traffic is at a minimum, all is well. But just for a minute, imagine some cheap $10 Ethernet card in an office PC that faults for some reason and starts continuously generating broadcast packets as fast as it can go (at 100 Mbps). What will happen to your IO network when this stream of garbage hits? What if the failed card is actually one of your IO devices? What happens when a fork truck hits a conduit and cuts the Ethernet connection between the local router and your IO network once IGMP starts going through the usual timeouts and everything turns into broadcast-only mode? What happens when one of your switches doesn't know how to do multicasting and starts spewing Ethernet/IP packets all over the entire plant?
My recommendations are different from AB. Rockwell is taking their cues from Cisco, and Cisco promotes a bunch of things that I disagree with. Especially when they were in front of an audience of about 50 people at a Rockwell automation fair and when asked lots of questions about VLAN's, they mostly stammered and tried to avoid the issue since they didn't understand what they were talking about.
You need 4 things to prevent problems with Ethernet IO:
1. You need a local IGMP querier (this is available in many industrial managed Ethernet switches). You program this querier to take over in the event that the router connection is severed. If you don't and contact is broken, eventually all your IO traffic will flood the network including overloading itself.
2. You need to bandwidth limit traffic to each of your IO devices to whatever maximum bandwidth the devices can handle (typically 1000-1500 packets per second for AENT's but it is higher for ENBT's). The Ethernet chips themselves can easily handle raw 100 Mbps bandwidth. The low power processors in the cards though is another story.
3. You need to set up traffic prioritization so that IO traffic takes priority over other general traffic. This can be done with outright priority settings, a separate physical IO network, or (although it adds a lot of extra complication) VLAN's. The purpose here is to gaurantee that even in the event of a flood, your IO can still get enough throughput to be largely unaffected. If you can, try to avoid VLAN's as they are not the panacea that people promote them to be, and they add a lot of complication to your system very quickly.
4. You need to have IGMP snooping on all switches involved. You can mix managed and unmanaged switches so long as you have this and managed switches at the end points (and at least one capable of IGMP querying). Having all managed switches is nice but expensive and not necessary. If you don't do this, then each switch without IGMP querying will leak out your multicast traffic as broadcast packets on all ports. Harmless to the IO (considering items 1-3), but adds to the network load everywhere else on all devices in your network up until it reaches another managed or IGMP-aware switch where it is contained. If nothing else, Panelview Plus is slow enough. Why contribute to it?
If you do all this, then you will have a very well armored and managed network with little to no trouble ever with your networked IO. If you miss any of these 4 items, it is possible for IO traffic to leak out into the rest of the network causing trouble, and vice versa.
