jeffersm

MrPLC Member
  • Content count

    24
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jeffersm

  • Rank
    Sparky

Contact Methods

  • ICQ 0
  1. 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.
  2. 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?
  3. 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?
  4. 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?
  5. 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)
  6. A Rockwell Field Service Engineer was here this past Saturday. He checked the signals on the Control Net and found them to be normal. He inspected the connections of the cabling and saw some problems with the way they were installed and replaced all the connectors. Also in the process of replacing them, he noticed that there was some oxidation on the center conductors of some of the cables, but didn’t think that it would cause a problem especially since the signals look good. We will be replacing them all just to make sure. Also he had said the replacements must be AB or Belden ControlNet cable. What is currently installed is another brand of RG6 quadshield that is labeled as ControlNet cable. The cable that I had tried as areplacement when we first started seeing this problem was regular RG6 which didn't solve the problems we were seeing, so I switched back to using the origionally installed ControlNet cabling after repairing one of the cable ends. Next he upgraded the firmware of the ControlNet bridge from 10.7 to 11.4. Also when he checked the AB firmware compatibility table he found that the firmware of the 1794-ACN15/C node adapters which were at 5.1, 5.2 and 5.2 were not compatible with the firmware in the PLC CPU which is 16.7. He downgraded all of them to 4.3. We cycled the system for about 30 to 40 minutes and we got a fault on node 4 which is the origional problem. Next he change the network schedule from 5 mS to 3 mS and the problem node interface and high speed counter also to 3 mS. Prior to that, everything was at 5 mS. We cycled the machine for about 1.5 to 2 hours and we got a fault. (I can’t say for sure if the problem is better as the amount of time between faults has always been highly variable.) I notice that all the status lights were green after a fault, but in the ladder logic that is checking the status word of the 1794-ACN15/C node adapters a 255 is being recorded and the fault counter incremented. Today I did some additional cycling of the machine and again it faulted after about 1.5 to 2 hours. This time I saved the program when the fault occurred to save the tag values. Also I checked the 1794-ACN15/C node adapters and high speed counter properties after the fault occurred. The node adapter says: it has a minor fault that was recoverable, and that there was a mismatch. I went and changed the version in RSLogix from 10.7 to 11.4 to match the new firmware. The High speed counter listed an “Unexpected Module” fault. This may be related to the problem, but I don’t know what it means. Attached are the screen captures of what I saw today. Any recommendations on what we should try next?
  7. Origionally it was set to Compatible Keying, but I received a recommendation to change it to Disable Keying to try to avoid the fault. Changing the keying did not prevent further faulting. I will put it back to the origional setting this weekend.
  8. Hi dmargineau, Sorry for taking so long to get back to you. Attached are some RSLogix screen shots of what I see related to the mismatch: In the general tab of the 1794-ACN properties, the revision is listed as 3.1 and I can only change the minor (.1) and not the major number. In the module info tab of the 1794-ACN properties, the revision is listed as 5.2 and also says mismatch.
  9. I do have version 16.03 of RXLogix installed on the PC and that is what starts up when I load the software for this PLC. I just meant that I have upto version 17.01 on the same PC.
  10. Correction: The project running on the CPU is V16.03.00 (CPR 9) The RSLogix installed on my PC is V17.01.00 (CPR 9 SR 1)
  11. Hi dmargineau, The RSLogix is V16.03.00 (CPR 9) The CPU is a 1756-L61 with revision 16.7 The RSNetworx for ControlNet is 9.00.00 (CPR 9) Flashing the CNet bridge didn't correct the problem
  12. Hi Shiner, That sounds like a great idea. We have a lot of places where we could use them. Where can I find them and how are they called. I have seen many coolers, but never driers. How do you seal the wireway or conduit entrances to create a positive pressure?
  13. Thanks dmargineau, I tried your recommendation but in reverse. I switched the trouble node flex io adapter with its neighboring node which has been trouble free. I went to the site you recommended, but din't find a ver 5.2 which is what one of the nodes is and the other 2 are 5.1. I was able to download the 5.1 though. I then used the EDS wizard with the find an download option and update the EDSs. Checked that all said they were updated with 5.1 file. Then updated EDS on all flex io. The mismatch I am seeing is actually in all the flex io adapters and is only reported in RSLogix. RSNetworx does not report any problems except when I run diagnostics. It complains about a minor watch dog fault in the cpu execution. The problem continued after this change. I just changed the CNet bridge from one with ver 5.001 FW to 10.007 FW and reoptimized. I will wait and see if it gives better results.
  14. Hi all. Today when I saw the problem happen again I noticed that the status light on the last 1794-ACN15/C in the chain had changed from green to red. I was able to reset it by disconnecting the tap. Our expert in headquarters is recommending to reflash the firmware of the ControlNet card. When I check the properties of the various interfaces, this is what I see: According to the report that RSNetworx produces, the revisions are: Node 1(1756-CNB/D): 5.038 Node 2(1794-ACN15/C): 5.001 Node 3(1794-ACN15/C): 5.002 Node 4(1794-ACN15/C): 5.001 According to RSLogix the revisions are: Node 1(1756-CNB/D): 5.38 Node 2(1794-ACN15/C): 5.1 Node 3(1794-ACN15/C): 5.2 Node 4(1794-ACN15/C): 5.1 According to RSLogix the versions are: Node 1(1756-CNB/D): 5.1 Node 2(1794-ACN15/C): 3.1 Node 3(1794-ACN15/C): 3.1 Node 4(1794-ACN15/C): 4.1 Also in the device properties module in the module identity field, all of the 1794-ACN15/C are listed as mismatch. Checking with the area Technicians, this node has always been problematic for years, not just the month or so that I thought it was. Lately it seems to be worse though. Any recommendations?
  15. We have many installation with Iconics Genesis 32 versions 8 to 10 and have the problem that it becomes unresponsive or looses communication with PLC. When this happens the operators will perform a hard reset to reboot windows since their security level doesn't give them access to the start menu to perform a soft restart start. Our development expert in headquarters is telling us that that the unresponsiveness and loss of communication is probably due insufficient number of tags and that we need to upgrade the licenses to solve the problem. I don't have enough of the details behind his reasoning to be able to judge if it makes sense or not. One thing that I have noticed is that in the PLC ladder logic were the HMI tags are updated, there are no conditionals to perform the writes only if the tag value in the PLC is changed. This means that all tags look like they are written to the HMI on each PLC scan. Could this be overloading the HMI? Also is there a way to add a button to Iconics that will restart the HMI application or windows?