Ethernet switchs?

[JeffKiper 9]

I don't know the IT side of the switch managment so any pointer would be great. I am getting to retrofit 3 Powerflex drives, 1 MLX 1100, & 1 RSView 32 station on a small machine.All ethernet comms. I am going to need a switch to make things talk. I would prefer to manage it myself with out IT support. Any suggestions?

[Nathan 7]

You have to get more specific in terms of management features. From that description, any small Ethernet switch should work fine. Consider getting an "industrial" rated one if you're planning on putting it in a hot, wet, dusty, or otherwise nasty environment.

[JeffKiper 9]

I don't know what features are out there or what I need. I have used the small cheap NetGears that you can buy anywhere. I see the systems the pros build and they have used Hirscman ,N-Tron ect. (spelling ?) I see them using it so there must be a good reason to do so. I am trying to learn and understand why we would use a switch that is managed or a non-managed. I hate just being follower of the other monkeys.

[Nathan 7]

Lol - sorry. Great question! A lot of the features become important when you're dealing with internetworking, but don't matter much for a stand alone switch or even a few daisy chained switches. These are things like Spanning Tree Protocol (for interconnecting switches) and dealing with broadcast/multicast packets. The significant Layer 2 (Hardware or MAC address) switch feature is called VLAN support. For example, on a 48 port switch, you could separate the first 24 ports on one VLAN and the last on another. This would behave like 2 physically separate switches. This is more often done logically, to separate services that need it like VoIP phones or servers. Layer 3 switches are IP aware and function as you would think of a router. Other "management" features are a web based configuration and features like: only allowing certain devices to connect (MAC filtering), SNMP (monitoring of device/link health), and more technical tweaks. Often the management features are security related, or there for technical tweaks. You can do some very cool things on large networks, but many of those features are trivial in the case you provided.

[UMEE 0]

If you want a simple plug and play unmannaged switch Hirschmann does has a good line of industrial types I've used called "Spider". They also have a variety of industrial managed and unmanaged ones and are usually ready for din rail mount. http://hus.hirschmann.com/English/industri...iew/index.phtml

[Scada Tom 0]

Some managed switches (Hirshman) use Hirshman software, others (Nutron sp) don't. I have used the Hirsham spider unmanaged switches and they are simple and easy.

[controlsdude 3]

AB has a preferred partner with cisco, might want to look at their switches for manage switch.

[Ken Roach 194]

For the system you describe, a Managed switch would get you some diagnostics but is not required to make the system function correctly. The MicroLogix 1100 will be sending MSG instructions to the drives (a method which, by the way, I have always very strongly recommended against) and not using UDP Multicast traffic the way a ControlLogix-family controller would. Get something with a robust case and a decent power supply and don't worry about the management features. I like NTron 508 and Hirschmann Spider, but there are some other good DIN-rail mounted switches (including the A-B Stratix units) on the market for a little less money if you don't need the super-robust construction. What I tell my customers is "if you only want to think about this switch once, get an N-Tron".

[Nathan 7]

N-Tron - good to know a solid brand of switches. I'll take your word and pass it on. Ken - Could you describe that packet/protocol that the Micro sends to the drive? Also, I've run into configuration headaches getting UDP Multicast traffic to work reliably (No pun intended since UDP is an "unreliable" protocol). I've found that on a bigger/more distributed network you may find yourself messing messing with BGP tunnels, proxies, forwarders, and the like to get that working, whereas using TCP based messaging just seems to work without issue. Obviously, not an issue with a single switch connected to both drive and PLC. Do Control Logix PLCs support TCP based traffic to the drive? I'm pretty sure that's how I'm communicating with them in an RSLinx Ethernet driver.

[JeffKiper 9]

Ken why do you recommend against the ethernet to PowerFlex? We have talked about using a CompactLogix 32E or 35E to control this system. Would that make any difference in the Comms? This may be a repeat of Nathan's question but he is way over my head. Sorry Nathan I am just a bit banger for now, I am learning though. If you keep posting what is happening in basic terms I may just learn something.

[Ken Roach 194]

I will clarify: I do not recommend using EtherNet/IP to control drives from MicroLogix 1100 or SLC-5/05 controllers. With CompactLogix and ControlLogix, they are built to be I/O device controllers on EtherNet/IP from the start. Connections, identities, sizes, retries, demotions, reconnections, errors.... everything is done behind the scenes by the Logix and the EtherNet/IP module. Fast, reliable, easy. SLC-5/05 and MicroLogix 1100 controllers only support the unscheduled non-I/O kind of messaging that is part of the EtherNet/IP protocol. Everything that is done in RSLogix 5000 by selecting a drive in the I/O tree you have to do manually with MSG instructions in RSLogix 500. Mess up a MSG instruction, and your error can cascade down the several drives your logic is controlling. Start loading up the controller with HMI traffic, maybe your control reaction time increases. You would never, ever want to use a MicroLogix or SLC-5/05 to control drives over Ethernet that had critical stop/start/speed change timing. In fact, the drives only work as controlled devices because they happen to have a "PCCC Object" that lets you address them like SLC data tables. They aren't using the actual I/O protocol of EtherNet/IP. Now, I know that some A-B salesmen and demos and powerpoint slideshows will show this architecture. But that doesn't make it a good idea. Every time I've had a customer implement a system like this, I have had to write their MSG logic for them. I send it off with my fingers crossed, hoping that they don't fat-finger a control block or add something later to the system then call me saying "that control network of yours flooded Newark with raw sewage". Note how it becomes "my network" when it gets installed against my recommendation and then doesn't work. I generally relent and agree with my customer that they will at least hardwire the Stop function, then use the example code that I write up for them. I think those examples are in the Downloads section of this site. As an aside: for inexpensive, robust, fast control of motor starters and drives, DeviceNet is the protocol you want to use. It takes a little more effort to set up, but it is solid and reliable forever and ever if you take even a grain of diligence installing it. When the MicroLogix 1400 comes out, I'm still going to strongly recommend using DeviceNet with it. Edited 31 May 2008 by Ken Roach

[JeffKiper 9]

So Ken let me make sure I understand you. If I read it correctly You would use the 5000 Family to do the control of drives. You also recommend using Devicenet. I hope I did not mis read your post. If you where to build a system using the MLX, SLC ,or CPL and drives what would you use? Our plant is a PLC5 and Baldor drive plant. The drives get a speed reference from an OFE 4~20mA. We have within the last 2 weeks started a 5 year plan for controls upgrades. PLC and Drives to be replaced. I like PowerFlex because they communicate to AB easy. Any pointer you guys have would be great.

[paulengr 44]

The advantage of DeviceNet and Ethernet/IP (device version) isn't in something fancy about the communications protocols in and of themselves. It's how they handle communication failures. In the event of a failure, there is a built-in pre-determined "fail safe"...normally, the drive will stop on communication failure. This cannot be achieved with explicit MSG packets because there's no synchronization protocol as such present. This is the most fundamental difference between the "old way" (4-20mA + discrete outputs) and the "new way" (Ethernet communication). There are easy ways to solve this, but you've got to engineer it into your design ahead of time, not when the machine tears itself apart or hurts someone 6 months down the road. In addition, implicit Ethernet/IP (and DeviceNet for that matter) set up a regular polling rate, and will even do some monitoring and calculations on the side as well to account for time delays in communication. You simply don't get any of that with explicit messaging. This may cause the drive to respond erraticly because you don't have precise control over timing. This is the old "nondeterministic" argument. There are plenty of horror stories about the idea that Ethernet is "nondeterministic". In reality, the whole deterministic/nondeterministic argument is usually hogwash because running into those barriers requires you to saturate your LAN with packets. There are some big problems which appear well before you get to that point. There are some fundamental problems. If you have a device spamming packets on your network (this does happen occasionally with hardware/ASIC failures), it can trivially saturate the 1000-1500 packet/second capability of Ethernet/IP modules and cause them to lock up. If you aren't extremely careful with how you do things, you can cause the same kind of thing just by doing uploads/downloads to PLC's. And hooking up your little subnet to the rest of the network can cause similar problems with broadcast traffic if you use cheap <$500 unmanaged ("dumb") switches. All of these issues can be completely eradicated with a managed switch but the price can be prohibitive. Managed switches start out with price tags closer to $1000 each. In addition to the catastrophic things, the theory behind the "nondeterministic" argument is that there are no gaurantees that a packet will arrive in a timely manner even with implicit Ethernet/IP (the CLX producer/consumer version). A packet could get delayed by a couple hundred milliseconds waiting to get retransmitted in the event that it gets lost. CLX I/O puts some limits on how much of a problem this can be and the fact that you almost have to install at least a few managed switches to keep the I/O traffic from flooding the rest of your network keeps the problem in check. But CLX I/O by itself doesn't avoid the catastrophic failure problem I described above. So you are forced to buy managed switches if you go 100% Ethernet/IP with no backup (drive enable bit) system. So...there are definite opportunities for things in the Ethernet world to go very, very wrong. You can fix every one of these problems. Just switching to CLX and running implicit Ethernet/IP isn't necessarily a 100% solution by itself. Just be aware that these problems exist. You can do everything you want to do with MSG packets on a Micrologix platform. Where the concept falls down is in terms of safety. A drive will continue to execute whatever the last valid packet you sent it is. This can be a disaster depending on your process if you lose communication while the motor is running and there's effectively no easy way to shut it down from PLC (or human) control. The same thing could be said of 4-20mA control except that in that situation, if you lose communication, in almost all cases, the effect is that the drive stops (gets a "zero speed" command). The simple solution is to make sure that you have a discrete RUN enable input wired up to an output on your PLC. Then if something goes wrong and you drop the output, it shuts down the drive, assuming this abrupt stop is the safe way to do things. In addition, you'll need to add extra code around the MSG block to monitor the status of the block, set the retry count down to 0 (so that you have explicit control over retries), and probably set the timeout limit on retries/error out to something much more reasonable. All this extra code has to be written carefully with an eye towards safety because this is your ONLY way out if something goes wrong. Your risk assessment may spell out something more complicated but this is the basic requirement for a PLC-controlled system. This gives you explicit Ethernet/IP control over your drives (your intended solution) with a failsafe just in case communication with the drive fails. If the drive is in a process plant running a pump or fan or something like that, I wouldn't even get concerned. If you're using it to drive some sort of machinery in a discrete manufacturing plant, then that's when I'd get nervous. In the process plants I've worked in, putting in the extra code to drop the enable bit on the drive in the event of a communication loss is as far as I would go because the consequence of a loss of drive communication means that there might be a big mess to clean up (only after several minutes of a drive losing communication). On the other hand I now work in a discrete manufacturing plant and the consequence of a bug in the system can mean that objects go flying or you can get an explosion. In almost all situations, I'd be putting in a layer of safety relays in to kill acuators when something goes wrong as a minimum. As to the five year plan, don't stop where you started. AB is definitely making it very clear that their intention is to phase out PLC-5 and SLC as quickly as possible, while making heavy profits on doing so. Don't assume that AB is the only game in town. They are going to force you to buy all new hardware and software over time (leaving the PLC-5 platform). There are many more choices to be made. For instance, softplc is essentially a software based knockoff of the PLC-5 that supports the same instruction set, I/O, etc., at a much better price point. Second, the Micrologix is not a bad processor line. But it's kind of like what most people would use an Omron PLC for. It's great if you need "smart I/O" or "smart relays". But you are really pushing things to think of it as anything more than a small PLC. The moment you need remote I/O (you already do), motion control (more than just gross speed control), heavy-duty math, etc., you are going to be leaning closer to either a CompactLogix or ControlLogix PLC. Third, if you do things carefully, expect to replace about every 3-5 PLC-5's with a single ControlLogix processor. At least that's what happens with most plants. The trouble with CLX is that the initial investment in spare parts, a PLC, Logix 5000 programming software, etc., sets you back close to $20,000 for most projects. A decent, new PLC-5 will set you back around $10,000 (PLC-5/XXE). So it's kind of hard to swallow the initial cost. Once you have the first one, then you are under $10,000 for each additional project beyond the first one and the total project cost will be well below the same thing if you had to do it with a PLC-5. Two years ago, I didn't hardly even see any mention of Ethernet I/O. At the last couple AB-sponsored trade shows, it was actually beginning to be hard to find a lot of stuff talking about Devicenet or Controlnet. They often get lumped in with the Remote I/O as "well, we still support the legacy stuff", although this is less true with Devicenet which still seems to have strong support. AB doesn't think they are "there" yet but they are moving that way quickly. For instance, they had ArmorBlock I/O modules with Ethernet/IP but those are not available for sale yet. They had a few of the Cisco switches but not the heavy hitters (that would compete directly with N-Tron & Hirschmann) available. But it is quite obvious based on all of the rest that AB believes that their marketing future is Ethernet/IP. Since I'm in the midst of this myself, here are my thoughts. First off, we looked at other PLC's and decided that there's no compelling reason to switch brands. Second, Ethernet/IP appears to be the future and since we frequently have processors with NO local I/O (all distributed), that will be our intended future as well, managed switches and all. AB doesn't hardly even talk about Modbus/TCP and makes it very difficult to use the existing industry standard so much as I'd like to, this appears to be something to stay away from. In the interim, the best I/O seems to be going with Flex I/O or Micrologix. With Flex I/O, you just have to change the communication adapter to change it over to Ethernet/IP. With Micrologix, well, $500 for a combination I/O card with a display, 10 inputs, 6 outputs, and a bunch of other options...show me where I can get into AB I/O at that price point with anything else. So I don't really use them as PLC's for the most part. They are more like "smart I/O". Edited 2 Jun 2008 by paulengr

[Ken Roach 194]

Very very well said, Paul ! I'd like to add some comments specific to this application. The principal reason that AC drives can be commanded by a MicroLogix 1100 or SLC-5/05 is that the drives support a special object called the "PCCC Register Object". You address the drive as though it was an SLC device on Ethernet, sending a command word to register N41:0 and a speed reference word to N41:1. PowerFlex drives with 20-COMM-E or 22-COMM-E adapters do have a command timeout value. If you are using the PCCC Register Object to run the drive, you must first write a nonzero value to the Command Timeout (addressed as N42:3). If that time elapses without a new command arriving across the network, the drive will execute its communication loss action. The technique of commanding an AC drive with a MicroLogix 1100 *works*, but I generally recommend against it because of the reasons Paul outlined; error handling, automatic connection establishment and detection, speed, and ease of coding. I agree with Paul about using a hardwired Stop signal to the drive, at the very least. The last few projects I helped users imlement this sort of thing, they were driving pumps and fans and other stuff that didn't have to react very fast to the controller's commands. If the application involves machine control, the Messaging approach isn't appropriate. For your little application, Jeff, I say go ahead with your design and use it as a learning opportunity for MicroLogix message programming. But for future projects, you'll have the advantage of understanding more about the architecture for a real EtherNet/IP I/O system.

[308guru 0]

I can't offer as much information as others already have, but I will recommend Hirschmann Spider switches. I've used them in two machines myself, and we have a bunch of others in operation. Plug, play, forget. http://hus.hirschmann.com/English/industri...iew/index.phtml I also noticed that Woodhead just came out with some switches. I really like all of their other products so they may be worth a look. http://www.woodhead.com/products/automation/switches/ Edited 2 Jun 2008 by mckeand13

[panic mode 246]

i was using Hirschmann ethernet switches on several machines some two years ago (Spider). At first I liked them a lot because of compact size, din-rail mount, 24V, price was right etc. Unfortunately our experience was horrible so we ended quickly switching to other brands. In our case Spiders were extremly sensitive. For each installed cable we had to buy at least ten. It didn't matter if cables were DIY or purchased or from same batch or not (we ended buying bunch of cables from different sources - same thing) and it certainly didn't matter if the LAN was just on the office desk with nothing powered from AC (two laptops running on batteries and 24V for switch was from pair of 6V batteries). All of the cables worked just fine on any other equipment. Replacing Spider with other brands cured all problems for us (we ended leaving in machines only some 10-12 of them, rest was returned). I hope this has changed but I'm not going to try them again. units I tried and never had issue with: Weidmuller, Phoenix Contact, Advantec (Adam 6510, 6520), Siemens, Volution, Cisco, D-Link, SysLink, NetGear, etc.

[Bill Linne 0]

Nobody likes a smart booty, but this fruit is hanging too low not to pick! Could the problem have been the 12V that a pair of 6V batteries would supply?

[panic mode 246]

thanks, you are right, it was the 12V sealed batteries from busted UPSs, we use them for I/O checks etc. when things are locked out i'm sorry about type. i must say i'm getting more and more busy so it it's increasingly hard to post something with more than 4 words when multitasking... (or was it 8 words..?). one thing that happens to me quite often lately is that i start replying, get distracted and finaly post few hours later.

[JeffKiper 9]

You guys are great!!! I asked a simple (so I thought) question on what managed switch to use and got a full bown explanation of how it work. We have changed the 1100 to a CompactLogix L35E. We started writing standards for our systems , less then 40 points of I/O MLX 1100, Less that 200 points L35E, we haven't set a BIG GUN yet. I know that is another thread. Our IT is whinning like my 2 year old for another cookie about us managing our own switches. They want to manage and OWN all the switches in our networks. The top dog in IT said all devices will terminate into their switches. His idea is that if the cables are terminated in their switch they will be able to see all the devices on the network. My argument is if any of the 10 or so main switches fails my entireplant is down. If we have a small group of machines that tie to a local switch then theirs even if the main switch dies I can still run I just can't see it from my office. So we are still making a money I just have to walk down the stairs and out to the black hole if we have a problem. How do you guys handle stuff like this or is this just me whinning?

[paulengr 44]

Very, VERY carefully. You just introduced another problem. You went straight from discussing isolated networks to integrated ones. The moment you tie both networks together, this becomes an issue. First off, you now need a managed switch because it's NOT an isolated network. You are tying it into the general network. You MUST protect your subnet from both internal faults AND external ones. And you just introduced the entire wild LAN to your network. Remember that little 1000-1500 packets/second problem? What happens if IT screws up what they are doing and starts a packet storm where your equipment gets swamped with packets? For that matter, what happens if the IT guy that doesn't have a clue about control networks (obviously based on their response) tries to swamp you with ping packets running some sort of bandwidth/speed test? What happens if they decide to reconfigure the switches in the middle of the day since "the users will never notice"? What happens if some PC gets a bug in it and starts flooding the network with broadcast packets even if their switches are programmed to eventually kill the broadcast storm? Any time I run into IT guys that think that they are the only ones who can control settings on switches (among other things), it is also painfully clear just how clueless they are. Control network traffic does not fall into any of the traffic patterns that they are used to. In addition, most IT departments really don't recognize how important 24/7 operation truly is. You have two choices about how to fix this. First, if your CLX processor has 2 Ethernet ports (this is standard on ControlLogix Ethernet cards; I'm not sure about CompactLogix), then put one port on the LAN and the other port on your device network. Do NOT connect the two networks. There are a few functions that you need to make a direct connection for. On everything else, Logix 5000 is smart enough to route messages across the ControlLogix backplane to the devices. An example of where this doesn't work is that it can't remotely program Panelview Plus's. The advantage of the isolated network is simplicity. No need to worry about external network influences on your network, or vice versa, since there aren't any. Just to make sure that nothing goes wrong, when you assign IP addresses, use a nonroutable IP address that is DIFFERENT from the plant network. You can use 192.168.x.x, or 10.x.x.x addresses since those are all nonroutable. Since it won't match the plant network if anything goes wrong, the packets will get routed to the router. Since they are nonroutable, the packets will be destroyed and never interact with the plant network in the first place. Effectively the devices will be invisible to anything except using the CLX bridge in terms of routing packets. If you do this, be aware that Multicast traffic defaults to acting like broadcast traffic so it can have a tendency to flood your network. To stop this, at least one switch must be an IGMP queryer. Any switch that you want to route multicast traffic properly (without flooding) must have IGMP snoop capability. The querying switches are all managed switches. There are some IGMP snoop capable switches (the Hirschmann Spiders, some N-Tron switches, and the Cisco/AB branded Stratix switches, among others). In addition if you don't be careful to make sure that IGMP capabilities are set up, your equipment is going to be flooding the rest of the network with packets and can possibly cause some serious problems. The passive (snooping) switches won't do anything without an IGMP query so eventually you'll have to add at least one managed switch. Broadcast Ethernet/IP traffic isn't a problem on a relatively small network, so if you are taking the isolated network approach, it is often OK with small amounts of devices are relatively long RPI's. It is also theoretically at least OK if you set up all your IO on unicasted packets, which is available at least in Rev 16. If you set this up then the only broadcast traffic you will get will be the usual IGMP "ping" and auto-mapping packets that software like RS-Linx uses to auto-detect Ethernet/IP devices. If you take the integrated approach, then you absolutely need a good quality managed switch. I have successfully used Cisco and Hirschmann although I'm partial to Hirschmann's railswitch series since it's a true industrial switch. Cisco is office grade. I have friends who have used N-Tron and Sixnet. Lately this class of switch has been showing up everywhere so some of the others might be good too. One advantage of the Hirschmann switch over some of the others is that you can store and restore all the settings with a "thumb-drive" type gadget, making them easy for electricians to replace without programming skills. With this in mind, here are some additional considerations: 1. Set up IGMP snooping and IGMP querying after a timeout. This way if IT's IGMP manager (usually the router) gets disconnected, after a timeout, the managed switch will take over the responsibility and keep your Ethernet/IP traffic from eating itself in broadcast storms. 2. Rate limit your ports according to the requirements of the equipment. 3. Set up your IO network in a separate VLAN. This effectively eliminates all broadcast traffic from entering your device network. 4. Set up your PLC on an overlapping VLAN (both plant network and IO network). This allows you to access the PLC. 5. Set up QoS so that IO packets always take top priority over all other packets. 6. If you do both steps 3 & 5, then you won't need step 4 as such. Use the VLAN settings within your subnet as a means of identifying internal vs. external traffic. Then prioritize the traffic. At this point you can make the subnet appear as a normal network with a normal VLAN number externally (which eliminates any sort of coordination with the external network) but internally allows you to carefully rate limit traffic to your devices and the PLC. 7. Consider setting up your own DHCP system. This can be done with the switch using DHCP agent mode. The switch will watch for DHCP traffic and then route it directly to your DHCP servers, bypassing the normal ones. You must have a DHCP server that supports Option 82. Microsoft Windows built in DHCP server does not do this. You can then assign IP addresses based on the switch identity (use something other than MAC address since this allows the switch to be interchanged, too), and by port. Then as long as your electricians ALWAYS plug the devices into the same ports (port swapping is not allowed), the devices will automatically assume the correct identity every time. You will have a true "configuration-free" system where there are no settings or programming required to swap devices. If you do this, make sure to give the switch at least 3 DHCP servers. Two are yours (primary and backup) and the third is the original IT one. In addition, set up your DHCP servers to ignore any devices which are not in the lists that they already have. That way they won't interfere with any normal DHCP traffic. 8. Plan for the future. Eventually you will want to move onto your own isolated network and put a firewall in between your network and the IT one. This will happen sooner than you think. I did it because then I could put redundant links in so that if a fiber got destroyed, the control network would continue operating, after fighting IT for 6 months on this. In the middle of rolling out the control network, suddenly IT got the bright idea to do the same thing! 9. Don't forget that you and IT are going to have to agree on an IP addressing scheme as a MINIMUM and that you can't be beholden to then 100% to assign IP addresses every time you need one (what happens in the middle of the night when you need to troubleshoot a problem?). The best approach I've found is to set up the controls equipment on a subnet and for you to manage it. For instance, all of our plants are 10.x.y.y where x is the plant number. Our local IT guy agreed that 10.3.3.x is for controls which gives me about 250 devices worth of space. Another approach could be 10.x.y.z where x is the plant number, y is your "PLC number", and z is the freely assigned number and you can have about 250 IP addresses per PLC. The only way around this is if you start assigning nonroutable, foreign addresses, as I suggested earlier. But then you will need to deal with the issue of routing and routers.