SLC 500 loses network comms

[jon511]

I have a slc 500 that communicates with a softengine and a RSSQL server. About once a day the communication with the SLC locks up, the only way I have been able to get the communication going again is to power down the processor on the SLC. Does anyone have any ideas?

I have 7 other SLCs that communicate the same way, with the softengine and RSSQL server, but this is the only one that locks up on a regular basis.

 

[OZEE]

Jon, you've got to give us a whole lot more information than that...

Which model of SLC? I assume it's not really a SLC500 -- those old bricks have been obsolete for years. How is it communicating to the softengine/rssql? What do you mean that it "locks up"? How is everything networked?

 

[jon511]

Sorry about that.

All the SLC's are 5/05, the softengine is running softlogix5, all communications are through ethernet. A Cisco switch is used to connect all the plcs to the plant network. The ethernet port is what locks up on the SLC 5/05, it only happens on the one 5/05. When it locks up, the ethernet indicator light stays on solid, the only way to get it to start communicating is to reset the power to the 5/05. I have tried a different processor in the problem plc, and it still locks up. This would lead me to believe it is a network problem, but this is the only 5/05 that locks up on a regular basis.

Is it possible for the communication to get lock up by the plc program?

 

[Oakley]

How similar are the programs between processors?

Have you done an audit on the communications to ensure that there is no messaging that may be locking up the ethernet port?

 

[jon511]

The plc programs are pretty similar. The 5/05 that locks up has 6 MSG instructions in it.

About doing and audit, do you mean the audit the network or the plc. I can monitor the network traffic through the cicso switch, and there doesn't seem to be any problems there. Can you do an audit on the plc communications.

 

[Mark Buskell]

When it locks up, have you tried going online to see if one of the MSG blocks has any error codes.

Also are you continously sending the MSG blocks through a timer or are you staggering your message blocks.

You may also want to look at resetting the MSG error with an OTU.

 

[Oakley]

The key point is to find out what is stalling the port.


It could be from another source - if the request is creating errors.


The first step could be determining if the errors were originating from the PLC end.

 

[jon511]

First, I would like to thank you guys for the help.

The last time it locked up, I had to go online through the rs232 port. None of the MSG blocks were errored out. Three of the MSG blocks were enabled. All the MSG blocks have a time out value of 23, but none of them were errored out.

 

[jon511]

I just dug a little deeper, 2 of the MSG blocks have the error bit being unlatched as soon as it makes, so it is possible that one of them did have a error. Is there a error log anywhere in the plc that keeps track of errors.

 

[Oakley]

You may want to put logic into the program that limits the messages.


Search the Rockwell Website for Message Manager.

There is a nice write up in one of the articles on how to implement in ControlLogix - same basic principle could be applied here.