Micrologix scan times - What's "normal"?

Greetings all,

I'm trying to track down an issue with a Micrologix 1100 that randomly drops off the network. I have swapped Ethernet cables, the switch it plugs into, and even the PLC itself to no avail.

We are using Wonderware for our HMI and the sys$status function in the DAserver to monitor comms. When I get the alarm, I cannot ping the PLC. Occasionally it will clear itself, but otherwise it's a power cycle or unplug the Ethernet cable for a few seconds. There are no fault or error leds on the PLC. During this outage, obviously, I cannot connect to it via RSLogix to have a look.

The only thing I can think of is the PLC gets so busy doing its calculations(it's part of a chemical injection system)and messaging to two 1400's, that it locks up the Ethernet communications. The last scan value(S:35) is hovering around 60-70. The maximum(S:22) currently shows 114. The 1400's are showing in the high 80's for their S:35 value and also approx. 100 for S:22.

We had an outside vendor design and build the system and unfortunately, he did a pretty good job of keeping me out of the loop. I had to trust his expertise, but I'm wondering if that was a mistake.

The old systems was running on a PLC5, but it was decided to move off of that device as it was getting a little long in the tooth.

I am wide open for advice/suggestions. Thanks for any ideas!!

-Jim

Those scan times are very high compared to what I have experienced with the newer Micrologix (not including the lowly 1000).

Still, though, I would tend to think your issues are due to some problem with the network/port configurations than the scan time itself.

Can you ensure that the PLC is using full duplex 100mb?

It's currently set to Auto Negotiate.

FYI: I found two running micrologix controllers I could connect to (in our sister plant) to look at real actual scan times.

We have a 1400 running about 2.1ms peak with 100ms watchdog and a typical scan time of about 1ms.
We also have a 1100 running at about 2.4ms peak, 100ms watchdog and a typical scan time of about 1.2 ms.

Neither of these controllers is doing a whole heckuva lot, although they each have a handful of messages.

Is this done?
http://forums.mrplc.com/index.php?app=core&module=attach&section=attach&attach_id=3478

jcreid said:

It's currently set to Auto Negotiate.

Click to expand...

Are you seeing that from a switch? It's possible for the setting to be Auto, but the actual negotiation to settle for something different.

I suggest you use a browser to connect to the IP address of each controller, navigate to the network diagnostics page(s) and make sure the port duplex shows up as full there (on the Diagnostic Overview tab), and also examine the diagnostic counters there for more leads.

Here's a couple screen shots from the 1100 in question:

Looks pretty normal except for those CRC errors. Every time I have had any CRC errors we later end up finding bad media somewhere (actually it usually finds us...). Based on those screen shots, you are not running out of connections, which is another thing that occasionally has bitten me.

Perhaps that's stale data from long ago, but if those errors continue to accrue, I think you have a cable or termination that might be related to your issues.

The advice Sergei points out is also very good. I would advise that you set those CIP options as recommended. This should only affect connections to PCs where RSLinx is involved, but this may include those that are giving you fits.

Thanks for all the suggestions. I fixed the settings in RSLinx. I think I will try locking the settings down to 100/Full instead of Auto, then clear the counters and let it cook for awhile.

I'll keep all of you posted.
-Jim

You're absolutely right, Okie. I waffled before hitting return, then hit return anyway. The comment has been deleted.

Is it even possible to clear the network counters? In my quick search, I'm not finding anything...

Has it always been a problem or a newly acquired talent . We changed over to paperless recorders , but then the Melbourne office needed to login in and take a peek at production data .
And then the problem started it acquired this type of operation , over time it started to go off line or go to sleep , and not being an IT expert , unplugging the Ethernet cable was a quick fix .
But in your case had it been a problem from the start , and i am only assuming that the original Ethernet cables were used and there were no new cables introduced .
And there weren't new device installed that could have caused any notable interference on the network.
And that is this specific to this set up only , .
I cant say if your new system and program will handle any manner of interruption and or if there is even an alarm that would tell you what was going on any way , and when you say off line i assume that you haven't lost the comms to the server but only to the node that maintains your PLC . The ip address along with any interruption’s and the monitoring of them as a system event including time outs , how well will the system restore such an event .
And can the system go into a holding pattern while the comms are being restored .
There are a million questions i would have no hope of ever answering , and is this plc part of a broad cast or distributed plc system .
I only hope that I have not confused the situation and have not opened up too many questions that might need better answers , look good luck with you problems random problem's are often exhausting by nature , but never the less persistence always pays off cheers:book:

jcreid said:

Is it even possible to clear the network counters? In my quick search, I'm not finding anything...

Click to expand...

Unfortunately, with the Micrologix, you must roll yer own or power cycle it.

With the Modular SLC, you must assign a diagnostic file in order to have access to counters at all, but that gives you the advantage of being able to write to that file programmatically, and/or view/reset them them with the handy, dandy viewer found built into RSLogix500 in the project tree under channel diagnostics.

The PLC must sense we're after it: another comm failure last night. We have the injection on manual so a failure won't throw us a curve ball for the time being.

With the Ethernet speed locked at 100 Full, I'm now seeing even MORE CRC errors. The other two 1400's show NO CRC errors and they are plugged into the same switch.

I think I'd better dig deeper into the Ethernet cabling and see what's going on. I've been looking for a good excuse to buy a decent cable tester anyway.

Blueeyed:
The problem has existed since the get-go. No new devices or programming changes have been installed. There's been no rhyme or reason to the comm failures. It can go for months with no errors, but now this week, it's been almost every night. Callouts generate excess overtime and then management wants to know what's going on. I've inherited this system, so I want to find the cause. It'd cost WAY too much to bring the original designer back in.

More details as I get them. Again, many thanks!

-Jim

You might have more than one issue here, but let's address the crucial one.

Incrementing CRC errors are convincing proof of a bad cable or a link mismatch.

The short version of the Auto-Negotiate issue: Set both the controller and the switch for Auto-Negotiate, or set both for 100/Full. Do not mis-match them.

There might be other issues, but let's take care of this one first.