Cutler Hammer WPONIDNA DeviceNet

[dalporto]

Hi.


We're planning ahead a cut-over (segregating some IOs on a new PLC) on a MCC Advantage Starter DeviceNet Modules which I'm 98% sure they are Cutler Hammer WPONIDNA modules (probably installed 20 years ago). The MCC is powered and the DWG aren't up to date, so I cannot confirm at the moment.


I found a picture of the module but cannot find the manual since it's been long replaced by Eaton C441 DeviceNet Modules.


It doesn't looks like you can set the Node address with switches from the pictures I saw. Do I need a software to set the addresses? If it's the case, what would it be? Also, any idea of the end of line resistance needed to close the daisy chain?


Thanks.

 

[plvlce]

I can't speak to anything regarding these specific modules, but the DeviceNet spec calls for a 121Ω termination resistor at each end of the trunk cable.

 

[dalporto]

Thanks. Make sense.

 

[Bit_Bucket_07]

It doesn't looks like you can set the Node address with switches from the pictures I saw. Do I need a software to set the addresses? If it's the case, what would it be?

I did a couple of systems back in the '90s with CH DeviceNet, but honestly, I don't recall very much about them. I do know that you can't configure the addresses with switches. I had a software package and a PCM-CIA card with a cable that would connect directly to the DN network for device configuration.

Maybe this document will be helpful?
https://www.eaton.com/ecm/groups/public/@pub/@electrical/documents/content/985139392063.pdf

 

[Ken Roach]

The WPONIDNA came out of the box at Node 63 like most devices, but the DeviceNet Object (including MAC ID and Data Rate) can only be configured over the network with a configuration tool like C-H Net View, or RSNetworx for DeviceNet's node commissioning tool.

C-H and A-B networked MCC's were generally set up by connecting one device at a time, verifying its serial number or connected device type, setting the DNet Object, then cycling power to verify that the configuration succeeded.

 

[dalporto]

Thank you very much guys.


I'm waiting for the customer to send its .dnt config (RSNetwork) to know more about how it's done and how it looked, I never open that before.


I thought that every starter needed a Node number like the IO Flex drops.



Plugging them one after the other makes a lot of sense then.

 

[dalporto]

The WPONIDNA came out of the box at Node 63 like most devices

I found some pictures of the MetalClad. Each cell is identified with different Nodes #. The Spare ones are indeed identified with Node 63. All others are differents (got 20-25 different starters), some starter looks like they're using more than one.



What do I need to modify the node #? Is is right from the RXNetwork config (It's scanned via a 1756-DNB on a L7 backplane), or module itself needs some config?


I won't have much time available with the MCC down, so I'd like to have everything I could need ready and available.

 

[RobertMichalski]

I am glad I found your post.

 

[jgunnels]

Dalporto, i used to work with the CH Dnet WPONIDNA years ago and I have some miscellaneous info on it. PM your email and I can send to you.


Joe

 

[dalporto]

I received the .dnt files from the customer.


The one I'm most interested in is the one pictured in the screen shot at the bottom. Some of you should even be able to understand the nature of what I'm dealing with from the descriptions but that's not the point, no sensitive information there.


Basically, they're polling all of that from one PLC, I need now to segregate Node 20 to 28 (those are the nodes, right?) to another PLC / 1756-DNB. It kind of look straightforward enough but I still have a lot of questions.


From the "new" DWG they provided, I can now tell that I was right and most of these starters are in fact WPONIDNA DeviceNet modules, but still won't have the CWD to figure the order they're connected.




-For background, we're reprogramming 2 X L7X into 3 X L8X (not sure why yet) and some of the MCC stuff belongs now in the new 3rd PLC;


-Let start with let say Node 20, Penstock Dewatering Pump. From the RSNetworx config it's Node 20). In PLC, I'm looking at location like Local:5:I.Data[30].X for 4 DI, So there is probably somewhere in RsNetWorx I can find that remap. I don't know where it is declared. I'm kind of getting the idea for the IO Flexs, but are the WPONIDNA addresses static so it's always the same structure? (Fault, Running, Ready, Auto);


-Is there a way to associate the .dnt with the actual PLC program? Or is it 2 completely separated instances that doesn't belong together?



-Nodes are looking like they are already assigned. Would it have any incidence if I switched the position (I mean wiring here) between 2 of them. This is a parallel daisy chain with addresses on each device, so my guess would be that the actual devices order / position in the chain doesn't matter at all. Am I right?


-Someone mentioned that serial number are used when attributing a Node or something like that. Question A)Do we configure node # using RSNetWorx or is is another software? B) Is the Node "aligned" with a serial number or it's just a device with a node # on the network? My understanding is that when the cut-over is done, I just need to re-use the same Nodes as they are "registered" into the devices, but since it's a new .dnt config, I'm not confident with it. I won't have access to any of that before the cut-over outage, so I want to be prepared;



-I have a lot of warnings right now and also when I try to "open" a Device:


"The device at address 04 has been redefined to use a different applet. Since the device's configuration could not be maintained, it has been reset to the default values."


and


"The device at address 28 is not registered on this computer."


Will it be an issue at some point?


-I know there are "EDS" files that are associated with that kind of setup. I found some related to those Cutler-Hammer DeviceNet Starters devices. I haven't worked with Rockwell / AB in a while so I'm not sure what is the purpose of those, but my guess is that is pretty important to make it work.


-Any insight on what to look for, how to proceed or what I missed that would be a show stopper when on site?



I'm asking a lot I know. If you have questions regarding Unity Pro, Citect or Vijeo Designer, I may can help you until I become more fluent with Rockwell.




Thanks.

 

[Bit_Bucket_07]

I do recall some annoying issues with the CH DeviceNet MCCs. The motor starters actually communicated via an existing 9600 baud rate serial bus technology, and the clip-on DeviceNet modules were actually functioning as gateways to that older serial network. There was significant lag in response time. This was made worse if power was removed from one or more of the starters (as in the case of a safety interlock) because while the DN PONI module can report its node number to the DN Scanner so long as DN has its own DC voltage present, it couldn't identify anything else about itself. This leads to unnecessary polling by the DN Scanner in an attempt to identify these undefined nodes.

Even when everything on the DN network was up and running normally though, there was significant lag. the starters were unfit for attempting brief jog operations with any repeatability.

 

[dalporto]

From what I saw, 24VDC is jumped from 1 device to another and so on.


There is a connector between the starter / overload relay to the PONI module. It is unclear which one powers which one (on a comm level). My understanding is that while the starter DC is down, PONI would still be powered if the chain coming from the 1756-DNB is still alive (anyway if it's down, every PONI is down), and that would only lead to an unavailable device.



So what you're telling is if one starter in the chain, is down, that could cause lag in the remaining of the chain (before or after) because the DeviceNet node would be proprietary of the starter itself instead of the DeviceNet module? Is that correct?

 

[Bit_Bucket_07]

From what I saw, 24VDC is jumped from 1 device to another and so on.


There is a connector between the starter / overload relay to the PONI module. It is unclear which one powers which one (on a comm level). My understanding is that while the starter DC is down, PONI would still be powered if the chain coming from the 1756-DNB is still alive (anyway if it's down, every PONI is down), and that would only lead to an unavailable device.



So what you're telling is if one starter in the chain, is down, that could cause lag in the remaining of the chain (before or after) because the DeviceNet node would be proprietary of the starter itself instead of the DeviceNet module? Is that correct?

That happened to me, using a Horner Electric DN Scanner on a GE Fanuc 90-30 PLC.

It might be worthwhile for you to simply ditch the obsolete PONI modules and replace them with AB DeviceNet interfaces.

 

[dalporto]

It might be worthwhile for you to simply ditch the obsolete PONI modules and replace them with AB DeviceNet interfaces.

When we bidded (past tense of bid? bided? bid? Sorry, french canadian) on the project, the spec was unclear. It still is, it is the most unclear spec I ever saw.


So we wanted to propose two options. Option A Rockwell like they have, and Schneider like we want it to be.


We knew we would have at least 3 IO Flex drops to replace with M580 CRA or even PRA drops depending on what was in there. Even with the engineering and the drawings and the construction, we would have cover for that just with the hardware expenses (Rockwell backplane alone is 2.5-3 X more expensive than SE).


There is also the question of the screens. There is one "local" InTouch screen using something I don't know that I just received an answer from a RFI today, talking Ethernet Ip over another layer (I'm gonna start another tread about this once I looked at the RFIs). And there's a random "remote control" talking Modbus over a GE Fanuc used as a Gateway for whatever reason.



Main problem was what we didn't know back then, and that was confirmed 3 months after we won the bid. The PONI.


Anyway back then I talked with Schneider about a way to communicate with DeviceNet on a Schneider setup (because control center is Modbus anyway). The solution was a third party layer. So we ditched option 2. Now I'm thinking that maybe it would have been easier to do that anyway.




SO, sorry for the long message, it's like a coping mechanism to reset my head and give a little overview of the thing.



But my question is, when you say "to simply ditch the obsolete PONI modules and replace them with AB DeviceNet interfaces";


Can PONIs be replaced one for one with a new Ethernet IP module over the same starter?

 

[Bit_Bucket_07]

When we bidded (past tense of bid? bided? bid?
Can PONIs be replaced one for one with a new Ethernet IP module over the same starter?

You could use the AB E-300 DeviceNet overload relays to control the starters. It would require some re-wiring.