Help! Modbus issues

richleva

Member
Join Date
Sep 2012
Location
ontario
Posts
79
Hello,

I have a Micrologix 1400 controlling 3 Benshaw VFD's via Modbus.
This setup has been work fine for years. until one day, the 3rd VFD blewup! literally, the door blew off the enclosure.

The 3rd VFD was then replaced, but now we are having Modbus communication problem, the PLC can't communicate to any of the drives anymore, the PLC message instruction times out with error. After doing some testing I found that by removing VFD#2 from the Modbus loop, it allowed VFD#1 and VFD#3 to communicate, However if I start up VFD #1 I instantly lose Modbus communication??

I tried running VFD 2 locally, even though Modbus is disconnected and communication is still good.

I can't run VFD 3, since the pump is not in water

So I'm suspecting electromagnetic interference (EMI).
but why?

-All Modbus cables are shielded and grounded from the PLC panel.

Also note, we have a hart gateway/modem called HRT-710 for the flow meters and this device communicates just fine on Modbus, regardless. even with VFD#2 connected to the Modbus loop which seemed to caused no communication to all 3 VFD's.

If anyone has any clue or ideas please share them, I'm not sure what to look at anymore, can an oscilloscope tell me anything?

Thanks everyone !!
 
So #1 and #3 works together but not with #2 added, but #2 work by itself? Is this RS485?

If so, check all three modbus addresses. After that, take 1400 out of the equation, use a modbus master simulator direct from your laptop with a RS485 adopter.
 
Hello,the 3rd VFD blewup! literally, the door blew off the enclosure.
Your inability to communicate with any drive suggests that when the VFD blew the doors off it might well have damaged the other devices on the communications bus (RS-485?).

I'd suggest that you test Modbus communication to each drive individually (with no other device on the bus/link) to prove that each drive's comm port is still functional.
 
So #1 and #3 works together but not with #2 added, but #2 work by itself? Is this RS485?

If so, check all three modbus addresses. After that, take 1400 out of the equation, use a modbus master simulator direct from your laptop with a RS485 adopter.

So yes 1 and 3 work together, however I cant run them, if I do, I lose comms
and yes its RS485

I only tried #2 by itself locally ( disconnected from the Modbus ) to see if it would still cause any impact on the Modbus. while 1 and 3 are communicating fine but not running.
 
Your inability to communicate with any drive suggests that when the VFD blew the doors off it might well have damaged the other devices on the communications bus (RS-485?).

I'd suggest that you test Modbus communication to each drive individually (with no other device on the bus/link) to prove that each drive's comm port is still functional.

Yes I can communicate to 1 and 3 directly, but if I run them I lose comms,
and drive 2, I cant do anything with it
 
As with any communications on wire, the basics are, you are driving an electrical signal across wires from one device to another. My guess (from what you’ve described so far) is that the serial driver in the MicroLogix 1400 (and probably the other drives) was damaged and isn’t able to push the current needed to pass the signal through the wires. It works with one because that’s less of a demand. Another way to look at it is when the MicroLogix 1400 tries to communicate via RS485 it has to turn on a transmitter then send an electrical signal on the wire. For every receiver on the line the transmitter has to be able to provide a certain amount of current to “drive” that receiver. The more receivers the more current the transmitter has to provide. A damaged circuit might be able to provide enough current to drive one or two receivers but (in your case) it can’t provide enough current to drive three. With the drives, it sounds like they are suffering from the same fate and the amount of current they can provide is reduced when the are running. There is some guessing here but from what you are describing you have a physical problem not a programming one. Given that this was the result of a catastrophic failure I would replace all of the drives and the PLC using the same expenditure process used to replace the one that failed in the first place. It was all part of one event and should be repaired that way.
 
As with any communications on wire, the basics are, you are driving an electrical signal across wires from one device to another. My guess (from what you’ve described so far) is that the serial driver in the MicroLogix 1400 (and probably the other drives) was damaged and isn’t able to push the current needed to pass the signal through the wires. It works with one because that’s less of a demand. Another way to look at it is when the MicroLogix 1400 tries to communicate via RS485 it has to turn on a transmitter then send an electrical signal on the wire. For every receiver on the line the transmitter has to be able to provide a certain amount of current to “drive” that receiver. The more receivers the more current the transmitter has to provide. A damaged circuit might be able to provide enough current to drive one or two receivers but (in your case) it can’t provide enough current to drive three. With the drives, it sounds like they are suffering from the same fate and the amount of current they can provide is reduced when the are running. There is some guessing here but from what you are describing you have a physical problem not a programming one. Given that this was the result of a catastrophic failure I would replace all of the drives and the PLC using the same expenditure process used to replace the one that failed in the first place. It was all part of one event and should be repaired that way.

Thank you for the explanation its just weird that #1 and #3 would communicate fine, but running a Drive would lose communication
 
Remove the shield wiring. VFD's generate a lot of "noise" on the ground and disrupt the communication signal.
I usually run shielded cable but do not connect the shield wiring. I have run Modbus over 1000ft with no comm issue with the shield disconnected.
 
All of the above and:
1. After you triple check the port settings in the new VFD power cycle it (make sure it is all the way dead when off). Most VFDs do not apply changes to serial port settings until a power up sequence occurs.
2. Check for termination jumpers/switches on the equipment. Most of them provide a tiny jumper or switch for cable termination. I try to make use of these and put the ML1400 in the middle of the daisy chain so I can avoid wiring a discrete 120ohm resistor to the terminals. You want termination applied to both end nodes in the daisy chain.
3. Check with the Benshaw literature about the preferred method for grounding the shield on the RS-485 cabling. I ignored the literature for some Yaskawa drives and only grounded the shield at one point. A few months later it started getting errors, so I ended up going back to the site and tying shield to ground at all three drives like the book said to do. It solved the problem for my situation. Also, ensure the cable is physical routed as far from noisy stuff as possible. You might even want to replace the segments that were potentially affected by the explosion.
 
Last edited:
I recommend an RS-485 isolator/repeater at the master and half-way down a multidrop bus in order to

- protect the master in case of a fault hitting the 485 line

- protect half the multidrops from a fault hitting the 485 line.

RS-485 isolator/repeaters are about $200-$300 each, and most people reject the advice, but I suspect isolation with my scheme would have left the master functional and one or two of the drives functional.
 
Thank you for the explanation its just weird that #1 and #3 would communicate fine, but running a Drive would lose communication

It depends on how you define “running fine”. On the surface it might look like everything is ok but under the surface the communications might be struggling. It wouldn’t be the first time I’ve seen a serial communications device take a surge and work but just barely. It’s also worth noting that not only do you have the transmitter, but you also have the receiver. The receiver equates to how the device “hears” the signal the transmitter is sending. It can be damaged in such a way that it can still hear but everything is a lot quieter. This would make things like magnetic interference have more of an impact. Think of it this way. If you are across the room from someone who is talking and even thou there are other people in the room talking you can still hear him. Now, someone comes up and screams in your ear. Now you can just barely hear the guy talking above the other people talking because your ear is damaged (hopefully temporarily).
The long and short is there are a lot of possibilities and while there is a lot of good information regarding cabling and such, you went from a system that was working without any issues to one that struggles to work at all (as it did before) after a catastrophic event. I’ve been a communications expert in the automation industry for 20+ years and if it were my system I’d be figuring out how to replace the remaining two drives, the PLC and possibly even the cabling.
P.S. The drive running causing the communications to fail is a simple one. Running drives produce a lot of noise across a wide spectrum and there is a lot of filtering done to reduce the impact that noise has. Two things can happen when you get the type of event you had both of which are probably present in your situation. One is the filtering gets damaged and the amount of noise getting out can be dramatically increased. Two, when a transceiver (transmitters and receivers are really one device called a transceiver) get damaged it become much more susceptible to noise per some of the reasons I’ve already covered. So, you have more noise being introduced to devices that can’t deal with it as well as they used to be able to. Thus, comms fail when the drive is running (seen it before).
P.P.S. I’m sorry you had the failure, but I love the topic, thanks for posting it. I hope it works you for you (and I go back to being bored).
 
It depends on how you define “running fine”. On the surface it might look like everything is ok but under the surface the communications might be struggling. It wouldn’t be the first time I’ve seen a serial communications device take a surge and work but just barely. It’s also worth noting that not only do you have the transmitter, but you also have the receiver. The receiver equates to how the device “hears” the signal the transmitter is sending. It can be damaged in such a way that it can still hear but everything is a lot quieter. This would make things like magnetic interference have more of an impact. Think of it this way. If you are across the room from someone who is talking and even thou there are other people in the room talking you can still hear him. Now, someone comes up and screams in your ear. Now you can just barely hear the guy talking above the other people talking because your ear is damaged (hopefully temporarily).
The long and short is there are a lot of possibilities and while there is a lot of good information regarding cabling and such, you went from a system that was working without any issues to one that struggles to work at all (as it did before) after a catastrophic event. I’ve been a communications expert in the automation industry for 20+ years and if it were my system I’d be figuring out how to replace the remaining two drives, the PLC and possibly even the cabling.
P.S. The drive running causing the communications to fail is a simple one. Running drives produce a lot of noise across a wide spectrum and there is a lot of filtering done to reduce the impact that noise has. Two things can happen when you get the type of event you had both of which are probably present in your situation. One is the filtering gets damaged and the amount of noise getting out can be dramatically increased. Two, when a transceiver (transmitters and receivers are really one device called a transceiver) get damaged it become much more susceptible to noise per some of the reasons I’ve already covered. So, you have more noise being introduced to devices that can’t deal with it as well as they used to be able to. Thus, comms fail when the drive is running (seen it before).
P.P.S. I’m sorry you had the failure, but I love the topic, thanks for posting it. I hope it works you for you (and I go back to being bored).

Thank you very much for the info! I spoke with Benshaw and they said there is no isolation on the RS-485 port for the drives. we did find out that the PLC master device and the HRT-710 do have isolation. I'll be retuning to site next week, with a much better understanding

Cheers, thanks again!!
 
Pay special attention to the terminating resistors.
The noise resistance of RS-485 is due to the fact that it works with current and not with voltage and for the current to circulate throughout all the loop the resistors must be installed in both extreme but nowhere else.
 

Similar Topics

Hello, I am trying the AOI provided by Rockwell to read Modbus TCP, the version is 2.04 The connection looks good to the modbus server. I...
Replies
4
Views
542
Title summarizes the overview of the problem. I am trying to make AVEVA Edge 2020 and a Schneider TM241CE40R to talk to each other via Modbus...
Replies
18
Views
1,922
Good day all. I have an RS-485 topology question. I am hoping for some guidance so that I can make a confident calculation/decision that this will...
Replies
4
Views
1,412
I'm trying to get an rx3i system with a IC695CMM002 card to talk to a Moxa Io-logik module over rs485 modbus. I can get my computer to talk to it...
Replies
1
Views
485
I have a PLC5/80E that I want to poll a Modbus device into using a Digi1. I have setup the message as a multihop going to the IP adress of the...
Replies
2
Views
1,404
Back
Top Bottom