Obsolete vfd upgrade (devicenet)

dmargineau · Mar 24, 2017

Let's say that matching the 59(60) corresponding parameters between the SP600 and PF525 VFDs would probably more than suffice.

An off-the-shelf PF525 is pretty much ready to go with a minimum of a setup for most of the common VFD applications

1. Specify the controlled motor information (HP/KW, FLA, RPM, etc)

2. Specify the Start/Stop source.

3. Specify the Reference source.

All AB drives have an annoying 10 seconds Default value for Accel and Decel Time- these values will most likely need to be reduced prior to startup.

Most of the other parameters are usually addressed for more specific/complicated applications.

The Quick Start Manual will walk you through the steps:
http://literature.rockwellautomation.com/idc/groups/literature/documents/qs/520-qs001_-en-e.pdf

The User Manual contains more in detail information about the drive functionality:
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/520-um001_-en-e.pdf

For you particular application PF525 on DeviceNet the 25-COMM-D communication adapter manual will come handy:
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/520com-um002_-en-e.pdf

JohnnyQuanex · Mar 24, 2017

Thanks...

FactoryTalktotheHand · Mar 24, 2017

I've done something similar.

The problem is, the Devicenet assemblies get pretty complicated. They're not going to be the same. You'll have to figure out where your new control bits and words are and change them in the PLC program. You also may lose functionality, depending on how you're controlling the drives. I know that when I was upgrading SSC160s on Devicenet to Powerflex 40s on Devicenet, the Assembly of the PowerFlex 40 did not include the Output Amperage like the 160 did. So I had to explicit message that portion. A 525 might be different, and that may not be an issue, but just be very aware of what you are passing back and forth to and from the drive now and have a plan in place how each of those elements are going to be handled with the new drive.

jraef · Mar 24, 2017

Also if you were not aware, the 525 has Parameter Groups set aside for a variety of typical applications, such as pumps, fans, conveyors, compressors, things like that. By jumping to one of those groups, the drive only shows you the parameter set that would apply to that use. You still have everything else available to you, but you don't have to slog through it all every time. In addition there is a "Custom" Group that you can create yourself, and give it any name you like. So one thing I have done with that in retrofit situations is to plan out in advance of any replacement exactly what I'm going to want the new drive to do, usually by looking at what the old drive was doing (but keep in mind that there may be new features to take advantage of). Then I create a custom group and name that group the name of the machine. That way if it is installed by someone else, I leave instructions on how they access that parameter group and mask off all of the others so they don't screw things up (without making an effort).

GTUnit · Mar 25, 2017

When doing a migration from one drive brand to a dissimilar drive brand I would reccomend not focusing on making the parameters match. Focus on getting the new drives to behave the same as the old drives.
Command Word and Feedback Word is where you start.
Just check the program to see what commands or parameters the program uses and you can probably ignore the majority of the rest of the stuff in the drive setup.

sparkie · Mar 25, 2017

Paully's5.0 said:
OP, I see a number of things you probably should have "in-place" to make swaps easier, especially if people are doing them when they fail.

1 - Logic in place to handle the resolution changes, probably a button on an HMI to toggle logic in the PLC if it is a PF40 or PF525

2 - Drive configuration files, you can probably create those in CCW ahead of time and ready to download to a new drive when needed.

3 - DeviceNet, this one is tricky. IF you have enough open addressing you could configure the DeviceNet network ahead of time by placing the new drives on the network as new nodes, however missing nodes on the network (future PF525 drives) might not be ideal. But you could set everything up, node address/PLC mapping addresses and they wouldn't have to touch the network. #1 evolves quite a due to the PF40/PF525 node addresses being different. But if you aren't afraid of updating DNet when you replace the drive you could forego this one.

Procedure:
1 - Replace drive, set pre-determined Dnet node address
2 - Download CCW config file to the drive.
3 - Toggle the logic to the "PF525" logic vs "PF40" logic
4 - Clean up the logic/DNet files as you go.

I would go a step further as to set up a config file for CCW and have a small switch handy. They probably already have a 3 phase test bench there. There is likely some labeling system for the machines and drives.

If the entire system is on one network work out the IP addressing ahead of time and make your config files. If each machine is on its own segmented network, then you can likely use one config file for each drive of the same type.

Then, you don't have to mess with configuring the drive over devicenet, as you can just plug in your little switch that has a sticker on it containing the network settings needed by your computer, power up the drive (which will have default IP address) and copy over the config with CCW, assigning the IP address as necessary, labeling and backing up the configuration file.

Lots of variables there but you get the gist, then you don't have to mess with removing or adding nodes to DNet on the fly.

Sorry misread. Didn't realize you are keeping dnet at the moment.

Obsolete vfd upgrade (devicenet)

dmargineau

Lifetime Supporting Member

JohnnyQuanex

Lifetime Supporting Member

FactoryTalktotheHand

Member

jraef

Member

GTUnit

Member

sparkie

Lifetime Supporting Member

Similar Topics