Hirschmann Switch + 22COMM-E = No Communication

Hey all – just wanted to share something I ran across during a start-up I have been working on for the last few days. I did some searching but haven’t found any reference to this so I thought I would put it up here in case somebody else is having the same problem.

I have a machine-based Ethernet network for a Logix5000 system which incorporates 4 managed switches (2 N-Tron and 2 Hirschmann), 2 CompactLogix processors, 5 remote I/O racks, 5 Powerflex 70 drives, 2 Powerflex 40P drives, and 1 SMC Softstart. As of noon yesterday, everything was communicating nicely and working properly with the exception of one of the Powerflex 40P drives – we could not get it to communicate on the network.

We tried all the usual suspects – changed CAT5 cables, swapped ports on the switch, replaced the 22COMM-E card with a known-good card; replaced the drive with another known-good drive; called AB Tech Support; attempted to find/modify the Hirschmann managed switch configuration – none of these helped. Finally, the only thing left was the managed switch (which, incidentally, was communicating nicely with all the other devices connected to it – 4 Powerflex 70 drives with 20COMM-E cards and 1 remote I/O rack), so we created an ran a long CAT5 cable from one of the other switches (an N-Tron) and the drive started communicating. So now we knew the problem was somewhere within the switch. Luckily I happen to have another, larger Hirschmann switch in my office that was destined for another project, so I swapped it in where the failed switch was and, once again, communications were successful.

Now here is where it gets interesting: This morning, it occurred to me that I have a second Hirschmann switch – identical to the first “failed” switch – working without issue in one of the other cabinets on the same machine. It, however, does not have any drives attached to it at all. So I took it out, put it in place of the first switch and saw the same communications failure with the same 22COMM-E card. Swapping back to the larger switch again restored communications. While I haven’t contacted Belden/Hirschmann yet, it seems there is a problem with this particular switch style.

The switch that seems to have the problem is the Hirschmann - RS20-0800T1T1SDAEE - Rail Managed 8 Port Switch.

FYI – the larger switch that does communicate is exactly the same part number except “-08” is replaced with “-16” for a 16 Port switch.


Steve

Please post what you find out. I will be very surprised if there is some kind of low-level Ethernet incompatibility between these two products.

About five years ago I worked on a system that used eighteen Hirschmann RS20 eight-port switches in a HiperRing arrangement with about 36 PowerFlex 40's, 28 PowerFlex 70's, and 20 FLEX adapters as well as PanelViews and other devices on the network. At the time we figured it was the largest single-CPU EtherNet/IP network ever installed; the 1756-L63 had three -ENBT modules to keep up with all the traffic.

Most of our challenges on that system came from configuration and performance of the HiperRing and the performance of the 22-COMM-E, but they definitely did work together. I came in after the network had been designed and installed so I didn't have a role in the selection or architecture.

Of course we're talking about the versions available five years ago, so it's not directly relevant.

I presume that "could not communicate" means no PING, no HTTP, and no RSLinx browse as well as no I/O connection. Did you get good LINK lights, or speed/duplex lights ?

Actually, in RSLinx, I could see the 22COMM card via the switch and I was even able to update the firmware. The problem presented itself as a non-communications with the processor (warning symbol when looking at the I/O configuration and alternating "connecting - fault" message) and the lights on the front of the drive would not stay on as they do when communications are established.

Sounds to me like a switch configuration issue. I run a whole network with Hirschmann RS-30 switches and have seen a similier issue. Here are a few things to check

1. Make sure that spanning tree is truned off if you are not set up that way. Some time back they changed that so be on by default. I run a Hyper ring so spanning tree causes issues.

2. Turn on IGMP, protocol 2 with kmown multicast to regestered ports and unknown to query ports.

3. Check on your main screen or port configuration screen to see if anything is showing up as 100base half duplex. This is caused by auto negotiation truned off in the PLC and set on in the switched. This can crash the network.

4. Go under reports and open the html error log and look for something like "work around reset".

5. You can also set up vlans to seperate out traffic like drives from remote rack and so on.

It sounds more like network collisions then anything and the switches are shutting down.

Kevin

If you would can, copy the log files and post it so I can take a look and see if anything rings a bell.

The attached .zip file contains the event log and system information I was able to pull off of the original switch where I was seeing the problem. That switch is currently operating in a different location where there is no drive attached. If necessary, I can re-install the switch in its original location and capture the data again, but that will probably have to wait till tomorrow.

Let me know if you see anything. It looks like all the things you pointed out as possible problems are as they should be.

Steve

Look at line 37 of the event log and you will see to "Check Duplex". the code under that is 0000000006. This is saying that there is a issue with the duplex setting between the switch port and what it is connected to. If you look at port 6 on the system information you will see 100/half. This is part of your problem. What is on the other end of port 6? On the system overview page on the switch, all the ports that are on should look the same except if you are running old 10base half equipment. It should be a green circle with a green dotted line around it. If the green circle has a line throught it that means half duplex. There are alot of peoeple that will turn off auto negotiation off but in general I leave it on and have not had any issues. Check the settings on the Comm-e card if that is what is plugged into port 6 and set it to auto negotiate and reset the drive.

If there are reasons that you want to run with a forced speed and duplex you can turn off auto negotiate off in the switch this will work as well. The key is to have ports and devices match. The reason I run with Auo negotiate on is because if I move cables around and don't get it back in the correct port you can end up with the same problem. It will also cause a problem if you connect a PC to a port that has a forced speed and duplex.

Also, if you are running hyper ring, make sure that you only have one ring manager.

I have always intended on using Auto Negotiate for the reasons you mention - no reason not to and, no, this is not a hyper ring - just a simple star system.

I have heard of issues in the past with auto negotiate with some AB products. Not sure of what the root causes were but they were able to correct issues by turning it off. I have worked on several networks that forced speed and duplex and they worked fine. But all the devices matched.

Kevin

Just to be sure, I tried forced speeds and duplex settings - all available - and that didn't help either, at least not for this problem.

What is connected to port 6? You need to get the speed mismatch corrected to stop the collisions that will shut the switch down or clog the network. Can you post screen shots of the port config in the switch and device port settings in RSLogix?

Ok. I re-attached one of the original 8-port switches back into position (the 22COMM-E card still does not make connection), cleared its log files, did a cold restart and then did a switch dump. I have attached it for your viewing pleasure.

Let me know what you see.

I am out right now and my android will not download the file. Can you do a screen shot of the comm card port settings in RSLogix from the project tree?

I would try to mirror the port connected to the 22-COMM-E and capture that traffic with Wireshark.

I'm pleased to see that my presumptions were incorrect and that you do have some network connectivity, just not a cyclic I/O connection.

My guess is that there is something going wrong with multicast management, using IGMP Snooping and Querying. I can't explain why it seems to happen to just this one drive on this one switch, though.

With the I/O connection cycling between Connecting and Faulted, what we need to figure out is if the connection is failing during establishment or after establishment. Establishment is done using ordinary TCP connections, while I/O is done with UDP multicast .

Just to take a step back: the only device that wouldn't connect is one of the two PowerFlex 40P drives, right ?

Is there a chance that you have the PowerFlex 40P in both of the CompactLogix I/O trees, thus generating an ownership conflict ?