Sign in to follow this  
Followers 0
jeffersm

ControlNet problems on ControlLogix5000 system

38 posts in this topic

Maybe we are (slowly!) getting somewhere... How many modules are attached to Node 4 of your CNet network? The fault you are experiencing is related to the "digital signature" of the High Speed Counter Module which is not being "seen" as what is is by the Keeper bridge, due probably to bandwidth issues. Correct me if I am wrong: Previously, the CNet NUT (Network Update Time) was set to 5ms AND the 1794-VHSC connection RPI was also set at 5ms. What was the RPI of the Node 4 1794-ACN? Currently, the NUT is set at 3ms and the RPI of the VHSC module is set at 3ms. What is the current setting of the Node 4 CNet adapter RPI? I believe you are just overloading the network by requesting of such low RPI from a single module. If your application is demanding such precise positioning, maybe you will have to implement some sort of Motion Control Sub-System for the project area "serviced" by the 1794-VHSC. It is quite a major undertaking, however, until making the final decision, you could try INCREASING the RPI of the High Speed Counter AND the RPI of the Node 4 Adapter. Observe if the Fault condition repeats at a lower rate. If it does occur less often, you might be able to find a ACN/VHSC RPI value high enough to ensure the proper functionality of your system. A CNet node dedicated entirely to the 1794-VHSC might be another option that could alleviate the bandwidth issues. If the media verified to be okay and the signal strength seems to be fine, the issue has to be related to a "too demanding" schedule...

Share this post


Link to post
Share on other sites
The connections are as follows: Origional configuration when problems first started occuring: Node 1: CNet Bridge (NUT = 5 mS) Node 2: CNet adapter, 2 VHSC, 5 discrete I/O (all RPI= 5mS) Node 3: CNet adapter, 2 VHSC (all RPI= 5mS) Node 1: CNet adapter(RPI= 20mS) , 1 VHSC (RPI= 5mS) I tried the following configuration since the above seemed odd : Node 1: CNet Bridge (NUT = 5 mS) Node 2: CNet adapter, 2 VHSC, 5 discrete I/O (all RPI= 5mS) Node 3: CNet adapter, 2 VHSC (all RPI= 5mS) Node 1: CNet adapter, 1 VHSC (all RPI= 5mS) (band width usage was about 20%) The Rockwell Field engineer changed the speeds to the following on Saturday, April 16: Node 1: CNet Bridge (NUT = 3 mS) Node 2: CNet adapter, 2 VHSC, 5 discrete I/O (all RPI= 5mS) Node 3: CNet adapter, 2 VHSC (all RPI= 5mS) Node 1: CNet adapter, 1 VHSC (all RPI= 3mS) (band width usage was about 37%): Today we had 2 Rockwell Field engineer troubleshooting and they found that the bridge CPU utilization was at 95% to 100% so we rescheduled to: Node 1: CNet Bridge (NUT = 5 mS) Node 2: CNet adapter, 2 VHSC, 5 discrete I/O (all RPI= 5mS) Node 3: CNet adapter, 2 VHSC (all RPI= 20mS) Node 1: CNet adapter, 1 VHSC (all RPI= 20mS) Now the bridge CPU utilization is at 52% (band width usage was about 10%) Timing is very critical in this application as to the relationship between opening and closing a valve to inject a precise amout of solution into IV bags at 10 independat stations, but the VHSC controls those vales directly and measures the volume by counting turbine pulses. This is done independant of the network, I don't think there is a problem with increasing the RPI for precision. I just have to make sure that the production capacity is not affected by this change. (see attached before and after bridge cpu utilization) We also observed that although the noise measurements said everthing was OK, whaen a fault occured, the network complained about noise. (See attached)

Share this post


Link to post
Share on other sites
After running less than an hour the fault is still occurring. Our engineering group up in headquarters is recommending to switch to Ethernet IP. Based on the noise warning errors from the CNB, it seems that there is some kind of sporadic noise even though the measurements this past Saturday found nothing. Even with very little running in the plant I was still getting the fault on Saturday and Sunday. The only auxiliary equipment that I was running then were three vibratory feeding bowls. All the local motors were shutoff. I'm starting to think that a 120 VAC bowl coil could be arcing. A couple of weeks ago we started having a problem with one of them blowing its 10 Amp fuse. These bowls run continuously and are not controlled by the PLC but have their wiring running through the same cabinet as Nodes 2 to 4 are located in. I will try to check the current draw on the bowls to see if the problem one is drawing more current, check with the bowl supplier to find out how to get at the coils individually to measure them. It would be nice to have an oscilloscope now to try to capture this event. Has anyone tried the Pico Scopes or anything similar that are PC based scopes?

Share this post


Link to post
Share on other sites
CNet electrical noise has always been pretty much the only "evil" within a generally efficient and reliable industrial communications network. We've experienced major issues with CNet/VFD applications, especially the latest generation, high (agile) PWM output ones. Since Ethernet is not always an option, when deterministic data transfer is mandatory Cnet is stil THE ONLY WAY TO GO! Parallel CNet and VFD line side runs are a major "No-No" even if in burried separate conduits. If "close" proximity is a given, 90 deg. "crossovers" between the CNet media and ANY variable frequency or variable load lines are a must. The vibratory feeders could be the culprit, at least the "acting up" one. If there is ANY way to route either the CNet media or the vibrators feed lines as far away as possible from each other you should try to do it if deciding to keep the CNet. Also, if the vibrators and the controls are sharing the same supply power you should consider the installation of an isolated Control Power Supply dedicated exclusively to the control side of your application. Good grounding is also a major component of any trouble free control system. I know sometimes it sounds like a broken record, however, time and time again it proves to be true.

Share this post


Link to post
Share on other sites
For what it's worth, I had a nearly identical problem on a traveling frame loader here. It was driving me crazy. In the end, I changed out the coax from the "High Flex" version to standard ControlNet cable, and all of my problems went away. I also did run the new cable avoiding any clamp that pinched it. The original cable was held in place by cable clamps, and some of them were squeezing the cable down and deforming it.

Share this post


Link to post
Share on other sites
The network performs the same data transfers whether the vibratory bowl feeders are on or off. Have you had a chance (e.g. a shutdown) to determine if the network still reports noise when the feeders are turned off ? I strongly believe your problems are caused by the ControlNet cable, it's installation, and the connections. As you have had water ingress to the cable, then it will have changed the dielectric characteristics of the spacing core. You may even discover that there is some water still left in the air gaps in the dielectric insulation, it will migrate quite a distance due to the capillary effect. Can you hook-up a temporary replacement cable, routed away from any high-power circuits, and see if the problem is resolved ? As dimargineau stated, ControlNet is "a generally efficient and reliable industrial communications network", and I believe you are spending too much time and effort in trying to find fault with the nodes and network settings, when you already know that there are installation issues. Nearly all network problems, especially those that are intermittent and sporadic, can be attributed to poor installation, i.e. routing and connections. You have had successful running of the network for several hours, and in my opinion the problems are not related to network NUTs, RPIs, or faulty nodes. If this were my plant, I would have replaced any cable that shows any sign of moisture ingress (I would probably replace them all), and changed from BNC to the more robust IP67 rated connector throughout. My 2c....

Share this post


Link to post
Share on other sites
Thanks for the recommendation. I don't see High Flex written on it any where, but it does see more flexible than I expected although this is the first time I have worked with quad shield cable. I did notice that the center conductor is made up of very fine strands and the outer braid strands also seem fine compared with coaxial cables that I have worked with in the past. I think it is held in place with wire ties in several locations for neatness. We will have to make sure to avoid that in the future. Do you recommend the AB or any other particular brand of ControlNet cable?

Share this post


Link to post
Share on other sites
Will I need new tooling to install the 1786-TNC? Also are there taps with TNC connectors or will I need adapters to go from the TNC to the BNCs on the taps?

Share this post


Link to post
Share on other sites
Yes, The taps have 3 TNC connectors, you use a drop-cable with TNC one end, BNC the other. (See Picture). This also shows the use of a bulkhead connector (optional). All info taken from the ControlNet IP67 Tap and Cable Assembly Kit Installation Instructions - Publication 1786-IN017B-EN-P - May 2004

Share this post


Link to post
Share on other sites
I just requested a quote from our local AB supplier for the following: 200 ft 1786-RG6 Standard PVC CM-CL2 1 pk 1786-TNCLXT4 TNC Terminating resistor TNC plug 4 ea 1786-TCT2BD1 TNC T-tap with straight BNC drop connector 1 pk 1786-TNCL10 TNC Plug No barrels or bulkhead adapters at any point in the installation. After reading the installation manual I noticed that there is something else that is wrong. All of the cabling (120 VAC, 24VDC, and ControlNet) are run through the same 1-1/2" sanitary pipe that is about 40 feet long. The 120 VAC is used mostly for some input modules and prox switches, but also powers the vibratory bowls which draw about 5 to 10 amps each and like most bowls are run on half wave with a thyrister type current level control. The 24 VDC powers several solenoid valves. Not a good environment for the ControlNet cable. I will be requesting quotes for installing a new pipe (with generously radiused elbows) just for the ControlNet cable. This is a clean room so that complicates the installation a little. Even though I had tried testing another cable that ran outside the pipe and still got the same results, I recognize that this needs to be corrected. There might be multiple factors at play here. I think we were just lucky that it worked well for so long. On another topic:Can anyone recommend a protective cover for 15" touch screen monitors in a washdown environment? We are using AB6186M15SSTR and would like protective covering for them to prevent water from getting into them. Edited by jeffersm

Share this post


Link to post
Share on other sites
If installed properly, the monitor will meet NEMA 4X enclosure ratings - you shouldn't need a protective covering. Make sure the gasket hasn't been rolled or over-torqued. Also, consider installing a breather drain/vent. Air pressure changes inside the cabinet can draw moisture in through the gaskets. Here's a link to a Hoffman vent: http://www.hoffmanon...6&itemID=174673

Share this post


Link to post
Share on other sites
I think you have nailed it with that statement. I had previously assumed the T-taps were outside the panels, but since you haven't considered bulkhead connectors, am I now to assume they are inside? In my view you need to eliminate moisture/water ingress to the panels, there is gonna be stuff in there that will dislike the conditions far worse than the ControlNet cabling and connectors, which (if inside) wouldn't need to be changed if you keep the wet out of the panels. This isn't a no-brainer - good seals, good venting, and possibly positive pressure can and does achieve this in many a worse location than a high-pressure washdown area. All panels I have worked on have also had thermostatically-controlled heaters to stop condensation in the cold. I commend your choice to change the cable, and you now have the opportunity to relocate it to where it should be - well away from sources of EMI. - Check the same inside the panels too, and if you have to cross a high-voltage/current conductor, do so at 90 degrees. Good luck, daba

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0