PointIO Change From DeviceNet To Ethernet

These are in RSNetworks for Devicenet file. You can see IO revisions there as well.


I found in RSLogix where this SHOULD be, but the file doesn't exist.


I'm guessing going online and selecting View/Edit DNET File will upload the configuration, or won't it?


The other thing I just got too was opening RSNetworks gives an activation error as my licenses for it are EVMove and not FTAM so Monday going to have to get with Rockwell Tech Supp and upgrade them.
 
I found in RSLogix where this SHOULD be, but the file doesn't exist.


I'm guessing going online and selecting View/Edit DNET File will upload the configuration, or won't it?
It will not (assuming by 'going online' you mean in Logix). All that is in RSLogix is a pointer to an (offline) RSNetworx file for convenience in opening it.

In order to upload the Devicenet configuration you need to open RSNetworx for Devicenet, then go online with the Devicenet network and upload there.
 
It will not (assuming by 'going online' you mean in Logix). All that is in RSLogix is a pointer to an (offline)


When in the RSLogix5K program [offline because I am home] I click on the View/Edit button on the Devicenet module properties window it opens RSNetworx and there are no .DNT files in the project folder.


I am (hopefully correctly) presuming this will go online and upload the configuration without needing the OEM files.


EDIT: Another small personal issue is although RSNetworx is installed on 3 desktops with various versions of RSL/S5K - the laptop does not have RSNetworx installed and I just went through the v16.05 and v33.01 installers and it's not listed (I have Studio5K Full Edition that includes everything on all PC's) so I might have to haul a desktop there tomorrow.
 
Last edited:
The only real benefit of going from POINT on DeviceNet to POINT on EtherNet/IP is that the bit numbers and data formats will be the same from module to module.

The method for "mapping" the data in RSNetworx for DeviceNet, even using default settings or the DeviceNet Tag Generator tool is simply very different from the auto-generated Tags related to each POINT adapter or module over ControlNet or EtherNet/IP.

IMHO you should follow ControlConn's recommendation to see if the POINT modules have the necessary firmware to even work with a 1734 EtherNet/IP adapter, and then make a decision about migrating versus fixing the existing system.

While a lot of folks whine bitterly about DeviceNet and how complex it can be, it's just four color-coded wires, and 90% of DeviceNet problems are loose wires, missing resistors (there are two ! Why can't people count to two !?), or a bad power supply.
 
and 90% of DeviceNet problems are loose wires, missing resistors (there are two ! Why can't people count to two !?), or a bad power supply.


The power supply has been changed, new cables run and even the resistors removed and ohm'd out. Even reseated the DeviceNet module, and all the node modules, & swapped out node adapters. The only things not tried is replacing the CLX rack or replacing each node module.


The customer has had DeviceNet problems on this press for years. Talking to the OEM support he's trying to remember what was done before, but he says he remembers it's some stupid simple thing.



Now a question for the experts here: The 2 nodes are wired with 2 DNet cables coming off the CLX rack module, each with a resistor. Would changing that to daisy chain from one node to the next, removing the resistor from the first node, make any difference?
 
Now a question for the experts here: The 2 nodes are wired with 2 DNet cables coming off the CLX rack module, each with a resistor.

Wait, you have two cables coming off with resistors? Are they on two separate plugs? If they are both coming off a single plug there should not be any resistor present, as only the terminating nodes on the network should have the resistor.

EDIT: It might help if you could provide a schematic of your network.

You ohmed out the resistors with them removed, but have you checked the resistance with them in place? You should read ~60 ohms between the blue and white wires (two parallel 121 ohm resistors, one at each end).
 
Last edited:
Just happened to take photos of the OEM schematic.


2 cables coming off the DNet interface each going to one node and a resistor on each node and no resistor on the interface.


I only ohm'd out the resistors removed, but with brand new cable installed would have to be 60 (if nothing is going through the interface and nodes)

0401221208.jpg 0401221208a.jpg
 
Just happened to take photos of the OEM schematic.


2 cables coming off the DNet interface each going to one node and a resistor on each node and no resistor on the interface.


I only ohm'd out the resistors removed, but with brand new cable installed would have to be 60 (if nothing is going through the interface and nodes)
Pictures are correct to how it should be, I got concerned when you said 'cables coming off the CLX module with resistors' that you meant the resistors were on the CLX side.



Let's back up a step -- what actual fault code(s) are you getting on the CLX card? I agree with Ken that 90% of issues are power/wiring, but the other 10% do exist.

I'm far from an expert but I've dealt with enough DNET issues to have some idea what I'm doing.

You wouldn't be anywhere near Jackson or Adrian would you?
I'm a bit south of Ann Arbor.
 
Let's back up a step -- what actual fault code(s) are you getting on the CLX card? I agree with Ken that 90% of issues are power/wiring, but the other 10% do exist


The Pointbus LED flashes red on both nodes after booting. Node 10 has ALL Network LED's flashing on all modules. Node 20 has the Network LED's flashing constantly on 3 modules and randomly on 2 others. The other LED's on the node and modules are solid green.



South of Ann Arbor is a lot closer to this press than I am, for me it's close to a 2 hour drive, and I don't have a lot of experience with DNet.


After trying a few things today the customer just said they found someone nearby that has a new -DNB interface they are going to get and try.
 
It's been a few years since we decommissioned our last machine that used DNET Point I/O (and good riddance, it was poorly designed in a number of ways), but things are starting to come back to me :)

I don't see a part number for the node adapter, but I'm going to assume they're a 1734-ADN(X)

Warning: Long-winded verbiage incoming
After trying a few things today the customer just said they found someone nearby that has a new -DNB interface they are going to get and try.
Note that you will need RSNetworx to commission the replacement -- at which point I'd suggest checking out the original one anyways. It's sounding more and more like there's some issue with the scanlist(s) (see below)

The Pointbus LED flashes red on both nodes after booting.
Flashing Red Pointbus indicates "No scanlist is available' or 'I/O module is missing." In other words, what is configured as present in the scanlist doesn't match what is physically there. The flashing network LED on individual cards points to the cards in question. Unless someone's shuffled the cards or you've got bad cards/backplane (unlikely on this scale imo), you're going to need RSNetworx to take a look at the actual scanlist.


Let's take a moment for a brief (but important) aside. There are potentially actually three networks present:
1. The main network (1756-DNB as scanner and two nodes as adapters. The DNB will have a scanlist with the two nodes configured and will map a chunk of I/O data from each adapter into the DNB module's tags.

2 (& 3). Each Pointbus adapter will serve as a scanner on its own subnet serving the individual I/O cards. Each adapter will have its own scanlist listing each card and mapping its data into the I/O chunk which the main network will then read. Usually they are a straightforward mapping in sequential order as they appear in the chassis, but not necessarily.

Each network is likely to require its own .dnt file.

I've seen a setup where some individual cards were read directly by the DNB card, but they were on a PointBlock relay, not off an actual 1734-ADN adapter.

Returning to the main point, the flashing red PointBus LEDs indicate that the scanlist in the PointBus Adapter[/i] (subnet) does not match what it detects physically present. This has nothing to do with the ControlLogix DNB card -- issues with that will show up on the Network LED of the adapter.

Node 10 has ALL Network LED's flashing on all modules. Node 20 has the Network LED's flashing constantly on 3 modules and randomly on 2 others. The other LED's on the node and modules are solid green.

3 modules + 2 more = 5 modules -- is this all of them, or are there some that have solid green Network LEDs?

What is the state of the LEDs specifically on the adapter module(s)? I'm not sure if when you say 'modules' you are including them, or just the individual I/O. You earlier noted the PointBus LEDs were flashing red, but if the Network LEDs on the adapters are green then an issue with the DNB becomes significantly less likely.


tl;dr Flashing red Network LEDs on individual I/O cards points towards an issue with the PointBus backplane, the cards being physically in the wrong locations (cards of the same type are potentially interchangeable, but certainly not with other types), or a scanlist issue in the 1734-ADN adapter. I would not expect doing anything with the DNB to resolve this.

If the 1756-DNB has a scrolling display I would be interested to hear what it reads as that could tell us whether it is seeing node 10 and 20, but until the issues on the individual node subnets are sorted out I wouldn't spend a lot of time on it (good to have a spare just in case though).

Overall, it sound to me like you aren't going to get far without having the actual scanlists to look at. Once you have them you can go down the line matching up the configured modules to what is actually present.

If somehow the scanlist(s) have been lost, they can potentially be recreated -- good documentation is incredibly helpful. I've restored a small network by looking at how the data was used in the program and matching it up, but if things aren't labelled well it can be a nightmare.

South of Ann Arbor is a lot closer to this press than I am, for me it's close to a 2 hour drive, and I don't have a lot of experience with DNet.
I don't consider myself to have a lot of experience, but I've had to fight with a few machines. A word of advice -- don't mount the cabinet containing your Point I/O on a moving hydraulic cylinder that's going to get a lot of vibration.
 
Per the photo (both nodes)

1 - solid green
2 - solid green
3 - starts green, changes to flashing red after about 20 seconds
4 - solid green
5 - flashing green (plus on Output cards all outputs flash with that LED)


As for Node 20 partially flashing
Card 1 - random flashing of LED 5, mostly solid green
Card 2 - random flashing of 5 but independent of card 1 solid or flashing & rarely flashing at same time card 1 is flashing

Cards 3, 4 - solid green always
Cards 5, 6, 7 - flashing #5 green always


One thing is both these nodes went down suddenly together, so it is highly probable that a single issue is at fault here, not 2 separate faults with the 2 nodes happened to pop up at the same time.



The -DNB does have the display, but I didn't record it and the photo has it showing "A#01"



I did get the 3 DNT files this morning, zipped & attached.



As for vibration no moving hydraulic cylinder here - these are mounted directly on a 600 ton stamping press that creates a 6.5 on the Richter scale.

1659049065425.jpg
 

Attachments

  • DNET.zip
    8.7 KB · Views: 2
2 - solid green
"Device on-line and has connections in the established state" -- In other words no issues seen on the main network/DNB side of things. This jibes with the DNB displaying A#01 -- that's what I'd expect to see on a healthy network. Doesn't rule out that there are scrolling faults not present in the photo, but from what can be seen everything in the main network is good.
3 - starts green, changes to flashing red after about 20 seconds
As mentioned, flashing red points to issues with the adapter connecting through the backplane to the individual card(s).
5 - flashing green (plus on Output cards all outputs flash with that LED)
This is interesting, I somehow thought you had said they were flashing red (upon checking you didn't specify color, mea culpa) -- flashing green indicates 'Device needs commissioning due to configuration missing, incomplete, or incorrect.'

In other words, things keep pointing back to the adapter scanlists not matching what is physically seen.
As for Node 20 partially flashing
Card 1 - random flashing of LED 5, mostly solid green
Card 2 - random flashing of 5 but independent of card 1 solid or flashing & rarely flashing at same time card 1 is flashing

Cards 3, 4 - solid green always
Cards 5, 6, 7 - flashing #5 green always
Solid green on 3 and 4 tells us that the scanlist exists and has them configured. With that, my armchair diagnosis is that there's issues with the backplane and/or individual modules. (The intermittent flashes of cards 1 & 2 make me think backplane specifically).

You said the individual modules were re-seated -- just the modules, or the TBS backplane as well?


One thing is both these nodes went down suddenly together, so it is highly probable that a single issue is at fault here, not 2 separate faults with the 2 nodes happened to pop up at the same time.
I agree that this is suspect, and a reason to initially look at the main network. No further evidence that I've seen points that way though.

The -DNB does have the display, but I didn't record it and the photo has it showing "A#01"
Off-hand that's normal for a running module, if there are other things scrolling it'd be worth finding out.
I did get the 3 DNT files this morning, zipped & attached.
Everything looks normal here.

As for vibration no moving hydraulic cylinder here - these are mounted directly on a 600 ton stamping press that creates a 6.5 on the Richter scale.
*wince* In my experience the 1734 backplane is not particularly solid and long-term vibration will cause issues, perhaps requiring replacement of parts of the TBS backplane and/or individual modules.

Note that if it is indeed the backplane at fault, switching to Ethernet won't do anything to resolve the root issue, just make it easier to troubleshoot in future.
 
You said the individual modules were re-seated -- just the modules, or the TBS backplane as well?.................

Note that if it is indeed the backplane at fault, switching to Ethernet won't do anything to resolve the root issue, just make it easier to troubleshoot in future.


These don't have a backplane like a PLC rack, or even Siemens backplane connectors.


Each module has connection blades on the side of it that the next module slides into directly. I just suggested to the customer to pull each and clean with a fine wire brush and pinch the socket side contacts together for a tighter connection.
 

Similar Topics

I'm working with a 1734-AENT PointIO module (manual) connected to a 1769-L30ER controller over fiber ethernet. The 1734 PointIO module has some...
Replies
3
Views
1,025
Hello all, I Have a PointIO module with 2 input cards. The Revision is 6.013 and it is connected to a ControlLogix running version 24.11 The...
Replies
16
Views
2,335
Hi, I'm having issues commissioning a new PointI/O module (1734-4IOL) on an existing DeviceNet network (1756-DNB). I am adding the 4IOL module to...
Replies
1
Views
813
Is it possible or advisable to remove an RTB, then reinsert a new RTB on a 1734-AENTR without power cycling? This is done with modules of course...
Replies
3
Views
1,851
Hi Experts, I got a 1734-ACNR failed on-site recently. I have replaced it with a new ACNR (node number and chassis size configured) but can't fix...
Replies
9
Views
3,533
Back
Top Bottom