Modbus Plus communications issues

[Guest boudreaub]

We have a rather large MB+ network consisting of two Citect HMI workstations, a PI interface, two 984-145 PLC's, two Quantum PLC's, 17 M1 processors, and two repeaters. The Citect and PI stations are conencted to the network via an SA85 card. Each network segment has a terminator on each end. In addition, each node is connected via the MBKT connector and daisy chained from one node to the next. Finally, the majority of hte network is wired using Belden 9841 cable, with only a couple of drops using Modicon's 490AA271XX cable. The longest segment we have is about 1200 feet. The problem I'm having is mainly with the first segment of the network, between the Citect stations and the very last node on this segment before the first repeater. The last node is an M1 processor. At the Citect workstations, I will see #COM errors in lieu of the analog data coming in from this node. This indicates communications errors wiht this particular node. I verified this in three additional ways. I first use MBPSTAT to look at the entire network, and saw that this node was showing up as unknown. In addition with MBPSTAT, I tried going to node statistics to see what was going on. What I saw was about one failure in every ten successes. Looking at what MBPSTAT was telling me, I saw several CRC and framing errors, indicating a possible cabling or connector issue. the cabling and the connector for this drop has been replaced. In fact, the cabling for the entire network has been replaced and re-rerouted two years ago to make it easier to expand on the existing network. I additionally attempted to connect to the node using Modsoft from the Citect stations. I kept getting an error. FInally, I used a laptop with a PCMCIA adapter to try to talk to the node by lifting one of the connectors from one of the Citect stations and connecting it to the laptop. Once again, I got the same errors. If I take the same laptop and systematically disconnect connectors from existing nodes and re-connecting them to the laptop. As I got closer and closer to the affected node, the communications errors would go away. When I would remove the connector from the affected node and replace it on my laptop, all communications errors would go away. I'd go back to the Citect workstations and be able to see the laptop perfectly with no errors. This is a situation that has been ongoing now for two years. I'd re-terminate the connector at the affected node, and the communications would sometimes return. I've also replaced the connector (many times), the terminators on both ends, the communications adaptor (many times), the M1 processor a couple of time, and even the I/O backplane a couple of times. Currently, I'm guessing I may have a possible ground loop here. I say this because the communications issues come and go so intermittently. The length of the error is also very intermittent (from a few minutes to several days). In addition, the affected node is grounded via a ground wire back to its main power panel. A couple of other nodes on this segment are also grounded in a similar manner. Some other nodes on this segment are grounded via local building steel. My questions are: Could I be right in regards to the ground loop idea? If not, could anyone else give me some pointers as to where to go from here? Also, has anyone else ever had similar experiences with MB+? Thank you in advance to anyone who may answer this post.

[Crossbow 294]

I know this sounds stupid, but actually it kind of is... Make sure the Momentum communication adapter or option adapter and CPU are firmly seated on the M1 base. We had many problems with customers with those little plastic locking tabs breaking off, and then the device wouldn't work well because there was no sure way to lock the tophat onto the base. The other thing you can use once you ensure the connections are tight is the high vibration kit for the Momentum. It's basically a bunch of palstic clips that go around the outside of the tophat and base to lock them together. Most of the issues we ever had with Momentum (as a distributor for years) were with the units not being connected tightly.

[Guest boudreaub]

Thank you for the information, Chris. I did verify that the M1 and the MB+ communications adapter was firmly secured on the base. I will be looking into the high vibration kits you mentioned.

[Guest Controls39]

First I am assuming you are using AS-MBKT -085 (inline) and AS-MBKT-185 (terminating) connectors on all drops. If not (ie using some of the T's supplied by Modicon), first thing to do is switch all connectors to these types. I have pulled countless T's out in similar situations. Then carefully check ALL connectors to make sure there are no stray ground wire strands touching connector barbs. In large, multi-node networks probelms like you described may actually be created because of wiring problems on other nodes. Having been in your situation many times, this is a hard lesson to learn. Next, make sure ALL cable sections are at least 10 feet minimum. If you put a short section in with this large network, it will cause problems. Something about wave length and reflections. If you get desperate, contact your local SQD office and ask them about getting TSD to help you. The can supply technical guys (and/or gals) that can help evaluate you system. They also have some specialized hardware and software to analyse the system. Good Luck!!

[Guest Guest_boudreaub]

Thank you for the reply, Controls 39. Yes, we are using the AS-MBKT-085 connectors as well as the 185 terminators. On the affected node, I have checked several times over to see if there is a loose strand from the shield touching either of the other two lines. As I said before, I've also replaced every associated part at the affected node. You did mention that a connection problem on one node could cause a communications problem on another node. If so, could this same problem be transmitted across a repeater? I was lead to believe that the answer would be no. However, I'm not quite so sure now.

[Thorny 0]

Hi, I have had several problems like the one you describe on MB + and when I found the problem it was not the node that was throwing up errors but one several nodes away ? strange but true, another thing to try is schnieder engineers have a network analysis tool to check net work condition lenght etc, I used this service once and it was money well spent, that was five years ago and even know I only have to do regular tightness checks of the node connectors and thats it, it just runs and runs.