VFD Guy

In my opinion, the first thing should be to determine if the drive is doing what is told. Compare the commanded speed to the output via its parameters. If they don’t match, use 750-pm001 manual block diagrams to see where the problem is. Divide and conquer 

As stated, the rpm in wrong. Also, the flux current appears very high. I would correct nameplate info and retune. Sounds like your drive is hitting a limit and folding back

Does the 3rd party servo support CIP sync and CIP motion protocols?

This is correct. If no 22 comm module installed then you need a 1203-usb 

The basics of VFD troubleshooting is to identify if the VFD is doing what it’s told. Compare commanded speed with output. Based on what you’ve stated it sounds like it’s not. This tells me the drive is hitting a limit and folding back. There should be alarms and limit statuses you can monitor. Another quick trick if you are in an open loop mode is to run without motor connected. If the it still cycles, you know to focus on the drive. If not, it’s a load or failure of the drive. At that point, I’d be looking at the logged alarms to understand more. There are regulators in the drive to overwrite the command to protect itself

1203-USB is what you need for using the DSI port. The old model was the 1203-SSS. If the drive is on a CIP network that RSLinx supports then just use CCW to connect via the network 

I think you can do this with source protection which is outside of factorytalk. Not a password but still lock it down

I use the new enet commissioning tool that is much better than the bootp tool

There are many on the knowledge base site. Some are tech connect so I don’t think I can post those here. Just search the fault name or number. My experience is that synch issues are caused by devices between the controller and plc. Check switches are set up with PTP, enable time synch with any enet modules. Things like that

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 

Connect with CCW. You can view the history there. It’s the latest drive software and free. Run the tech support wizard for print outs of parameters and fault history