I am new to MODBUS. Looking for guidance
- Thread starter graitor20
- Start date
The protocol you referred to as Modbus RS-485 could be either Modbus RTU or Modbus ASCII. Modbus RTU is much more common than ASCII. That's one of the things you have to establish, is which protocol is in use? Both ends, master and slave, need to talk the same protocol. An RTU device will not talk to an ASCII box.
One of the most important things you can learn is how to exploit the available documentation for any and all devices in a project. Sometimes Modbus docs are included in the user manual, other times there is separate communications manual. Getting the documentation and reading it goes a long way in executing a Modbus project.
The documentation should tell you how to set up the serial settings, which have to be identical on both ends. RS-485 is a multidrop hardnet bus, so each slave device needs a unique ID number. Each slave will have some means of defining what the slave ID is, DIP switches, rotary switches, jumpers on pins, or a software utilty used to communicate to the slave device. A master does not have a node ID.
For field devices like VFD drives, pH meters, electrical monitoring meters, etc, the manufacturer defines which data resides where by assigning a data value to a specific Modbus register. The documentation should have a 'map' of the Modbus registers. The data format (integer, floating point, or ASCII, among others), engineering units and whether the value is read only or read/write is typically included in a Modbus register map. Given that PLC's are custom programmed, the programmer has to enable Modbus registers and define which goes in which register.
Modbus and its communications is frequently an option, not standard for any given device.
What the documentation does not tell you is that the labeling of the half duplex RS-485 terminals is not regulated by the EIA-485 standard. Some vendors label one way, some the other way. RS-485 notes should be wired (+) to (+), (-) to (-), or A to A, B to B, in parallel, daisy chain fashion, but when devices from different manufacturers are used sometimes the wiring is backwards on one end.
If the master is a PLC that requires downloading any change in the setup, I find it better to 'test' a slave's functionality with a generic Windows Modbus master application like Modscan, Modpoll or Simply Modbus because changes can be made on-the-fly in those apps when one is working to establish communications and making sure that the data is correct.
I would guess that a student project would have only one slave with one master. But should a project involve more than one slave, the best practice is to connect to one slave only, prove it works, then add one slave at a time, because a network of multiple slaves can have multiple problems that make it difficult to assess where the problem is, unless the basics of (#1 works OK, #2 works OK, #3 works OK) have been done already.
There are several good overviews of Modbus on the web.
Chipkin's Modbus for Field Technicians
http://www.chipkin.com/files/liz/MODBUS_2010Nov12.pdf
Introduction to Modbus using (National Instruments) Labview
http://www.ni.com/white-paper/7675/en/
Simply Modbus 'About' Files
http://www.simplymodbus.ca/
Unless you're programming you shouldn't need to read the Modbus standard/spec. The Modbus standard tells the whole story of Modbus, but implementation of Modbus shouldn't need to go that deep into it.
One of the most important things you can learn is how to exploit the available documentation for any and all devices in a project. Sometimes Modbus docs are included in the user manual, other times there is separate communications manual. Getting the documentation and reading it goes a long way in executing a Modbus project.
The documentation should tell you how to set up the serial settings, which have to be identical on both ends. RS-485 is a multidrop hardnet bus, so each slave device needs a unique ID number. Each slave will have some means of defining what the slave ID is, DIP switches, rotary switches, jumpers on pins, or a software utilty used to communicate to the slave device. A master does not have a node ID.
For field devices like VFD drives, pH meters, electrical monitoring meters, etc, the manufacturer defines which data resides where by assigning a data value to a specific Modbus register. The documentation should have a 'map' of the Modbus registers. The data format (integer, floating point, or ASCII, among others), engineering units and whether the value is read only or read/write is typically included in a Modbus register map. Given that PLC's are custom programmed, the programmer has to enable Modbus registers and define which goes in which register.
Modbus and its communications is frequently an option, not standard for any given device.
What the documentation does not tell you is that the labeling of the half duplex RS-485 terminals is not regulated by the EIA-485 standard. Some vendors label one way, some the other way. RS-485 notes should be wired (+) to (+), (-) to (-), or A to A, B to B, in parallel, daisy chain fashion, but when devices from different manufacturers are used sometimes the wiring is backwards on one end.
If the master is a PLC that requires downloading any change in the setup, I find it better to 'test' a slave's functionality with a generic Windows Modbus master application like Modscan, Modpoll or Simply Modbus because changes can be made on-the-fly in those apps when one is working to establish communications and making sure that the data is correct.
I would guess that a student project would have only one slave with one master. But should a project involve more than one slave, the best practice is to connect to one slave only, prove it works, then add one slave at a time, because a network of multiple slaves can have multiple problems that make it difficult to assess where the problem is, unless the basics of (#1 works OK, #2 works OK, #3 works OK) have been done already.
There are several good overviews of Modbus on the web.
Chipkin's Modbus for Field Technicians
http://www.chipkin.com/files/liz/MODBUS_2010Nov12.pdf
Introduction to Modbus using (National Instruments) Labview
http://www.ni.com/white-paper/7675/en/
Simply Modbus 'About' Files
http://www.simplymodbus.ca/
Unless you're programming you shouldn't need to read the Modbus standard/spec. The Modbus standard tells the whole story of Modbus, but implementation of Modbus shouldn't need to go that deep into it.
Hi there,
We also have some information about getting started with Modbus on our site. Hope this helps!
We also have some information about getting started with Modbus on our site. Hope this helps!
- https://control.com/technical-articles/introduction-to-modbus/
- https://control.com/technical-articles/comparison-of-modbus-over-tcp-ip-and-profinet/
- https://control.com/technical-articles/tls-transport-layer-security-protocol-secure-modbus-TCP/
- https://control.com/technical-articles/security-decisions-in-modbus-systems/
- https://control.com/technical-artic...ce-why-modbus-is-still-around-after-40-years/
- https://control.com/technical-articles/making-sense-out-of-serial-communication-methods/
Dear graitor20,
If you are new to Modbus Communication and you want a complete understanding of Modbus RS485, you should watch this video on Modbus. A very good and interesting video on Modbus RS485 RTU Communication for basic to complete understanding
If you are new to Modbus Communication and you want a complete understanding of Modbus RS485, you should watch this video on Modbus. A very good and interesting video on Modbus RS485 RTU Communication for basic to complete understanding
