PowerFlex 525-Fault 73.EN Net Loss. Anyway to ignore any short term Comm. Losses ?

Have you used this switch before? I believe it’s unmanaged, which will limit you in diagnostics and if needed, the managed settings. You should open up the integrated web diagnostics on the PLC’s ethernet card and start from there. You might need to use packet sniffer and tap between a drive and the switch and watch the traffic.

Is the packet sniffer on the PLC webpage , or is it a separate tool you need to download ?

Thanks

I have not used the 525's in recent months. But...is there a time setting for loss of comms? If it is set for say 10, or 100ms, maybe change it to 1000ms.

Rob S. said:

Is the packet sniffer on the PLC webpage , or is it a separate tool you need to download ?

Thanks

Click to expand...

Wireshark is a great packet sniffer, it’s a 3rd party tool that lets you see every packet that reaches your NIC. With that being said you need to monitor the connection between the PLC and drive, I highly doubt your switch allows port mirroring, so you should look into making a network tap.

I’m not sure if your switch has diagnostic logs being it’s an unmanaged switch, but you could check that if there is one.

Also the switch did say it had some form of storm protection, are you certain there are no loops in your network, like more than one switch to switch connection?

But the PLC Ethernet diagnostics page with counters should be your first look.

Ken Moore said:

I have not used the 525's in recent months. But...is there a time setting for loss of comms? If it is set for say 10, or 100ms, maybe change it to 1000ms.

Click to expand...

I looked into this once, and I don't remember the exact details, but it's an automatic time calculated by the RPI that is selected. Something like RPI x 4, with some other conditions in there. It is not user-adjustable other than raising the RPI time.

Rob S. said:

Is the packet sniffer on the PLC webpage , or is it a separate tool you need to download ?

Thanks

Click to expand...

I certainly wouldn't start with a packet sniffer. Just punch your PLC's Ethernet module IP address into your web browser. There is a lot of useful information to decide where to go next.

Good Morning ,

Any particular folder I should look under or data I should look at, on the Ethernet Adaptor webpage , to see where I may have "traffic" issues.

Also , can you guys give me a little more education , on what RPI is , and how the calculation works ? and what parameter to adjust if I want to possibly use this to ride it thru ? That is really what I'm looking more , is just 2-3 seconds to ignore a loss.

" I looked into this once, and I don't remember the exact details, but it's an automatic time calculated by the RPI that is selected. Something like RPI x 4, with some other conditions in there. It is not user-adjustable other than raising the RPI time. " rupej

I plan on replacing my AutomationDirect Stride 16 Port 10/100 , with Stratix 2000 Switches on Saturday.

Thanks so much for your help.

Rob S. said:

Good Morning ,


Also , can you guys give me a little more education , on what RPI is , and how the calculation works ? and what parameter to adjust if I want to possibly use this to ride it thru ? That is really what I'm looking more , is just 2-3 seconds to ignore a loss.

Thanks so much for your help.

Click to expand...

From the manual located on this site:
https://literature.rockwellautomation.com/idc/groups/literature/documents/um/520-um001_-en-e.pdf

Check parameter C141 on page 103. It is for the port / connection negotiation. They are listed as follows:

See if it is set to 0, indicating "Auto detect" which is sometimes referred to as auto-negotiation. Change it. Set it to 3 for 100Mbps Full first. Do not try half-duplex settings until you have tried all full duplex speeds.

Check the speed in the module configuration. Right click the drive in Studio and there is a properties / configuration type menu. I don't have the software to take a screen shot, but it should be easy to find. Bring up that module configuration, and see what the Ethernet/IP settings on that drive are. Take note of the settings regarding negotiation and Change it to "100Mbps Full Duplex"

There is a parameter C126 [Comm Loss Time] on 101. IF there is a setting like that, this would be it. It says there that it is for RS-485, but I would like to know if it is also for Ethernet/IP. Perhaps someone would chime in on that one. If not, how does Ethernet/IP do it?

Anyway, C128 is where the address settings start out. C129-132 are for the 4 octets of the IP address. They take the format of:

Having duplicate addresses will also give you problems like you are facing. My suggestion is to look at those main network parameters and figure out what that one has correct that the others don't. This may give you a lead.

Next swap the ethernet cable for the working drive over to another port. This would be a quick and dirty check to see if perhaps that ONE port is working and the others aren't.

Those steps should get you into what is happening. Basically, you want:

• The transfer rate settings to match on the PLC and drive. If both are on auto, try to set them both to a full duplex setting.
• To try the known working drive on another switch port.
• To compare address / ethernet settings between drives. All unique IP addresses. Let us know if you more detail on that.

You could very well have a bad switch, but I'm leaning towards a configuration issue somewhere. That being said, a stratix switch may very well resolve a negotiation issue as well.

Lastly, for RPI look at page 12 of this:
https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm004_-en-p.pdf

That is where the information on it starts. I would try a few quick and dirty checks first.

I had a very similar problem with four PF525's going into fault 73. I also had a HMI on the network that I found to have a faulty patch cable. Once I disconnected the faulty patch cable from the HMI (Ethernet Switch end removed) the PF525's remained fault free. Disconnect the PF525 that you believe to be good and try resetting the fault 73 on all of the others.

Instead of disabling the fault...

• Once comms are restored, you can programmatically parse whether the most recent fault code is 73.
• If it is, attempt some number automatic fault resets, then require manual intervention after the number is reached.
• This will cover the timeout that happens each time the PLC mode switches to Program during a download, for example.