Compact Logix l35e ip address issues

Hello All,
I have an issues with Compact Logix l35e's ip address failing. I am able to set the address and connect to the processor with a Redlion HMI and RSLogic 5000. Everything is fine for days, then the processor can't be pinged, the HMI will not communicate with it. To regain communications, all i have to do is power down and restart, then everythings fine for about two weeks. I have set static ip address, turned off boot-p, dhcp, dns and auto speed. I thought the PLC was bad, so I changed it, same issue. My AB rep is stomped. Any ideas?
By the way the rev is 20.12

Any other equipment on the same network as the PLC that could have a duplicate IP?

I have checked, from time to time but have not changed to another address to see if the problem presist.

I have changed the PLC'S address to another that shows no activity to see if that helps. Still scanning the old address for activity from something else, nothing yet. This may take sometime to prove ya or na. Thanks for the suggestion.

There just seems to be more issue with CompactLogix for some reason. A quick search turned up 5 or 6 simiiar threads. here's one:

http://www.plctalk.net/qanda/showthread.php?t=65535

- have you tried connecting through the serial port and take a look at the Ethernet setting?

Leave auto negotiation turned on. And Auto speed. NEVER disable those options.

rdrast said:

Leave auto negotiation turned on. And Auto speed. NEVER disable those options.

Click to expand...

Others agree with you, of course.

http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-should-be-set/

But, never is a bit strong.

I have been on site(s) where the end user has demanded that all devices attached to his internal infrastructure be FIXED.

It all works, but, of course, the end user is maintaining the infrastructure.

If the never position were taken with this customer, lots of work would be lost. But, its their money, and their network, and their risk...

How many things are "talking" to your PLC? It could be that the max number of connections has been reached, and by rebooting it you force all of those connections to drop - giving you a chance to get back in before they all get used up again.

Try this:

http://www.plctalk.net/qanda/showthread.php?t=74607&page=3

In the case of a customer like that, and I had exactly one, the simple answer is "No Guarantee, on performance or any attached equipment. Startup and an following issues will be billed at standard service rates".

In retrospect, that made the company a lot of money over the cost of the drive system.

I'll stick by my "Never" if it is something I'll ever have to work on. For that one edge case, where a device won't play nicely, I'll replace the device.

One cheap device set to fixed port control can seriously impair an entire network.

jdbrandt said:

Others agree with you, of course.

http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-should-be-set/

But, never is a bit strong.

I have been on site(s) where the end user has demanded that all devices attached to his internal infrastructure be FIXED.

It all works, but, of course, the end user is maintaining the infrastructure.

If the never position were taken with this customer, lots of work would be lost. But, its their money, and their network, and their risk...

Click to expand...

My initial guess here would also be that this is possibly a port speed/duplex mismatch.

For starters I would open a web browser and point it to your processor's IP address. Go to Diagnostics>Ethernet Statistics and look at Media Counters. See if you have any errors or can see any of them incrementing. Specifically Alignment, FCS or MAC Transmit Errors.

You have mentioned the PLC, HMI and your computer, but no mention of a switch? I assume there is one? If so, is it managed or unmanaged?

Is everything set to Autonegotiate for port speed and duplex, including the switch, if it is managed?

..........

A quick word on the "NEVER" and the "...One cheap device set to fixed port control can seriously impair an entire network."

In general, for more modern equipment that all support it, Autonegotiate should be set for port speed and duplex. This allows for optimal settings to be used. But some older devices do not support Autonegotiate and will use a fixed port speed and duplex. Some of these devices are also far from cheap.

One such example would be the older PLC5 processors which operate fixed at 10Mb half duplex. Many of these are in service for years and are not pulling down entire networks.

Why?

Let's say you want to communicate with a ControlLogix processor that supports Autonegotiate and also communicate with several other devices that also support Autonegotiate.

The key here is that both devices connected to one cable must match for port speed and duplex, not everything on the network. The switch you use in between acts as one end of the cable for all the devices connected to it. With a managed switch, each end device connected to a switch port must match the switch port only.

So the switch port for the PLC5 processor would be configured for 10Mb half duplex forced. The switch port for the ControlLogix processor would be configured for Autonegotiate, as would any of the other devices that support Autonegotiate.

The switch handles all of the traffic between the ports that are configured for different port speed and duplex. So if the only forced device is the PLC5, all other devices can still operate using the optimal setting of Autonegotiate without any impact on their communications. Any communications between the PLC5 and other devices will be slower because of the PLC5's inherently lower port speed and duplex, but this is just a performance factor. The network should be solid.

This is just one example, but there are many network configurations where there are a mixture of Autonegotiate and forced devices on the same networks or segments of networks and this is a perfectly valid setup.

There are of course also the "customer spec" cases where they want to force modality for all devices, but this can often be led by a misconception that forcing it higher is faster, which is not always the case.

For setups where all devices support Autonegotiate, I can understand your "NEVER" stance, but for those "other" setups where some or all do not support it, the "NEVER" stance cannot really be applied.

If you do not want to work on those types of setups, then that is of course your prerogative.

Regards,
George

I agree that "never" is a strong term, but he isn't that far off from wrong. If you need to fix it for one legacy device, its doable. I'm very careful to make it the exception, however, not the rule. In my experience, half duplex mismatches are a big #2 cause of Ethernet problems. End device to switch just causes that device to be slow, but switch to switch mismatches can create havoc.

The problem with a duplex mismatch between switches is that it shows itself with a myriad of symptoms. If the network has light traffic, it might only be "acting funny" sometimes; if ithas heavy traffic, you'll wonder why only a FEW of your PINGs get through.

I've seen it a lot where Network A was set up as fixed, Network B was set up (as it should be) for Automatic, and then when they are connected, neither engineer thought to check to see what the partner was expecting. It is amazing how hard it can be to convince someone with a half-functional system to make a change, even if it is one simple dropdown. If it isn't the first thing you check, you can lose a lot of time tracking down phantom problems.

Yes, but the point I'm trying to make here really is that those cases where port speed and duplex mismatching is causing issues lies squarely with the configuration not be set correctly and is not the fault of the fixed device by virtue of its very existence on the network. Once configured correctly you should have a stable network.

It is not the use of fixed port speed devices that causes problems here. It is the misuse of them.

Never suggests you should never use them because "they" cause issues. I am saying you can use them once you "configure" them correctly.

It is misconfiguration that causes the issues, not the devices themselves.

We can keep giving examples of problematic situations where port speed and duplex were mismatched between fixed devices and other devices, switches to switches, and everything in between. But again, the problems are related to misconfiguration and not the actual use of the fixed devices.

Regards,
George

If you observe a problem that I had on link above, you will see that I set all devices to auto negotiate, but PLC and switch failed to negotiate same duplex.

The point is I had to put fixed full duplex on both sides. Interesting thing is that PointIO adapters didn't like fixed duplex between them and switches so I had to put them both to auto negotiate.

Geospark said:

It is misconfiguration that causes the issues, not the devices themselves.

Click to expand...

Ah, yes, I missed your main point. Completely agree.