Modbus questions

richleva

Member
Join Date
Sep 2012
Location
ontario
Posts
79
Hello,

I have a question about modbus communication, we have a PLC controlling two VFD's. One of them was locked out, since a pump had to be sent out for service.

If the VFD is powered down would that affect the entire modbus communications line?

Here's the story, since the pump came back from service it won't communicate the PLC anymore? We checked all the communication settings like baudrate, polarity...ect
And all is good.

I'm trying troubleshoot this remotely with the customer. But it's weird that it won't communicate anymore.

The only thing that comes to mind is that, someone removed the drive from the modbus loop while the pump was sent out for service.. and might of forgot to put the drive back in the modbus loop?

Since the Modbus has always been working properly, to my knowledge, even while the pump was out for service.

Therefore, if they locked out the drive because the pump is out for service, would that affect the Modbus communication? If So, then we
need to look for a jumper somewhere?

Not sure if my thinking is correct ...!

Any help or advice is well appreciated
Thanks guys!
 
If this is Modbus RTU then when someone un-wired the VFD to remove it from the site they probably broke the Modbus RTU circuit.

As long as the circuit is not broken removing a Modbus Rtu device will not cause the whole modbus to stop working.

Now when putting the device back into operation with Modbus Rtu, should be as easy as setting the device ID and as long as it is the same as before the new unit should communicate.

Modbus RTU communicates across a complete circuit, endpoints should be terminated because the underlying protocol is probably rs485.

If this is Modbus TCP I would say you have a conflicting IP address or the device Id has not been set correctly.(Conflicting IP) could cause complete failure of modbus, a wrong device id would just not communicated to the device.

Is it the exact same replace? If it is not the addressing could be different.
 
Presumably the PLC is the Modbus master. If so there is probably something in its logic that controls how it handles a non-responsive slave. Usually when a slave doesn't respond the master stops trying to communicate so as not to slow down the entire network waiting around for a response that's not going to happen. Since it has no way of knowing when a slave comes back online, there needs to be some method of re-establishing communications. I suggest you check the logic in the PLC, the settings for the Modbus master, or the documentation of the control system to see how it is supposed to handle the situation.
You said you've checked parameter settings like baud rate and parity. One parameter frequently overlooked is the Modbus ID. In the course of servicing the drive, the shop may have reverted it to its default settings. The default Modbus ID may not be what the PLC is trying to communicate with.
 
If this is Modbus RTU then when someone un-wired the VFD to remove it from the site they probably broke the Modbus RTU circuit.

As long as the circuit is not broken removing a Modbus Rtu device will not cause the whole modbus to stop working.

Now when putting the device back into operation with Modbus Rtu, should be as easy as setting the device ID and as long as it is the same as before the new unit should communicate.

Modbus RTU communicates across a complete circuit, endpoints should be terminated because the underlying protocol is probably rs485.

If this is Modbus TCP I would say you have a conflicting IP address or the device Id has not been set correctly.(Conflicting IP) could cause complete failure of modbus, a wrong device id would just not communicated to the device.

Is it the exact same replace? If it is not the addressing could be different.

Thanks but I don't feel that you awnsered my question.
And yes it's modbus RTU.

If a device is powered down. Will that affect the entire modbus circuit?
 
I missed Steve's reply while typing.

Typically, VFD drives are a Modbus slave/server, so the PLC is likely to be the Modbus master/client.

The manner in which Modbus works is
master polls drive #1, waits for a reply
Drive #1 replies
Master polls drive #2, waits for a reply
Drive #2 replies
Back to the beginning with slave #1

There is typically a time-out period so that if a slave/server does not reply, the master skips that slave at the expiration of the time-out and goes on to the next slave. Otherwise, things would grind to halt, waiting an eternity for a non-responding slave.

So could Modbus in general be affected by a powered down slave? It all depends on how the master deals with non-responding slaves. One would think that a time-out would always be incorporated in the logic, but there are no guarantees. If there is no time-out, the master could wait an eternity for the unpowered/disabled/missing slave to respond.

>Since the Modbus has always been working properly, to my knowledge,
That's your assumption that you should challenge. Has it been working properly or has the customer only reported the Modbus failure since the pump got repaired?

RS-485 is daisy chain connections, typically, master to drive 1 to drive 2. If the RS-485 connections at the first drive are physically disconnected, then the entire network is dysfunctional because neither drive 1 nor drive 2 can get a signal.

A correctly wired, but unpowered RS-485 slave node will not affect downstream nodes.

If the Modbus connections at a drive was unwired during the repair, it could easily have been re-wired incorrectly and swapped 485 driver lines will not work.
 
Last edited:
Thanks you for the replie. That's exactly my question... what are the affects if a node if unpowered ? Does that take down everything?
 
In a properly executed Modbus RTU network powering down one of the nodes will not disrupt communications between the remaining nodes. The designer of the system should have anticipated that one or more of the nodes could be powered down and included logic to handle it gracefully. The designer should also have included a method to restore communications when a node becomes available again. Ideally the designer would have included something on the HMI to tell you the status of the nodes on the network and even given you a friendly communications reset button.
 
In a properly executed Modbus RTU network powering down one of the nodes will not disrupt communications between the remaining nodes. The designer of the system should have anticipated that one or more of the nodes could be powered down and included logic to handle it gracefully. The designer should also have included a method to restore communications when a node becomes available again. Ideally the designer would have included something on the HMI to tell you the status of the nodes on the network and even given you a friendly communications reset button.

Yes we have all that, but still no communication.
 
>Yes we have all that


Great. Bypass the repaired drive.

If drive #1 (first drop on the multidrop daisy chain) removed the wiring but keep it intact so it continues to pass Modbus messages to drive #2.


If drive #2 (2nd drop on the multidrop daisy chain), the disconnect and terminate with a 120 ohm resistor between the driver lines.


In either case, the non-repaired drive will come back on line because you've got all that.
 
I hate to recommend cycling power to the PLC, but if you cannot get online with it using programming software to diagnose the Modbus messages/logic, then cycling power to it might cause it (through intentional logic) to try polling all the nodes again.

But first I would ensure that all the comms settings are configured properly in the drive and that you power cycle it (and leave it off until there is no voltage on the DC bus!).

Many VFDs I have worked with will not implement certain changes to the serial port until they are rebooted...LSIS and Yaskawa are two that I know for sure, when I change serial port settings like parity, baud, or node number, a power cycle is required for them to take effect and work properly.
 
Removing and reconnecting a node affects its communication with the PLC in exactly the way the programmer designed it to.
If you don't have access to the program, find out if there is/are alarms on the screen if there's one.

My understanding is that the Pump was rebuilt but the drive is still there and has not been replaced. If existing drive then it's quite possible that it was damaged, look for error codes on the drive. If new drive then as David stated look at node address and termination. depending on the position of the drive in the Modbus setup it may have to be terminated and it either has a built in termination switch or needs a resistor.
 
Some vfds have more than 1 rj45 socket. Only one of the sockets works with modbus, the others can cause damage if incorrectly plugged in.

As a control engineer, if asked "will this always be ok?" without perfect information, the answer is no.

Switch to ethernet Comms, install remote access, and call it a win. Ethernet cards and associated programming are cheaper than rs485 modbus troubleshooting.
 

Similar Topics

Hello, I am new to Codesys, and am trying to learn about it for a project we're developing. I've got a couple questions, but first a little...
Replies
1
Views
72
I am using a Beckhoff PLC and trying to convert a REAL to 2 WORDS to send over Modbus. Does anyone know how to do this? Also how would I convert...
Replies
5
Views
742
Hi guys, i am trying to program a Scada/HMI. The values i will take them from PLC using Modbus. In the manual they said: This address is not an...
Replies
10
Views
2,498
Hi Everyone, First Project with Siemens and I need to communicate via RS-485 to a Tank Level Hub using Modbus RTU. I will be using the CB 1241...
Replies
13
Views
3,751
Hello Long time lurker. I am flailing around trying to figure out how to implement MODBUS TCP on a W2000 IPC that controls one of my company's...
Replies
10
Views
5,777
Back
Top Bottom