RSNetWorks/DeviceNet ??

We have 11 (AB)Armor Start 284D PF4 drives on DeviceNet.

1. If I open up RSNetWorks and go line---do the network upload & save?
2. I will have all of the drives parameters and anything else on the network--right????
3. If one of the drives fail how do I down load to that 1-drive or device on the network?

This is something new to me and wanting to look down the road.
Thanks Terry

1. Yes.
2. Yes.
3. Go online with replacement drive and select download instead of upload. All parameters from offline file will be downloaded to replacement drive.

It's a good idea to test this yourself and become familiar with it when you have a down day so when have to do it in a real world situation with the plant manager looking over your shoulder you can perform this with confidence.

gmferg's advice is good.

The "upload network" feature goes to every device that's been browsed and uploads the configuration parameters from them. Watch the Results window carefully to be sure the upload succeeded on all the devices.

What you want to avoid is going online with a blank RSNetworx project, performing a browse, and selecting "Download to Network". That will load all the default parameters (from the EDS files) into every device, thereby resetting your system back to before it was installed.

So Ken & gmferg If I have everything backed up as you say & 1 of the drives fail.Remove & replace the bad drive wiring & mounting.How do you down load to that 1 drive--exactly what do you do as this point.Just don't want to screw anything up.

Thanks:beerchug:
again for the info

Terry

You have to set the Node Number on the replacement drive. I don't know if that's done with hardware or software on the ArmorStart version.

Then you open the offline project file, browse the network, select the new drive, right-click and select "Download to Device".

The most common problem is when the replacement device isn't really the same as the original; maybe the firmware revision is newer or you didn't have the right power rating in stock so you substituted a larger one.

Simple firmware differences *might* be resolvable in RSNetworx.

But especially for drives, I always keep a hardcopy of the drive parameters. RSNetworx will create a nice parameter list Report as an HTML file for an individual device, or for the whole network.

When this was set up they set the scanner card with a node address of 63.Is there a simple way the change it to 0? They started out with node address #1 why I don't know.
Thanks Terry

Terry B said:

When this was set up they set the scanner card with a node address of 63.Is there a simple way the change it to 0? They started out with node address #1 why I don't know.
Thanks Terry

Click to expand...

No, No, No.... It should NOT have been set-up this way - Node 63 is the "default" node address that "software-configurable" devices are factory set to. You put the node on the network, then "node-commission" it to an address that suits.

63 must NOT be used for a "real" node address, as doing so will ultimately lead to a "duplicate node" on the network when you add a device that is defaulted to 63.

You definitely NEED to put the scanner at another address, and "usually" node 00 is used for the Scanner.

How you set the scanner to node NN depends on which scanner you are using. Full Cat. No. pls...

daba
This is all new to me. Last night while at work I done a network upload and saved it. When the upload was complete it listed the scanner card as node 63. When I go in tomorrow I'll get more info to post tomorrow night. Any input and info will be greatly appreciated.
Thanks Terry

You should get yourself the DeviceNet Network Configuration Manual dnet-um004_-en-p.pdf

All I said above, and more, on page 23.

Sounds like you might have some hefty reconfiguration to do on this network.... Your biggest task will be if you have to re-map any of the device's I/O data, as this will surely throw your PLC code into disarray.

Best case scenario is if node 00 is "free", and you can just move the scanner to it, and leave the device mapping "as-is".

If node 00 is not free, you can also avoid any re-mapping by using any free "unconventional" address for the scanner, except 63 and 62 (62 is "reserved by convention" for a direct computer connection to the network, e.g. a 1770-KFD RS-232 to DeviceNet adapter module).

daba
The scanner(1769-SDN/B)has a node address of 63. Address 00 is empty. When they mapped this out they started at 01??? Is it any trouble to chnge the scanner to-00?
Thanks terry

daba said:

best case scenario is if node 00 is "free", and you can just move the scanner to it, and leave the device mapping "as-is".

Click to expand...

Edit : I've actually confused myself on this - the node address of the scanner will not affect the I/O mapping

hth

daba said:

You should get yourself the DeviceNet Network Configuration Manual dnet-um004_-en-p.pdf

All I said above, and more, on page 23.

Sounds like you might have some hefty reconfiguration to do on this network.... Your biggest task will be if you have to re-map any of the device's I/O data, as this will surely throw your PLC code into disarray.

Best case scenario is if node 00 is "free", and you can just move the scanner to it, and leave the device mapping "as-is".

If node 00 is not free, you can also avoid any re-mapping by using any free "unconventional" address for the scanner, except 63 and 62 (62 is "reserved by convention" for a direct computer connection to the network, e.g. a 1770-KFD RS-232 to DeviceNet adapter module).

Click to expand...

That takes me back to the early days of Control Logix and DeviceNet. Node 62 was reserved by convention for comm's and many people took this to mean that it should be used for the scanner. The early series 1756DNB modules had a wonderful little button behind the front flap which was used to set the Node No. and Baud Rate. If this was pressed while the system was running it would increment the Node No. so if 62 was being used it would change this to 63 but the change would not take effect until the power to the card was cycled. This was a recipe for endless call outs which, thankfully, Rockwell have since resolved.