How communicate with this device net module

jjwitty

Member
Join Date
Feb 2021
Location
United States
Posts
22
We have some very old technology in my plant that needs adjusted but I don’t have the equipment. Can anyone tell me what I need to program this IO associated with the DeviceNet?

Link :
 

Attachments

  • IMG_7028.jpeg
    IMG_7028.jpeg
    175.9 KB · Views: 27
That's a 1747-SDN DeviceNet scanner, of course, but we can't see from the photo what else is on the network.

The general purpose configuration software for DeviceNet with Allen-Bradley PLCs was called RSNetworx for DeviceNet. It's still for sale. RSLinx is part of the connection to the network, but RSNetworx does the configuration of the Scanners and the slave I/O devices.

You often also need a direct connection from your PC to the network. These could be the old serial 1770-KFD, or the PC-Card format 1784-PCD card, or the modern 1784-U2DN.

If you don't have any of those tools, or the expertise to work with the software and understand how it interfaces with that SLC, it might be more cost-effective to hire an integrator who does already have the tools and experience.

Follow that color-coded DeviceNet cable from the Scanner out into the system and let us know what's connected to it !
 
I don’t have RSnetworks. I have a very bad feeling these devices are going ro
Go bad one day and I will not be prepared to troubleshoot it. I am in tune with all modern technology, but not DeviceNet. I’m attaching a photo of what’s connected to the SDN module. This is a SLC5/03 PLC.
 

Attachments

  • IMG_7031.jpeg
    IMG_7031.jpeg
    168.8 KB · Views: 27
I’m attaching these drives that have to be controlled from that PLC also. They say device net.
 

Attachments

  • image.jpg
    image.jpg
    270.6 KB · Views: 32
  • image.jpg
    image.jpg
    186.1 KB · Views: 34
Oooh... old 160 drives. I remember them exploding. Later series supposedly had that fixed. We did see fewer explosions from the newer ones, but they still did it. Not what you asked, but I suggest starting a plan to modernize the system. The Flex rack is still viable with an AENT. Everything else shown is obsolete.
 
It was over 10 years ago when I had a panel full of those 160 series drives on DeviceNet and I needed to come up with a migration plan. At that time, I found that ABB ACS355 with FDNA-01 adapters would work on DeviceNet with a similar footprint. I think I got two of the dozen or so done before I left that company. I did have to reroute incoming power around to the bottom of the new drives and had some hassles getting RSNetworx to work well with the ABB eds files...I think there were come parameters that could not be accessed correctly.

I kind of liked the 160 series for its time. Allowing power in from the top has practical advantages. Oh the good old days when VFDs had less than a thousand parameters.
 
I think that folks can appreciate that the cabinets and equipment pictured have been the subject of some quick-and-dirty maintenance over the years, and that the system owner has been fortunate that they're still running at all. I agree that a migration and disaster-recovery plan is appropriate.

Since you don't have any of the software or hardware tools necessary to maintain that system, you have to choose between hiring in some help from someone who does, and buying or subscribing to those tools and learning how to use them.

If I were in this situation with a low budget, I would ask my distributor to get me the trial version of RSNetworx (which only allows configuration of Nodes 0-5) and buy a serial 1770-KFD on the aftermarket. I would use it to upload the 1747-SDN configuration (which is very probably at Node 00), then schedule an outage to plug a "spare" 160-DN2 that's been configured for Node 1 into each drive in turn, uploading (and then exporting the RSNetworx file to an HTML document for reference) and saving the configurations.

That will give you the necessary disaster-recovery information about how the drives are configured. When one fails, you can install a replacement, reconfigure it as Node 1, then change the DeviceNet address back to the correct address.

That process will also give you the opportunity to determine the DeviceNet network addresses of each drive, and make notes in your PLC program about where their data is mapped in the 1747-SDN memory.

If I had the budget for RSNetworx, I would do the same things except with a single copy of the network configuration and less plugging-and-replacing effort.
 
I had a customer with terrible problems with Bulletin 160 drives distributed along their conveyors, which eventually led to a facility-wide ban on any DeviceNet installations.

The problem was never the network; their conveyors were not grounded and operated as gigantic Van De Graff static generators. They discharged to ground *through* the drive control modules once the potential exceeded the couple thousand volts of isolation that the DNet adapters provided.

Maintenance guys would get violent shocks every time they worked on the machine. But they blamed the network because the drives went red-light when they static discharged through the drives instead of through the air or through a worker.

Later in my career, I hired one of the junior controls engineers from that company and he confirmed that he'd heard about those systems. "Why couldn't you fix the DeviceNet ?", he asked.
 
It was over 10 years ago when I had a panel full of those 160 series drives on DeviceNet and I needed to come up with a migration plan. At that time, I found that ABB ACS355 with FDNA-01 adapters would work on DeviceNet with a similar footprint. I think I got two of the dozen or so done before I left that company. I did have to reroute incoming power around to the bottom of the new drives and had some hassles getting RSNetworx to work well with the ABB eds files...I think there were come parameters that could not be accessed correctly.

I kind of liked the 160 series for its time. Allowing power in from the top has practical advantages. Oh the good old days when VFDs had less than a thousand parameters.
I feel I am very capable of integrating Powerflex and ENET Flex IO. Assuming most of the wires can be reused that’s currently supplying the DeviceNet and the “VFDs”, isn’t this a very plausible strategy ?
 
I think that folks can appreciate that the cabinets and equipment pictured have been the subject of some quick-and-dirty maintenance over the years, and that the system owner has been fortunate that they're still running at all. I agree that a migration and disaster-recovery plan is appropriate.

Since you don't have any of the software or hardware tools necessary to maintain that system, you have to choose between hiring in some help from someone who does, and buying or subscribing to those tools and learning how to use them.

If I were in this situation with a low budget, I would ask my distributor to get me the trial version of RSNetworx (which only allows configuration of Nodes 0-5) and buy a serial 1770-KFD on the aftermarket. I would use it to upload the 1747-SDN configuration (which is very probably at Node 00), then schedule an outage to plug a "spare" 160-DN2 that's been configured for Node 1 into each drive in turn, uploading (and then exporting the RSNetworx file to an HTML document for reference) and saving the configurations.

That will give you the necessary disaster-recovery information about how the drives are configured. When one fails, you can install a replacement, reconfigure it as Node 1, then change the DeviceNet address back to the correct address.

That process will also give you the opportunity to determine the DeviceNet network addresses of each drive, and make notes in your PLC program about where their data is mapped in the 1747-SDN memory.

If I had the budget for RSNetworx, I would do the same things except with a single copy of the network configuration and less plugging-and-replacing effort.
Thie is an oil bottling plant, cleaning is not on the daily agenda.

I’m the only controls guy in the plant so only am I aware of slippery slope we are on in regards to this old technology. I can tell management it needs replaced, but until it does go down and I’ve banged my head on the wall for 14 hours will they feel the gravity of the situation. I recommended migrating PF 525 and Flex, hopefully they listen.
 

Similar Topics

I'm trying to connect an ADAM 6156 PN (16 DO module) to a S7-300 series PLC over profinet. Loaded the GSD file, added the device to the hardware...
Replies
6
Views
3,213
We are trying to poll data coming from a PLC for remote monitoring we have the IP address of the PLC and the default port number and the path is...
Replies
25
Views
582
Hi all, Got a new device I'm trying to work out how to communicate with. It came along on Monday morning after 9 months of development inside my...
Replies
19
Views
5,719
hello @ alll, actually i am trying to send a constant character continuously to my redlion G306A device with my DSP 28335 Device but redlion was...
Replies
1
Views
2,107
how to communicate FactoryTalk Optix and Mitsubishi Q Series. I want to know the details of that
Replies
0
Views
37
Back
Top Bottom