RSLinx Classic Crashes PLCs When Using Ethernet/IP Driver

MCB

Member
Join Date
Jun 2009
Location
Pittsburgh, PA
Posts
5
I had an interesting problem at a customer's site today.

He has RSLinx Classic Professional version 2.50.00.20, and is using the Ethernet/IP driver to communicate with the PLCs. He is also using the Ethernet driver with individual IP addresses to talk to the different VFDs, which are from 192.168.0.30 though 192.168.0.38 (Both drivers configured are, however, on the same subnet. The Ethernet/IP driver configured to browse a remote subnet at 192.168.0.20, subnet 255.255.255.0)

In RSWho, if you were to simply just expand the tree that is the Ethernet/IP driver, all PLCs (there are 3 CompactLogix PLCs) on that subnet will completely lock up, as that is what I was told. He would then have to go power cycle the PLCs to get them to come back online.

Then after they power cycled the PLCs, they were able to see it in that RSLinx tree, and be able to get online. Say they would make changes to the program live in RSLogix5000 by adding a new tag. Then that would cause all of the PLCs on the network to lock up again, and be restored only after power cycling them.

I personally have not witnessed the PLCs crashing like that, and could not experiment today while I was there....




However, with my laptop running RSLinx Classic Gateway version 2.54.00.11, I was able to get online just fine. However, I used just the plain Ethernet driver, and added the IP addresses myself. I was also able to get online using RSLogix5000 with the processor with no problems.

I was unable to experiment with other drivers on the customer's PC today, as we were afraid of again crashing the PLCs...

The PLCs are all CompactLogix L32E.


So my question is: Is it the Ethernet/IP driver in RSLinx on the customer's computer causing the problem? Or is there something else configured improperly in my scenario above?


Thanks,

Mike B.
 
Is this an existing system that has been around for awhile or is it fairly new. I've had an experience with linx classic that when I installed it on my desktop to run an excel HMI it would crash my computer. I had to remove the software then reinstall. Just a guess
 
Sounds to me like duplicate IP addresses on the network. It could be possible that it doesn't cause much of a problem until Linx tries communicating with the device that has the same address, then the network goes screwy. Just a WAG.
 
Is this an existing system that has been around for awhile or is it fairly new. I've had an experience with linx classic that when I installed it on my desktop to run an excel HMI it would crash my computer. I had to remove the software then reinstall. Just a guess

The desktop computer itself doesn't crash. That continues to run flawlessly. However, it causes the PLCs to lock up completely.

The system has been installed within the last 2 years, doing the same symptoms as I stated above on the customer's desktop PC.



Sounds to me like duplicate IP addresses on the network. It could be possible that it doesn't cause much of a problem until Linx tries communicating with the device that has the same address, then the network goes screwy. Just a WAG.

That is what I am thinking, as the Ethernet/IP driver would conflict with the Ethernet driver with the addresses 192.168.0.30 through 192.168.0.38.

I just wanted to be sure that might have been an issue before I make my next site visit and start making those changes. I am hoping that will resolve the problem.

I am going to do an experiment in house here and see if that causes the PLC to fault.
 
Exactly what does "completely lock up" mean, from the customer's perspective ? I realize that failure to communicate might be as severe as an operating system crash from an operational standpoint, but it's not the same if you'r troubleshooting.

Have the controllers faulted, and have a flashing red or solid red "OK" LED ?

Are there changes to the indicatiors on the Ethernet port of the controller (Link, MS, or NS) ?

Are there other HMI devices accessing the controllers ?

Are the controller running MSG instructions or Produced/Consumed Tags ? Are there any ways to determine the status of that traffic ?

Do networked I/O devices (particularly the drives) lose their logical control from the controllers ?

Do the controllers not respond to HTTP or ICMP PING requests ?

Can the controllers be accessed using their serial ports ?

I use the EtherNet/IP and Ethernet Devices drivers all the time to access the same devices, and do not have any problems with them. I have ControlLogix and CompactLogix going back to 1997.

Is the PC's Ethernet interface actually on a different subnet from the controllers and the drives ?

My first two troubleshooting steps would be to use PING and a web browser to find out of the controllers are accessible using something other than CIP protocol.

I'd also check carefully the Connection count on the controllers and the CPU utilization of the Ethernet daughtercard. The symptoms you described seem consistent with the controllers being starved for connection resources or bandwidth, which are relieved by the power cycle.
 
The customer only told us that the processors completely stopped and the plant pretty much shut down. Power cycling them brought them back up.

I was not able to perform any troubleshooting on site yesterday, as they could have their plant go down at that time.

So I currently do not know if the controllers faulted, or had Ethernet problems, etc.


But I can answer some of your questions:
1. For each of the 3 PLC cabinets, there is a Panelview Plus screen accessing their associated controller.

2. There are no MSG instructions in the program.

3. The VFDs do loose their control from the PLCs when this happens

4. There is only one desktop PC on this network with RSView/RSLinx/RSLogix5000, and it is on the same subnet as the controllers and drives. While I was there, RSView was running just fine on his PC.



That aside, on my laptop, I was able to see all of the PLCs in RSLinx, and I was able to go on RSLogix5000, upload the program to my computer, and view everything working. I did not try to add a tag or anything, but it was completely stable the whole time, including me accessing it in RSLinx.

On my next site visit, I will be able to troubleshoot this completely, even if it takes the plant down again.
 
Wow, that's just a whole lot of weird. Adding a tag to one controller absolutely should not cause a different controller to fault.

A failure or "lockup" of the Ethernet daughtercard would break the I/O connections and make the connections to RSLinx and PV+ fail. An actual fault of the controller would do the same.

I'd take two tools with me on this:

1. The Fault Dump Utility from RA Tech Support. If the controller operating system is really failing, you can get some information out of the serial port. Do this before attempting to recreate the situation, and after.

2. A managed Ethernet switch with Port Mirroring. Capture the data going into the controller(s) when the RSLinx 2.50 browse is performed. Are you familiar with Wireshark ?

Get an RA Tech Support case going before you go onsite, so that you'll have someplace to send the dump files or capture files.
 
Last edited:

Similar Topics

Hey All, I am sorry to ask this, but i still gotta do it. What happens if I close RS linx? Will it cause network interruption and PLCs will lose...
Replies
5
Views
111
Does anyone know if there is a way to import RSLinx Classic data into FT Linx? We have a quite extensive configuration set up, and it would be...
Replies
8
Views
2,343
Hello, I entered my controller IP address as 192.168.1.100 (Local) for 1769-L33ER. It worked fine until couple month and found the controller kept...
Replies
1
Views
1,104
Hi All, Looking for some clarity regards the relatively recent rebranding of RSLinx Classic. From what I can make out from the RA website and...
Replies
9
Views
2,212
Inexperienced user here. We are upgrading servers and currently have RSLinx Classic Lite with a dozen SLC505s on it. The new server will run FT...
Replies
0
Views
772
Back
Top Bottom