ControlNet issue

[ObnoxiousWatermelon]

Hey everyone, looking for advice in this particular scenario.

Currently we have a controlnet bus that has (6) CN2DN devices and (2) powerflex 700's. We have had a few events where we lose multiple CN2DN devices, but the rest stay up including the vfds. Connected to the CN2DN are mostly E3P overloads. We tested the bus by disconnecting at different spots in the loop - disconnecting the 'A' bus and watching how the network reacts to try and replicate the issue. Typically, if we disconnect 'A' Bus everything switches over to 'B' bus. But there are a few instances where depending on the location in the bus we disconnect, a few nodes drop out.

To clarify what's actually happening, I am fairly certain that the CN2R/B card isn't throwing a fault. What is throwing the fault is the CN2DN devices. It looks like the AOI we have looks at the CN2DN Device failure registers, along with a msg instruction (CIP Generic) pointing to the f0 Instance 1 Attribute 83 to determine if there is a fault on the CN2DN.

If there is any more information required to help point me in the right direction please let me know.

 

[AlfredoQuintero]

Hello, so I read this post in the morning, probably a few minutes after you posted it, and I though at least about two forum members with hugely far more expertise than me on this issue. But since I do not read their post, maybe I give you a little bit of information of a issue I had decades ago. I am speaking from memory and have not worked with ControlNet in over a decade, so this may or may not help you, and you will have to forgive my less than precise terminology as I am not someone with electrical background.

I worked at the time for a board maker who had a ControlNet scanner/adapter board for use with a number of applications, one of which was robot arm controller for spot- and arc-welding. The interface was in the robot controller backplane, sitting right on by the side of the robot's motion control cards, all of them communicating though a internal bus to the robot controller. The noise from the robot motion control device was such that it would jump out to the ControlNet bus causing so many errors as to render communication impossible. I am not so familiar with the physical layer of ControlNet, so please bear with my language. We got support from Rockwell and somebody recommended the engineering company which designed the line to wire all of the ground for the ControlNet interface in all of the robot for the line, which was several dozens, to a single ground point in the building. So, on top of the ControlNet media, there was an additional wire connecting all the robots ground to this single point. Low and behold, this fixed the problem according to my memory.

Maybe before trying anything like the above, it might be helpful to try to access the error counters in the ControlNet interfaces to see if you get an unusual error counts. I do not remember the ControlNet specification and my company does not have a subscription for that specification, but the Rockwell documentation must have this documented. Needless to say, a good network should have very low rate of increase of errors. If the errors increase too wildly, there is no software fix. You would need to try fixing the grounding, I think.

 

[Ken Roach]

How do the 1788-CN2DN's come back on line ? Do they recover spontaneously or require a manual reboot or a re-schedule of the ControlNet, or something else ?

Your system could have more than one problem. You could have some bad media or noise on Channel B. And you could have something that's causing the 1788-CN2DN's to reboot or disconnect from the ControlNet at the same time, like a shared DC power supply that dips below the necessary operating level (probably 18V on those units). You might have a big load or voltage discharge on a DeviceNet that's interrupting that network so hard that it actually propagates to the ControlNet.

I've seen a lot of systems that power the 1788-CN2DN from the DeviceNet network power supply. While it works, you lose the benefits of isolation and independence between those components of the system.

I don't remember if the classic 1788-CN2DN had removable CNet and DNet daughtercards like the FlexLogix did or if everything was fixed in place. Corrosion or wear would probably not affect them all at the same time.

Diagnostics might include polling the ControlNet media counter objects from all the nodes on the network and looking at whether they rise at certain times.

When I did this kind of work I had a ControlNet signal meter that let me separate out individual node broadcasts to an oscilloscope, and gave me some LED indications about signal quality at each node number. It used that in conjunction with the media counter and status objects. Lots of GSV and messaging to objects I had to look up in the protocol spec.

 

[Ken Roach]

I went back and checked and the 1788-CN2DN definitely had a separate control power supply (on top) and didn't take its logic power from the DeviceNet. You could run them connected to ControlNet even when the DNet power was shut off.

 

[ObnoxiousWatermelon]

Hello, so I read this post in the morning, probably a few minutes after you posted it, and I though at least about two forum members with hugely far more expertise than me on this issue. But since I do not read their post, maybe I give you a little bit of information of a issue I had decades ago. I am speaking from memory and have not worked with ControlNet in over a decade, so this may or may not help you, and you will have to forgive my less than precise terminology as I am not someone with electrical background.

I worked at the time for a board maker who had a ControlNet scanner/adapter board for use with a number of applications, one of which was robot arm controller for spot- and arc-welding. The interface was in the robot controller backplane, sitting right on by the side of the robot's motion control cards, all of them communicating though a internal bus to the robot controller. The noise from the robot motion control device was such that it would jump out to the ControlNet bus causing so many errors as to render communication impossible. I am not so familiar with the physical layer of ControlNet, so please bear with my language. We got support from Rockwell and somebody recommended the engineering company which designed the line to wire all of the ground for the ControlNet interface in all of the robot for the line, which was several dozens, to a single ground point in the building. So, on top of the ControlNet media, there was an additional wire connecting all the robots ground to this single point. Low and behold, this fixed the problem according to my memory.

Maybe before trying anything like the above, it might be helpful to try to access the error counters in the ControlNet interfaces to see if you get an unusual error counts. I do not remember the ControlNet specification and my company does not have a subscription for that specification, but the Rockwell documentation must have this documented. Needless to say, a good network should have very low rate of increase of errors. If the errors increase too wildly, there is no software fix. You would need to try fixing the grounding, I think.

Thanks for the reply! We have taken a look at Rsnetworx for controlnet, but it seems that the software is a bit difficult to use (could be error on my part). We used it in conjunction with our tests, but found when disconnecting the 'A' bus it didnt seem to refresh itself and still showed a healthy network. Have you used the 1788-CNCHKR before?

 

[ObnoxiousWatermelon]

How do the 1788-CN2DN's come back on line ? Do they recover spontaneously or require a manual reboot or a re-schedule of the ControlNet, or something else ?

Your system could have more than one problem. You could have some bad media or noise on Channel B. And you could have something that's causing the 1788-CN2DN's to reboot or disconnect from the ControlNet at the same time, like a shared DC power supply that dips below the necessary operating level (probably 18V on those units). You might have a big load or voltage discharge on a DeviceNet that's interrupting that network so hard that it actually propagates to the ControlNet.

I've seen a lot of systems that power the 1788-CN2DN from the DeviceNet network power supply. While it works, you lose the benefits of isolation and independence between those components of the system.

I don't remember if the classic 1788-CN2DN had removable CNet and DNet daughtercards like the FlexLogix did or if everything was fixed in place. Corrosion or wear would probably not affect them all at the same time.

Diagnostics might include polling the ControlNet media counter objects from all the nodes on the network and looking at whether they rise at certain times.

When I did this kind of work I had a ControlNet signal meter that let me separate out individual node broadcasts to an oscilloscope, and gave me some LED indications about signal quality at each node number. It used that in conjunction with the media counter and status objects. Lots of GSV and messaging to objects I had to look up in the protocol spec.

Thanks for the reply!

The CNDN's come right back up, which is part of the problem as we can't troubleshoot the network during the upset.

I believe the CN2DN's have redundant DC power supplies, that is something we could check.

As for diagnostics, is there a good way to do this? I havent had much luck using RSnetworx for controlnet(and cant find much for documentation). It seems that the software was quite inconsistent to indicating faults when the CN2DN was actually showing a fault in the field during our tests.

When you say controlnet signal meter, are you refering to the 1788-CNCHKR? I was looking to purchase this but they are obsolete unfortunately.

One other thing about the scenario. Here is the example:
We would spot check the bus by disconnecting the 'A' bus and watch what the network would do. In one case, we disconnected 'A' bus - knocking down a CN2DN (we would see a blinking green light on the 'B' bus indicating bad signal). We then disconnected the 'A' bus at a tap close to the CN2DN that went down, and the 'B' bus came back online solid green.