1734 Point I/O missing module node address change

[a093619]

Hi All,

I have a Devicenet network installed, configured, and working properly. One location in the network consists of the following: 1734-PDN, 1734-OB4 (Node1), 1734-IE2C (Node2), 1734-OE2C (Node3), 1734-OE2C (Node4), 1734-OE2C (Node5), 1734-OE2C (Node6), 1734-OE2C (Node7), 1734-IT2I (Node8), 1734-IT2I (Node9), and 1734-IT2I (Node10). I have physically removed 1734-OE2C (Node7) from the 1734-TB wiring module (to be replaced later) leaving an open slot. SDN showed Node7 was code 78 (as expected). Power has been cycled to the control cabinet (but not 24V Devicenet power), SDN still Node7 code 78 and all else still functional. Cycle power to PLC (1768-L43 utilizing a 1769-SDN Devicenet module and Right End Cap) Node7 code 78 and all still functional. Called it a night. Returned next morning to find Node 8 (1734-IT2I) is now Node 7, Node 9 is now Node 8 and Node 10 is now Node 9. I forgot to check status on SDN module. Keep in mind there are two programmers (me and one other) using the same PC, RSNetworx configuration file and RSLogix5000 program. ADR is NOT configured and NOT enabled nor is AAR enabled in the 1769-SDN. Any reason these nodes are changing addresses because of a missing module in the middle ?

Thanks in advance,

 

[dmargineau]

Probably the the RSNetWorx Node Comissioning Tool was deployed via a SAA (Sequential Auto Addressing) command...
When the SAA command is set each module to the right gets a new address one greater than its neighbor. The addressing will ripple through a line of POINT I/O modules, assigning a node number to each module installed in a mounting base...:angr:

 

[a093619]

Thanks for your quick response, I have just now been able to return to this subject.

You stated "When the SAA command is set". Where/How inside of RSNetworx can that command be initiated other than from the tool submenu?

Thanks in advance

 

[dmargineau]

The SAA feature is related to the 1734-ADN "Auto Start Mode" and is specific to DeviceNet Point I/O hardware.
The Auto Start Mode is Parameter #6 of the 1734-ADN module and is accessed via Online RSNetworx for DeviceNet while within the 1734-ADN Properties Applet.
It is a tool for efficient comissioning of Point I/O DeviceNet networks however, it might trigger issues such as the one you have experienced.
Refer to http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1734-um002_-en-p.pdf
At page 3-11 the Auto Start Mode comissioning is explained in detail.
A "Do Nothing" setting for Parameter #6 should be implemented after the comissioning has ended.

 

[a093619]

Thanks dmargineau for the quick response. I agree that the "Auto Start Mode" function of the 1734-ADN could cause the issue I am seeing. However, I am using a 1734-PDN as my Devicenet communication interface device and don't believe that it has the Auto Start Mode feature.

Thanks in advance

 

[dmargineau]

I have yet to sub-net Point I/O on DeviceNet; probably never will or, if ever summoned to do so, I would probably use a DeviceNet adapter such as the 1734-ADN or ADNX.
The 1734-PDN is "transparent" to the main network, non-configurable and relying on the Scanner's Scanlist configuration and the individual Point I/O modules settings one of which is the Sequential Auto Addressing.
I do not have a live, branched, Point I/O DeviceNet network hence not being able to research the Properties of the digital Point I/O modules on the sub-net; maybe you could do it and verify if the SAA "feature" is enabled on one or any of the troublesome Point I/O modules;(refer to http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1734-um001_-en-p.pdf)
It surely looks like this "efficiency feature" of the DeviceNet Point I/O hardware is the culprit; again, "branching" via a non-configurable bridge such as the 1734-PDN will most likely open-up another huge can-of-worms since the "static" settings of the modules attached to the PDN communications adapter will be permeable to any network traffic since there is no present (configurable) "enforcer".

 

[Ken Roach]

In decreasing order of likelihood:

1. The other programmer intentionally or unintentionally commanded SAA on one of the modules in the system.

2. SAA was commanded but didn't take effect until DeviceNet power was cycled.

3. Somebody performed a "download to network" with different Node Numbers set for some of the modules, which didn't take effect until the power to the 1734-PDN was cycled.

I couldn't be totally sure from the original posts exactly when, or if, the DeviceNet power was cycled. Most devices don't apply their DeviceNet identity object, including the MAC ID, until they have undergone a power cycle or device reset.

I don't have a bunch of DeviceNet or POINT I/O stuff handy to test this out, but I am certain that SAA doesn't just run without being commanded, and that the 1734-PDN doesn't have any ability to reconfigure the devices that are connected to it.