Modbus Comms failure between PLC ML1400 and VFDs when one devices is unplugged

Hello Everyone, I am new to this chat and I have encountered a major issue on a system we are building. We have a master PLC Micrologix 1400 and several VFDs that are the slaves. Our comms are working just fine, but one of our tests is that in the event of a device failure and loss of comms we would alarm out the specific device, provide an HMI alarm and continue to ping that device until comms are restored.
As a test with the system running we pull the modbus connector to the device, and we do get the alarm for that specific device BUT additionally we get alarms to several of the other devices. The other devices are still connected to the daisy chain and will communicate but every now and then it will error the message.

Any ideas would be highly appreciated, this thing is driving us crazy but I am sure I am not the only one trying to provide a fail safe system that if one device fails, it locks out and the rest continue to operate.

Thank you
 
It could be a hardware/wiring issue. Presumably this is an RS-485 daisy chain wired network. Are you sure that when you "pull the modbus connector to the device" that you are not disconnecting downstream daisy-chained devices at the same time?

If the device you disconnect is the last device on the daisy chain, then it should have a termination resistor. If the device disconnection process disconnects the termination resistor, then termination resistor is not doing its job of absorbing reflected energy and Modbus data could could be corrupted for those units remaining on-line and corrupted messaging could look like a loss of communications and achieving exactly what you're attempting - identifying a loss of communications issue.

Or, it could be a programming issue. When a Modbus master does not get a reply from a slave, it "times out" so that it can go on to the next task and not hang up trying to talk to a node can not reply. Timing-out is a standard feature of all masters.

But the alarm-on-time-out function is most likely custom programming. If the alarming is faulty because additional false alarms are triggered by an actual loss-of-comms to one device, then you have to look at the code that does the alarming. What does the guy who wrote the code to do the alarming say about this issue?
 
Dealing with a similar issue with Proface GP touch screen/PLC. When a device's comms were lost, communication for the whole network would slow considerably.
This was our only solution:
Monitor system error bit for each device. This bit turns on as soon as there is an error but before the Comms Timeout is activated.
If an error bit turns on stop scanning that device and disable any of its message blocks.
Turn the device's channel on once every 2s for one scan and check to see if the system error bit recovers.

Unfotunately I'm not aware of individual channel error bits or device scan enable/disable bits in AB but you might keep the network 'alive' through delaying triggering of message blocks with errors and only retrying intermittently for one scan.
 
David_2 and Meisterbod,

I appreciate your feedback. After getting your responses I actually reviewed the PLC code and we didn't find anything that could possibly cause a major issue but as we tested the system we found that we were able to make it work successfully but other times it wouldn't work. We noticed that we could get it to work at nights or after the fabrication shop was gone for the day so we immediately started looking into noise into the 460 VAC line.
Looking into the source of the power we noticed that the main source was not grounded at the main disconnect that feeds this test bench. We fix the ground issue but additionally we looked into the comms wiring to make sure our shields were being properly connected through the modbus network.

We found a disconnect AND most importantly we found that our 0 V or common pin had been swapped at the beginning of the network. Difficult to troubleshoot since it would work some of the times,because of that I assumed that the comms cabling was OK.

We have the system working, thank you for the help.
 
I am back just as my comm problems. Here is the weird problem with this system we have. Per my previous thread we thought we had the system fixed, we found a couple of issues, we fixed them and everything was working great. That was until the next morning we came in and everything was back to what it was before. So let me clarify a little bit the system we have:

Micrologix 1400 AB PLC with 16 VFDs EATON DE1 connected via Modbus RTU.

Under normal conditions we can get the VFDs to start, stop and it all works properly. As part of our test we have to report if there has been a COMM trouble on any of the VFDs, so to test this functionality we disconnect one of the MODBUS connectors from the VFD and up to this point everything works good, we show one alarm on that specific VFD but then the alarms start to rain on, we show other VFDs with Comm alarms. We have also tried this test by just turning the VFD protector off and we get the same response.

It has been extremely frustrating since we have gotten this system to work properly 2 times already but then the problem re surfaces without any code or wiring changes.

I have verified the wiring multiple times, we have tested the system when our fab shop is not working, just in case we have noise from all the welding equipment, and we cant pin point the problem.

My concern now is if I have the proper logic for the alarms. Right now once a message errors i use that error bit to latch and alarm. I have added a 4 second delay so the error bit has to be active for 4 seconds before I latch the alarm and still nothing. I am using code that is actually provided by AB as sample code so I am at a loss here. Any help that can be provided will be appreciated.

Is it common on a MODBUS network to get error messages every now and then or once the communication is properly set up these error messages dont show up at all unless there is a problem?

Thank you
 
Does Modbus do what it is supposed to if you disable the fault detection/Comm problem reporting routine? Or do you get long-term drop-outs, like a drop-out in excess of one minute?

Can the PLC execute a 2nd poll to the faulty VFD within the 4 second alarm delay period?
 
You've stated that you encounter this issue both when you disconnect the Modbus connector from the VFD and when you power off the VFD.

One test you can try that should help you determine whether the issue is electrical or logical is to temporarily change the Modbus slave address of the VFD to an address that is not being targetted by your PLC (don't forget to power cycle the VFD for the change to take effect). This keeps the VFD on the RS-485 network, electrically, but effectively disconnects it logically, as the VFD will never receive a request targetted for it and so will never transmit a response.

If you see the same issue occur, then your problem is likely a logical issue in your PLC program. If the issue goes away, then you likely have an electrical issue (i.e. improper bus biasing, improper termination, overloading the bus, etc.)
 
Dealing with a similar issue with Proface GP touch screen/PLC. When a device's comms were lost, communication for the whole network would slow considerably.
This was our only solution:
Monitor system error bit for each device. This bit turns on as soon as there is an error but before the Comms Timeout is activated.
If an error bit turns on stop scanning that device and disable any of its message blocks.
Turn the device's channel on once every 2s for one scan and check to see if the system error bit recovers.

Unfotunately I'm not aware of individual channel error bits or device scan enable/disable bits in AB but you might keep the network 'alive' through delaying triggering of message blocks with errors and only retrying intermittently for one scan.
Hi Meisterbond, I also program many Pro-face GP screens using GP Pro EX. Did you use the #scanoff functionality for this? I also use that a lot. Good idea to enable it now and then te see if something comes back online............I'll keep that in mind.
 
David_2 and Meisterbod,

I appreciate your feedback. After getting your responses I actually reviewed the PLC code and we didn't find anything that could possibly cause a major issue but as we tested the system we found that we were able to make it work successfully but other times it wouldn't work. We noticed that we could get it to work at nights or after the fabrication shop was gone for the day so we immediately started looking into noise into the 460 VAC line.
Looking into the source of the power we noticed that the main source was not grounded at the main disconnect that feeds this test bench. We fix the ground issue but additionally we looked into the comms wiring to make sure our shields were being properly connected through the modbus network.

We found a disconnect AND most importantly we found that our 0 V or common pin had been swapped at the beginning of the network. Difficult to troubleshoot since it would work some of the times,because of that I assumed that the comms cabling was OK.

We have the system working, thank you for the help.
Are you using a good impedance corrected cable? I only use Lapp Unitronic bus LD, a cable designed specially for bus systems (like modbus) and it is impedance corrected. See: https://products.lappgroup.com/onli...s422/fixed-installation/unitronic-bus-ld.html
You can order it by the meter from the german company Conrad.
 
I am back just as my comm problems. Here is the weird problem with this system we have. Per my previous thread we thought we had the system fixed, we found a couple of issues, we fixed them and everything was working great. That was until the next morning we came in and everything was back to what it was before. So let me clarify a little bit the system we have:

Micrologix 1400 AB PLC with 16 VFDs EATON DE1 connected via Modbus RTU.

Under normal conditions we can get the VFDs to start, stop and it all works properly. As part of our test we have to report if there has been a COMM trouble on any of the VFDs, so to test this functionality we disconnect one of the MODBUS connectors from the VFD and up to this point everything works good, we show one alarm on that specific VFD but then the alarms start to rain on, we show other VFDs with Comm alarms. We have also tried this test by just turning the VFD protector off and we get the same response.

It has been extremely frustrating since we have gotten this system to work properly 2 times already but then the problem re surfaces without any code or wiring changes.

I have verified the wiring multiple times, we have tested the system when our fab shop is not working, just in case we have noise from all the welding equipment, and we cant pin point the problem.

My concern now is if I have the proper logic for the alarms. Right now once a message errors i use that error bit to latch and alarm. I have added a 4 second delay so the error bit has to be active for 4 seconds before I latch the alarm and still nothing. I am using code that is actually provided by AB as sample code so I am at a loss here. Any help that can be provided will be appreciated.

Is it common on a MODBUS network to get error messages every now and then or once the communication is properly set up these error messages dont show up at all unless there is a problem?

Thank you
Are the VFDs not causing the noise on the communication? The cables from VFD to the motors must be shielded and the shield must be connected to ground at both sides......Is your earth itself ok. I know from personal experience in a factory 100km above Madrid (rocky bottom) that we had to let a specialized company drive a special earth pin 100m in the ground (touching ground water) in order to have proper shielding earth. Maybe slowing the communication down can improve things.......if that happens there is certainly noise on the communication signals.
 
I am back just as my comm problems. Here is the weird problem with this system we have. Per my previous thread we thought we had the system fixed, we found a couple of issues, we fixed them and everything was working great. That was until the next morning we came in and everything was back to what it was before. So let me clarify a little bit the system we have:

Micrologix 1400 AB PLC with 16 VFDs EATON DE1 connected via Modbus RTU.

Under normal conditions we can get the VFDs to start, stop and it all works properly. As part of our test we have to report if there has been a COMM trouble on any of the VFDs, so to test this functionality we disconnect one of the MODBUS connectors from the VFD and up to this point everything works good, we show one alarm on that specific VFD but then the alarms start to rain on, we show other VFDs with Comm alarms. We have also tried this test by just turning the VFD protector off and we get the same response.

It has been extremely frustrating since we have gotten this system to work properly 2 times already but then the problem re surfaces without any code or wiring changes.

I have verified the wiring multiple times, we have tested the system when our fab shop is not working, just in case we have noise from all the welding equipment, and we cant pin point the problem.

My concern now is if I have the proper logic for the alarms. Right now once a message errors i use that error bit to latch and alarm. I have added a 4 second delay so the error bit has to be active for 4 seconds before I latch the alarm and still nothing. I am using code that is actually provided by AB as sample code so I am at a loss here. Any help that can be provided will be appreciated.

Is it common on a MODBUS network to get error messages every now and then or once the communication is properly set up these error messages dont show up at all unless there is a problem?

Thank you
You may have look on this informations that can higlight some points:


H5-05: Communication Fault Detection Selection
Enables or disables the communications time-out fault (CE).
If H5-05 is set to 1, a fault will occur if the master controller does not receive a response
from the drive after two seconds. The power to the drive needs to be cycled for the setting in
H5-05 to take affect.
H5-06: Drive Transmit Wait Time
Sets how long the drive should wait to send a response after it receives data.
H5-03
Communication
Parity Selection
Selects the communication parity for
MEMOBUS/Modbus terminals R+, R-, S+ and
S-. Cycle power for the setting to take effect.
0: No parity
1: Even parity
2: Odd parity
0 to 2 0 427H
No. Name Description
Setting
Range
Default
MEMOBUS
Address
H5-04
Stopping Method
After
Communication
Error
0: Ramp to stop (decelerates according to C1-
02)
1: Coast to stop
2: Fast-Stop
3: Alarm only
0 to 3 3 428H
No. Name Description
Setting
Range
Default
MEMOBUS
Address
H5-05
Communication
Fault Detection
Selection
0: Disabled - A communication


H5-09: CE Detection Time
Sets the time required to detect a communications error. Adjustment may be need when
networking several drives.

0.0 to
10.0 s
2.0 s 435H

Do not hesitate to let us know what you think about this CE detection time.

I will ahve a closer look on this case , and see if i can support .

I am sure that the document that i got contains some valuables datas to check for solving this case.

Controls Guy25.
 
Top