Replacing a VFD... DeviceNet Steps to match new/old controls (SLC 5/05)

My DeviceNet skills are rusty and weak... so of course, an old, obsolete Reliance 400 HP VFD goes down and we're looking at replacing it with a Yaskawa A1000. ...AND, of course we're under the gun and I'm the sole controls tech for this plant.

I'm hoping to get an idea of the steps to take in changing the drives and re-establishing the same DeviceNet connections with the SLC 5/05 ladder logic. I'll be reviewing the DeviceNet manual tonight, but I remember being foggy about how to even start this process. The good thing is that once I learn how to do it, I'll be able to replace 8 more small drives on the machine.

Here are some details...

Old drive, GV3000/SE
New drive, Yaskawa A1000
PLC: AB SLC 5/05
I do own: RSNetworx for DeviceNet
1770 KFD

My understanding of DeviceNet with the SLC is that RSNetworx writes addresses in the SLC's memory, and then we can access those bits/words for the different communication functions between the PLC and drive... like run enable and amp draw, etc.

So many details I'm unsure about... do I remove all the old addresses for that node? do I give the new drive a new node address and change the ladder logic to the new addresses?

I've set up connection like this in the classroom... once, about 3 years ago. I didn't have to *replace* a device with a totally different device, though.

I appreciate any help/advice you can offer. Even just an outline of the steps to take, in order, would help. Thank you so much!

Brian

Brian:

First of all you have to be sure how big is your new (EDS) devicenet driver ( yaskawa) compared to the old one (reliance), if the new one is bigger then you have to remap the whole things and you have to be aware of this.
What I mean is like this: if you have other devices on the same network you have to modify your program due to remapping.
Be careful or otherwise you're going to be in a mess.
Or you can try to use unused addresses in order to avoid remap and leave reliance space free on the scanner list.

Yes! That's what I thought! I'm thinking of giving it a new node address and just moving the pertinent instructions to the new addresses. So...

Step one: Compare the new EDS size to the old EDS size... consider giving the new EDS a new, unused location in the memory.

Step two: Is there a way to easily see the open locations... in RSNetworx, I'm guessing?



Sidenote: I was surprised how many devices were linked to this one SLC through DeviceNet. This company bought just a portion of this huge plastic extruder, and the portions of the machine they didn't purchase are still configured into the DeviceNet card and SLC ladders. I've been hesitant to remove the missing devices because I don't want to make a decision like that without knowing the full consequences. This gives me a #78, config error on the scanner. The machine still runs with that error, so I've been fine with that until now. Now, I'm wondering if there is enough open memory to add the new drive... Hmmm.

Error 78 is a node error from memory - f what you say is correct and lots of nodes are missing then thats why your getting a 78 error

Again from memory it normally cycles from the error (78) and the node address

Its sounds a bit of a devicenet mess to be honest.....

Manual Here for Device Net Scanner

http://literature.rockwellautomation.com/idc/groups/literature/documents/in/1747-in058_-en-p.pdf

The first two things you need are the RSNetworx for DeviceNet project file (*.DNT) and of course the RSLogix 500 project file for the SLC-5/05 controller.

The crucial thing that needs to be in the RSNetworx for DeviceNet project file is the 1747-SDN Scanlist. That's what tells the 1747-SDN how much data to exchange with each slave device, and where to put that data in the 1747-SDN memory so that the SLC controller can use it.

EDS files do tell you a lot about the I/O connections and how they are formatted, but the Scanlist is the most important thing.

If you also have a backup copy of the RSNetworx project file, it might have the GV3000 configuration in it as well. That's going to help you tune up the sort of things that you would have to do on any drive; set the acceleration and deceleration rates, figure out the speed reference scaling, etc.

Imagine that the GV3000's output assembly was something like this:

Word 0: Run / Stop / Reset / Jog / Forward / Reverse / Speed Select
Word 1: Speed Reference, 0-32767 = Min Hz to Max Hz

And maybe the Yaskawa output assembly is something like this:

Word 0: Run Forward / Run Reverse / Jog / Speed Select / Reset
Word 1: Speed Reference, 0-12000 = 0 to 120.0 Hz.

You would have to convert your logic both for starting and stopping the drive, and for sending it a speed reference.

Get whatever files you can and post them, or send them to me by PM.

The info given here is correct about status code 78; it indicates the scanner is not communicating with a DeviceNet slave node. The status codes alternate with the slave address.

Status code 72 appears when a device was communicating and stops. Once the scanner has attempted to re-establish communication (or if it has never been able to start), you'll see Status Code 78.

You can de-Activate a particular slave device's scanlist entry without removing it from the scanlist or from the memory map, if you're being conservative. It's nice sometimes to not have to stand there and try to keep up with a flashing list of status codes, most of which you need to ignore.

Yes!!! Thanks! DeviceNet is the last area of this extruder that I'm fuzzy on. The new VFD is expected on Monday, and I'll be getting familiar with what I need to know between now and then.

Ken... I'm always amazed and grateful when you post! Thanks once again!