Hello All!

I am using a BSN modules to switch RIO on a redundant SLC500 project (I didn't spec the hardware). The design has one pair of the Ethernet wires going through the 232/485 A and B terminals on the BSN so that the primary PLC would have connectivity to the Ethernet HMIs. For the most part, this works. However, during a failover, I am experiencing communication loss for approximately 7 minutes and 30 seconds. I started to isolate the network, and I am down to the switch, one PLC and the PV Plus. I have disconnected the ME Station, the Secondary PLC and my laptop

Network Configuration

Linksys Switch SRW2008 (10.12.1.1).

PanelView Plus 1000 (10.12.1.13).

Two SLC 500’s 1747-L551 Ethernet. They both have the same IP address, only one is connected to the network at any given time (10.12.1.10).

Dell workstation running RSView ME Station (10.12.1.2).

Programming Laptop is configured as 10.12.1.250

PanelView, Station and PLCs have 10.12.1.1 configured as gateway, and 255.255.255.0 for mask.

Testing

With the PanelView Plus communicating to PLC #1, I can unplug either the PV or the PLC, reconnect, and communication is restored in seconds.

With the PanelView Plus communicating to PLC #1, I can unplug either the PV or the PLC, reconnect to a different port, and communication is restored in seconds.

With the PanelView Plus communicating to PLC #1, I manually unplug PLC #1 and plug in PLC #2 (same IP and program as #1). Communication is dropped and I have 7 minutes and 30 seconds before communication is reestablished.

Everytime I test this, it is around 7 minutes and 30 seconds (+/- 15 seconds).

I have tried different ports, and same ports with the same end result.

I tried forcing PLCs and ports to 100/Full with the same result.I tried using an unmanaged switch/hub with the same result.

If during the PLC swap, I reboot the PanelView (reset switch on the back), communication is restored after the reboot is complete (under 7 minutes).

Best regards,

I could be guessing here but since PLC #1 and PLC#2 are not the same unit they are not the same MAC ID. I would curious what result you get using 2 PC's to communicate with the PVP. If the 7.5 minutes still exists?

Hey BobLfoot,

First off, thanks for taking the time to reply. MACID's are different, and no way to spoof PLC MAC addresses(that I know of).

I should clarify that the switch I am using is just for testing, switch in the field will be an unmanaged SPIDER 5TX.

How are you suggesting I test with PC's? NIC cards in the PCs will have different MAC IDs as well. Are you suggesting using the PCs to ping continuously?

I am going to try a cross over cable to eliminate the switch as a cause.

Thanks!

My bet is that what you are trying to do won't work.

It sounds like the ARP table entry for the IP address (10.12.1.10) is still matched to the MAC ID of the first SLC5/05.
So 1 of 2 things has to happen. The ARP table has to be flushed (power cycling does this) so that the PV+ will have to explicitly send an ARP request to match up 10.12.1.10 to the new MAC ID or the present ARP entry for 10.12.1.10 has to be changed.

I think if you substituted 2 PC NICs for the PLCs as Bob suggested, the latter would happen since PCs will typically send out a 'gratuitous' ARP request when they come up forcing the PV+ to update it's ARP entry for that IP address. But it doesn't sound like the SLC5/05 sends out a gratuitous ARP request when it comes up.

Have you tried talking to AB Tech support? They may know a trick or setting to make the PV+ flush it's ARP table.

Hi chstjame,

Thanks for the reply, I appreciate it! To be clear, it works, and communication is restored, it is just that it takes 7 minutes and 30 seconds.

You bring up some great points about the ARP table, and I suspect this is where the problem is...at the device.

A point of interest is that I performed the same test with just a x-over cables with the same result. So, the ARP table resides in the PV+.

I am not aware of anyway that I could test using a PC with two NIC's and a PV+?

I have contacted AB and the Distributor with no answers yet.

Best regards,

Paul

If the problem is the ARP table and this were a PC and not a PV+ I'd issue an ARP -d and let it rebuild. Might ask if you can do that with a PVP.

ANother thought. If Power Cycle cures it why wire a relay to control PVP Power. Let the Relay be Normally closed and whenever a roll over occurs ahve new Primary PLC cycle it's PVP power relay. This would give you a quicker than 7.5 mintue restore.

If this was a PVP CE, I might be able to do the ARP -d, not sure. Killing power will speed up the process, and might end up doing that, but...I am not a fan of "band-aid" solutions 8-).

I will hammer AB and the distributor for a real fix, if I get shot down then I will implement the relay fix. Customer spec'ed the hardware, so I am off the hook to some degree.

Control Net 1, Ethernet 0

Is there a way to change the MAC address of the PLC? Or a device that could be used to spoof?

On the PC running ME Station.

I switch PLCs, comms are disrupted.

I open a command prompt, type arp -d, then ping, and communication is established in seconds.

Need to be able to trigger this on comm. Loss and also perform this on PVP 8-).

FIXED!!!!

I am sending out a "dummy" message on the network from the PLC after a switch over. This is updating the ARP tables and restoring communication in seconds!!

Thanks group (especially Eddie from PLCs.net) for the assistance!!