When configuring the WPONIDNA at Node 63, it is essential to ensure that each cell is correctly identified with the correct Node number. While some devices like the MetalClad may have Spare nodes designated as Node 63, each other node should have a unique identifier. It is crucial to determine whether modifications to the Node numbers need to be made in the RXNetwork configuration or directly on the module itself. This device is scanned via a 1756-DNB on a L7 backplane, so setting up the correct configuration is vital. To avoid extensive downtime with the MCC, it is recommended to have all necessary resources and information readily available in advance.
I am thrilled to have come across your insightful article.
- 19-08-2024
- RobertMichalski
A few years back, I had the opportunity to collaborate with the CH Dnet WPONIDNA team and gathered some useful information. If you're interested, please send me your email through PM and I'll be happy to share it with you. Looking forward to connecting, Joe.
I have received the .dnt files from the customer, with a particular interest in the one shown in the screen shot at the bottom. While some details in the descriptions may hint at what I am working with, the focus is on non-sensitive information. The task at hand involves segregating nodes 20 to 28 from one PLC to another PLC / 1756-DNB. Despite the seemingly straightforward process, I am left with numerous questions.
From the recently provided "new" DWG, it is evident that most of the starters are WPONIDNA DeviceNet modules. However, determining the order in which they are connected remains a challenge. The project involves reprogramming from 2 X L7X to 3 X L8X and integrating some of the MCC components into the new 3rd PLC.
Starting with Node 20, identified as the Penstock Dewatering Pump in the RSNetworx config, I am looking at specific locations within the PLC. While I have a concept of the IO Flexs, I seek clarity on the static nature of WPONIDNA addresses and their structure.
Concerns arise regarding the association between the .dnt files and the actual PLC program. Are they distinct entities, or is there a correlation between the two? The assigned nodes appear to be fixed, prompting the question of implications if the position within the chain is altered.
Queries surface regarding the configuration of node numbers using RSNetWorx and the relationship between nodes and serial numbers. In preparation for the cut-over outage, ensuring the retention of registered nodes is vital, given the transition to a new .dnt configuration.
Furthermore, warnings indicating device redefinition and registration issues raise concerns about potential challenges. Exploring the role of EDS files linked to the Cutler-Hammer DeviceNet Starters devices is essential for seamless functionality.
In the midst of these complexities, guidance on identifying critical aspects, navigating the process, and addressing any overlooked elements would be invaluable for a successful on-site implementation. While my familiarity lies more with Unity Pro, Citect, or Vijeo Designer, I am open to assisting with any queries within the Rockwell domain as I enhance my expertise in this area. Thank you.
Some common issues I encountered with the CH DeviceNet MCCs involved communication delays and lag in response time. The motor starters utilized a 9600 baud rate serial bus technology, with the clip-on DeviceNet modules serving as gateways to the older serial network. Removing power from one or more starters, such as for a safety interlock, exacerbated the situation as the DN PONI module could only report its node number and not further details without its own DC voltage. This resulted in the DN Scanner continually polling to identify these undefined nodes. Even under normal operating conditions, there was still significant lag in the system, rendering the starters unsuitable for reliable brief jog operations.
It appears that a 24VDC connection is passed from one device to another in a series. A connector links the starter/overload relay to the PONI module, but it's unclear which one powers the other at a communication level. If the starter DC fails, the PONI module may still receive power as long as the chain connected to the 1756-DNB remains operational. However, if the chain goes down, all PONI modules will be affected, resulting in device unavailability. Essentially, if one starter in the chain malfunctions, it could potentially impact the entire chain due to the DeviceNet node being tied to the starter rather than the DeviceNet module. Is this understanding accurate?
dalporto explained that in the system, 24VDC is passed from one device to another through connectors. There is a connection between the starter/overload relay and the PONI module, but it is unclear which device powers the other on a communication level. It is believed that even if the starter DC is offline, the PONI module would still receive power if the connection from the 1756-DNB remains active. However, if the connection is lost, all PONI modules would be affected, leading to device unavailability. This suggests that if one starter in the chain fails, it could cause delays in other parts of the chain, as the DeviceNet node would be tied to the starter rather than the DeviceNet module.
A similar situation occurred when using a Horner Electric DN Scanner with a GE Fanuc 90-30 PLC. It could be beneficial to consider replacing the outdated PONI modules with AB DeviceNet interfaces.
Bit_Bucket_07 recommended considering replacing outdated PONI modules with AB DeviceNet interfaces for improved efficiency.
During the bidding process for the project, the specifications were unclear then and remain unclear now, presenting a challenge. We proposed two options: Rockwell, similar to the existing setup, and Schneider, in line with our preferences. The plan involved replacing at least 3 IO Flex drops with M580 CRA or PRA drops. Despite anticipated expenses for engineering, drawings, and construction, the cost of Rockwell hardware alone is significantly higher than that of SE hardware.
An issue arose with the screens, particularly with one local InTouch screen utilizing an unfamiliar Ethernet IP setup. Additionally, a remote control communication through Modbus over a GE Fanuc as a Gateway added complexity.
The unexpected discovery of the PONI modules three months post-approval complicated matters. Discussions with Schneider led to a solution involving a third-party layer for communication with DeviceNet on a Schneider system, ultimately leading us to dismiss option 2.
In hindsight, it may have been more straightforward to follow through with the original recommendation of replacing PONIs with new Ethernet IP modules. Apologies for the lengthy message - sometimes a detailed overview helps clarify thoughts. Can PONIs be replaced individually with Ethernet IP modules on the same starter, as suggested?
Dalporto asked if PONIs can be swapped out with new Ethernet IP modules on the same starter. Can AB E-300 DeviceNet overload relays be used to control the starters instead, with some re-wiring necessary?
Unfortunately, it seems like I have no choice but to stick with the PONIs. Thank you, regardless.
Dalporto mentioned the past tense of 'bid' can be confusing - it is simply 'bid' regardless of the meaning. However, for the meaning of 'utter' or 'command', the archaic form 'bade' (pronounced like 'bad') can also be used.
Dalporto mentioned that they are stuck with PONIs, but there may be ways to make them work. Eaton provides migration options for legacy DeviceNet systems that could be helpful in this situation. Good luck with finding a solution! Learn more about Eaton's migration options here: https://www.eaton.com/content/dam/eaton/...assist-devicenet-migration-pa042005en.pdf.pdf
Hello everyone, I have an existing IOFlex drop with 4 modules installed. I have noticed 2 bytes at the beginning that appear to show statuses from the rack before the first DI Module mapping commences. In the PLC, I am seeing the following: "Local:5:I.Data[0].0 - Flex IO Node 1 Module 0 Status," "Local:5:I.Data[0].1 - Flex IO Node 1 Module 1 Status," "Local:5:I.Data[0].2 - Flex IO Node 1 Module 2 Status," and "Local:5:I.Data[0].3 - Flex IO Node 1 Module 3 Status." These 4 bits seem to indicate the failure status of each module.
I also observe the first DI starting at Local:5:I.Data[0].16. I am curious about what other information could potentially be extracted from the remaining part of the structure (4-5-6-7-8-9-10-11-12-13-14-15). While I am unsure if more than 4 modules can be accommodated in that rack, I am assuming that these would be statuses for additional modules. My main goal is to monitor the communication status with the rack (1756-ADN) itself, as a module failure will not be indicated if the rack is not communicating.
Although there are some standard statuses available from the slot structure, I am seeking more comprehensive information. Thank you.