If so, let's investigate a few concepts behind this protocol, as well as the top 3 Pros and Cons you'll encounter while setting up remote monitoring for your Modbus Devices.
Modbus is a protocol used for machine-to-machine communications in a wide variety of industrial applications. Modbus is generally used for remote monitoring and control; commands are issued to instrumentation and control devices while data is being generated.
In Modbus networks, there is typically one master and multiple slave id units. The Modbus master devices will either request information from or issue commands to remote telemetry units (RTUs).
Each RTU box is assigned a unique Modbus address to enable correct routing of data and commands. Traditionally a Modbus network had a multi-drop serial lines with appropriate unit isolation. In these traditional networks, up to 247 RTUs would be connected at one time.
Modbus/TCP was introduced to take advantage of contemporary LAN infrastructures. Modbus/TCP increased the number of units that could be connected to the same network.
Data is organized in 16 bits registers with commands available to access an entire register or in some cases individual bits. Writing to a coil or register generally represents controlling the RTU or something it's connected to. Each Modbus RTU manufacturer has considerable freedom in determining what each input register means for its telemetry. A Modbus register map is typically available to enable master configuration.
With these main concepts in mind, let's dive in the pros and cons.
The Modbus protocol was released in the 1970's as a way to ease communication between different devices, such as generators, PLCs, and even reverse osmosis pumps.
Modbus itself is rather universal: as an open source protocol, it can be used by anyone rather than one entity or company. As a result, several manufacturers started developing Modbus; thereby leading to the main benefit of this protocol: wide-scale early adoption.
Modbus was then used extensively for a number of reasons, including the following:
It is an open-source protocol, meaning that it can be included in a wide range of device types from any equipment vendor.
Modbus messages are simple messaging structures, making it less difficult to deploy. It might require just a matter of days to implement, a big improvement over the months of work that might be required to learn and deploy other protocols.
Modbus moves raw words and bits and has very few restrictions.
However, the difficulty that you might run into with this kind of early adoption phase is that the standard is not fully mature or defined. As a result, you will run into inconsistencies and variations between different manufacturers. You'll usually have to work with an expert or with extensive vendor documentation in order to get your configuration right the first time.
The flexibility of the transport is both a blessing and a curse for Modbus enabled devices.
When Modbus was first introduced, it was designed more with a point-to-point RS-232 connection in mind. However, as Modbus began to mature, more devices incorporated RS-485 and TCP/IP connections.
Modbus via RS-232 sends data in the form of time-series bits; in other words, a standard for communication between data terminal and data circuit termination equipment. Transmission and receipt for data occurs on different circuits when using Modbus RS-232 lines. This means that data is able to flow both ways at the same time.
RS-485 is similar, but distinct, from RS-232. This two-wire, multipoint connection communicates data by indicating values by sending different voltages across the two wires. These differences between these voltages are related to one and zero values, which make up the Modbus RS-485 communications.
Although Modbus networks typically utilize serial port connections (RS-232 or RS-485), Modbus TCP/IP networks is made up of devices that support the Modbus TCP/IP protocol. And it will usually use 10BaseT or faster for their connection.
The bottom line is that the type of connectivity your Modbus device supports dictates how it will report back to its master. You will need to think about your specific scenario, i.e. "I have a Modbus device that reports 485, but need it to report back to an LAN only master." Or "I have an extremely remote site. How am I going to receive my data, and how can I bridge that connection from serial to TCP/IP?"
One way around this disadvantage is to deploy a Modbus bridge. A Modbus Bridge connects Modbus networks to several different protocols and networks.
Ultimately it allows you to transition to TCP while still making use of your Modbus serial devices.
As you start developing your remote monitoring solutions, scalability is something you should seriously consider ahead of time. If you are only looking to monitor one or two devices during the entire lifespan of your business, a single RTU or site-based RTU polling information may be significant for your needs.
However, if you're looking to monitor a myriad of different devices, or if your business grows significantly, you should consider a system that is scalable and will effectively distribute and route your monitoring loads.
A dedicated Modbus master or master system is capable of handling such a task.
This Master should be able to remotely reach out and poll all of your Modbus devices and bring back their information to single collection zone.
If that is your case, look for an efficient Modbus master that can be used for more than simply communicating with Modbus slave devices.
Find a master that can bring your Modbus alarms and notifications from other protocol devices into one master screen. Master Screen monitoring maximizes efficiency by eliminating the need for multiple operators and workstations common in traditional alarm monitoring.
In addition, try to find the most user-friendly interface possible. Interfaces with familiar Windows controls helps staff quickly pick up both the work and the features of the new Modbus master.
Lastly, be sure your master can provide alarm grouping by user-defined groups. This will allow you to categorize your Modbus alarms based on severity, geographic location, and any other criteria that will help your operator to most efficiently dispatch your network technicians.
With an ordinary master, you will be unable to collect alarms from your non-Modbus devices. This will require you to deploy multiple masters to support all of the different protocols within your network, as well as hire additional operators to monitor the communications from these assorted masters.
With T/Mon, you can have Modbus alarms and alarms from over twenty-five additional protocols forwarded into one master browser. This convenient, single-window view allows you to monitor your entire network of devices through a single workstation, using a single operator.
Another advanced feature of the T/Mon Modbus master is the page and email alarm notifications utilized by the system. Anytime an alarm occurs within your network, your Modbus master will send a page or email directly to your network technician. These alerts can even be directed to specific technicians according to your technical staff's schedule, and their individual skill sets.
The T/GFX on T/Mon allows you to map out your operations in a user-friendly way. By choosing your own images, you can create an interactive layout of your floor.
For instance, if you are a factory, you could have your entire process laid out. Each time a process is started, or if there is a problem, a light flash at the exact area the issue is coming from. Eliminate the guesswork and know exactly where the problem is when it happens.
There are three levels of T/Mons, depending on the size of your network.
The T/Mon LNX, mentioned previously, is a multiprotocol, multifunction single-platform solution for all remote alarm monitoring uses.
The T/Mon SLIM can be used over LAN and Modem. It monitors up to 64 devices and 10,000 alarm points. Additionally, it supports web browser and email alarm notifications.
And lastly, the T/Mon MINI. provides centralized monitoring for up to 16 alarm remotes (scalable to 64 remotes). This makes it a great test for a larger T/Mon deployment, and also a solid long-term option for monitoring smaller networks.
With all these advanced features, you'll be the first to know anytime a device in your remote site has lost communication with your Modbus master.
Before you decide on a Modbus solution, there's a lot you need to consider about the devices that you're going to be monitoring and how they report back to you.
We've developed a new way to prioritize the polling of thousands of Modbus registers. This helped one of our clients monitor hundreds of registers spread out over several devices while focusing primarily on the few that matter the most.
You may not need to process large amounts of Modbus information. But what do you need? Remember that we can customize a solution that will directly meet your unique needs.
We not only can develop custom firmware to meet your very specific technical requirements, but also your new firmware functions will run on our proven hardware and benefit from our remote monitoring expertise.
There is no other network on the planet that is exactly like yours. For that reason, you need to build a monitoring system that's the right fit for you.
"Buying more than you need" and "buying less than you need" are real risks. You also have to think about training, tech support, and upgrade availability.
Send me a quick online message about what you're trying to accomplish. I'll work with you to build custom PDF application diagram that a perfect fit for your network.
Don't make a bad decision
Your network isn't off-the-shelf.
Your monitoring system shouldn't be, either.
We'll walk you through this with a customized monitoring diagram.
Just tell us what you're trying to accomplish with remote monitoring.Get Your Custom Diagram Now