VFD Guy

Apologies. I understood the opposite in the initial post that said stand alone worked

Seems like some good convo here. If I summarize it right. Your system works stand alone but not on enet. So I go to the basics of divide and conquer. If on the problematic drive, you disconnect enet and set the settings to keypad and pot and it works then adc is not the issue. Adc only triggers on comm establishments. If you still have the issue, I would look for not fault config params on comm loss. With enet unplugged and you power cycle, set up for him and pot and it works. It has to be some setting. Can you attach .iuux CCW file so I can take a look?

K5500 don't need to be on DLR. Interesting that upgrading RSLinx fixed the issue. Nice find. I would look at the motion timing statistics in Studio to see collect data with this issue. Too much jitter will cause a synch fault.  I use FactoryTalk  Updater software (Free) to notify me when Rockwell's PCDC site has newer versions of software so you might be interested in that.

Has anyone asked if ADC is configured?

This is caused be the planner not seeing enough counts of position and the motor is not where it’s supposed to be like stated above. Could be many things. I would start with motion direct commands to verify motor and encoder are working. Obviously open the brake if one is equipped

Can you explain what the chip you replaced was?  Was this on the x comm box or 22 comm e?  Info on your error would help

The identity page has nothing to do with tuning. I would ensure the CCW profile is up to date. If a plc was connected, a tune wouldn’t be possible from CCW. Plc owns the Io connection as a class 1. In order to tune ie control bar to start it, a class 3 connection needs to be opened which can’t if it’s owned. This is why there is no control bar function in the AOP of logix 

The uftb is like an AOI. the download typically comes with instructions. What is the error you are getting and what sample code did you download?

Thanks @Tommie Dont Ground. After 12 years no warranty and I figured replacing wouldn’t help. I’m a big fan of divide and conquer. What is the time between each fault. This would help with a troubleshooting strategy. Also, you have 20+ drives. What other devices are on the network? Has anything been added recently? When you state the drives fail occasionally, you mean they are damaged or just mean you replace them when an F71 appears?

I’m just saying slower speeds doesnt mean a hardware issue. That’s the data you need. If it’s a hardware problem, then replace it. Problem goes away right? Replace it. Or are we not confident in that solution?

Those ribbon cables can be long. Check how it’s routed. Is it mounted in a fashion for high vibration 

This is an easy suggestion with no data 

That’s a difficult concept for me to accept without supporting data. Baud is just the speed at which it talks. If that were true, a single drive at 500kbps would have the issue. Are there release notes on the 500kbps issue?  Have you tried other traffic reducing means such as rpi time or less devices on the network?  If this is 11 years old, and is a hardware issue, then moving a known bad one to a good position should stay with the drive. Just giving you thoughts on troubleshooting 

Comm issues are sometimes hard, especially when it’s random. More when it’s on a bus network such as devicenet. Asking the right questions helps narrow down. Do all drives fault at once or one here and there. Are the pf40s in single drive or multi drive mode?  What is the spacing on top and bottom of the drives?  Any new device been added to the bus?  If reducing baud rate fixed the issue, this probably masked the problem

Odd solution. Did you try what I suggested above?  I’ve never heard of this fault caused by stored data. I could possibly it as a secondary issue to the flux value when above base speed. I’ve found the best way to force Rockwell on an issue is to continue to call in and ask for updates on the case. But if you are happy with your solution that works too