Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayModbus is a protocol developed in the 1970's for use with Programmable Logic Controller (PLC) devices to facilitate communication between machines, especially in industrial applications.
Even though time has passed and new technology advancements have arrived, this protocol is still the principal choice for networks of many businesses. It's now widely used for connecting many types of industrial electronic devices connected in different types of networks. It's typically used to remotely monitor and control devices when data is collected, such as in a SCADA application. This protocol can be used to issue commands and to automate processes as well.
Standard Modbus is easy to deploy and maintain, which allows you to build up your network piece-by-piece as needs arise, and also contributes to saving time and money on repair work.
Are you currently exploring the opportunities that remote site monitoring equipment can offer to your network? Let's walk through Modbus protocol particulars and capabilities, as well as some options of RTUs and masters that support this protocol, so that you can make an informed decision.
Modbus is an open protocol of a Supervisory Control and Data Acquisition (SCADA) system. This means it doesn't belong to one manufacturer and can be used by any company.
Unlike many proprietary, vendor-specific protocols created by manufacturers to trap customers into using only their products, Modbus is commonly supported throughout many vendors. This gives you the ability for devices from several generations and companies to send data back and forth.
Keep in mind that the Modbus protocol can be used with both RS-232 and RS-485 connections. Virtually all modern Modbus systems will also send data over Ethernet through TCP/IP. These Modbus data transfers can be a single bit, or 16-bit packets.
The Modbus network is structured as a master/slave model, meaning there is usually one "master" that receives information from, and sends commands to, multiple "slave" units.
Each Modbus RTU slave has a unique address so data and commands can be routed correctly over a network. Traditionally, a Modbus network was a multi-drop serial channel, such as RS-232 or RS-485, with appropriate unit isolation. In these types of networks, up to 247 RTUs could be connected at one time.
Modbus TCP was put in place to take advantage of modern LAN infrastructure. It also expands the number of units that can be connected on the same network.
To connect Modbus serial products to Modbus TCP masters you can use a Modbus bridge. A Modbus bridge allows Modbus networks to work on many different types of networks.
Modbus serial is the original variant of Modbus that travels over a serial connection. As stated before, the serial connection commonly utilizes RS-232 or RS-485.
Modbus TCP, however, has become a more popular version of the Modbus protocol. A Modbus bridge will allow users to transition to this version, while still making use of their Modbus serial equipment.
A Modbus bridge can be configured as a slave or a master bridge, simply by connecting to either device serially. This bridge may also be used for other Modbus versions, such as Modbus ASCII and Modbus RTU protocol.
Using a Modbus bridge, you can connect numerous slave devices using a single Ethernet card and the Modbus TCP protocol. Devices joined to a Modbus bridge have a single IP address, and addressing slaves through the Modbus bridge is defined by the IP address and the slave address or unit ID.
When a Modbus bridge receives a Modbus TCP request, it converts the messages into Modbus RTU or other version of the Modbus protocol, creating a response using Modbus TCP. In these cases, the Modbus master typically doesn't even know that it's actually communicating with a Modbus TCP device.
A Modbus bridge can connect to many Modbus TCP masters at one time. Serial slaves will see the Modbus bridge as a master device. The actual TCP Modbus masters will see the Modbus bridge like a group of slaves, communicating as if each single master has sole access to these slave devices. With more masters accessing the Modbus bridge, response times can become somewhat slow.
The Modbus protocol has two major variants:
Modbus RTU
Modbus RTU is more compact and uses binary communication. In this format, data transmissions are always followed by a cyclic redundancy check checksum, which are used to detect transmission problems.
Modbus ASCII
This second variant is more verbose, and it uses hexadecimal ASCII encoding of data that can be read by human operators. A different type of checksum - the longitudinal redundancy check checksum - takes place after Modbus ASCII data transmission. This version is less secure than Modbus RTU.
Modbus ASCII characters are less efficient, so operators should only utilize it for the transmission of data to devices that do not support the RTU format. It can also be useful when RTU messaging can't be properly applied.
Purchasing the right RTU for your remote sites can be challenging. It's important to find the right balance of capacity, interface, and features.
Before committing to any choice, consider both the RTU's short-term and long-term effect on your network monitoring. Of course, you want a remote that will immediately improve your network visibility, but keep in mind that this unit has to support your future monitoring goals as well.
Avoid overspending on alarm capacity that you'll never use, though. It's always easier, and more cost-effective, to add alarm capacity in a controlled way rather than rushing into a new deployment when you've exceeded your alarm capacity.
That's why your best choice will be an RTU that meets your present requirements and will expand to meet your future needs. Looking for a vendor that is willing to work to deliver you a perfect solution is also key.
When planning your network fault management system, remember that your RTU should communicate with your equipment via Modbus, extract alarm data, and then report this information in the way you need. Your RTU must be able to send you a text or an email, report to your SNMP manager, or send you notifications through whatever method that works best for you.
The NetGuardian 480
The NetGuardian 480 is a good example of an RTU that integrates smoothly into your network and can manage your gear via LAN. This Modbus-compatible RTU can be incorporated into your preexisting SNMP manager, bringing your Modbus data under your top-level SNMP umbrella. This device will collect alarms from your Modbus equipment, process the data, and send SNMP traps to your SNMP manager.
This NetGuardian allows you to efficiently monitor your remote Modbus devices through the same interface used to monitor the rest of your network. No extra Modbus master station is required. No extra personnel have to deal with multiple interfaces, either.
The Modbus-to-SNMP Converter - or "Modbox"
Another example is the Modbus-to-SNMP Converter, also known as the "Modbox". It'll monitor your Modbus data, generate alarms, and send notifications or SNMP traps to your SNMP manager. With the ability to monitor up to 1500 different registers, you don't have to choose which alarms you can live without.
Monitoring that many registers, however, is a bit challenging. It can take an extended amount of time for RTUs to complete such a long polling loop (it may take 5 minutes for example). This means that you may not receive notifications and alerts for a few minutes.
The Modbox resolves this challenge by allowing you to group alarms according to severity. As it polls Modbus registers, the Modbox will check for high-severity alarms more often. This ensures that you're aware of any potential problems before disaster strikes.
Have you ever needed to monitor multiple Modbus devices through your firewall? With the Modbox you can also keep track of up to 50 devices without creating holes in your firewall.
Simply install this unit and configure your settings on one easy-to-use web interface. With the built-in web interface, you'll be able to log on the Modbox from anywhere on your network to edit your proxy settings. If you need to add another device or want to check which port you're connecting to, you can handle all of this right from your PC. The Modbox also features plug-and-play functionality, which means smooth integration into your existing network.
The NetGuardian 480 and the Modbox are just 2 simple examples of powerful RTUs that are compatible with the Modbus protocol. Most of the DPS remotes support this protocol - or can be lightly modified by DPS to support it.
RTUs are a great option when it comes to handling just a few devices. However, if your network operator have to monitor 10 or more pieces of equipment, you'll probably want to consider purchasing a master station that can help you deal with the load.
When looking for a master for your Modbus network and other devices, you should look for a master that supports a Human Machine Interface - HMI. A Modbus HMI is vital for an operator to be able to read alarm polls and status reports from their Modbus System.
Modbus communications take the form of packets of bits, so it's very hard and time consuming for a tech to manually interpret even a single message. With thousands of alarms and response Modbus messages coming in every day, it'd be impossible for an operator to monitor their network without a Modbus HMI. This is why an HMI is necessary. It decodes the Modbus protocol and translates them into a human-readable language.
Usually, a Modbus master device is accessed in a standard browser window. This allows the network staff to view their Modbus alarms and other messages in English format. The HMI simply uses the codes programmed into the system to retrieve the information from the packets of bits.
Here are some points to keep in mind when looking for an HMI monitoring tool:
Find the most user-friendly interface you can
If your HMI has familiar Windows-like controls, you know your staff will quickly become comfortable using it.
Look for a Modbus HMI that provides alarm grouping by user-defined groups
This feature allows you to categorize your Modbus alarms based on severity, geographic location, or any other criteria that will help you most efficiently dispatch your network technicians.
Choose an HMI with support for all of the protocols within your network
Multi-protocol monitoring systems combine your Modbus alarms with alarms from all of your other protocols. By bringing your Modbus alarms into a single screen with your other network alarms, you'll save money while being able to more efficiently monitor your network. With only one HMI workstation to monitor, you won't have to hire and train more staff to monitor several separate master stations. This multi-protocol capability is important when looking for a Modbus HMI and monitoring system.
Additionally, an advanced Modbus master can be used for more than simply communicating with Modbus slave devices
When searching for a master for your network, look for one that can bring your Modbus alarms and notifications from your other protocol devices onto one screen. This will help you monitor your network in the most efficient way, without the need to have multiple operators and workstations to accomplish the best network alarm monitoring system for your unique scenario.
A good example of a robust, industrial master station is the T/Mon LNX. It can greatly increase your company's visibility while reducing your monitoring costs.
With T/Mon LNX, you can interpret alarms from your Modbus devices, as well as alarms in over 30 SCADA and other protocols. With the Modbus Interrogator installed, T/Mon becomes a solid Modbus HMI. The interrogator module supports discrete alarms, analogs, controls and remote provisioning of Modbus remotes and sensors.With this system, you'll be able to easily switch between alarms and clears with controls that are easy to use. You'll also be able to group your alarms into any group you need to improve your monitoring.
The T/Mon LNX provides a window view that polls all of your Modbus and other alarms into one browser window, getting rid of the need for other monitoring gear and extra operators. With all alarms on one screen, you'll never miss an important alarm because you were checking on another workstation.
T/Mon LNX can also double as a mediator. This means that if you have SNMP equipment, legacy, or proprietary equipment - or any other gear that doesn't support Modbus but needs to be monitored - you can use the T/Mon to mediate those protocols. You can send them to another device, either upward to a higher-level master or downward to an RTU.
Part of T/Mon's web interface - the GFX - 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 site.
For example, you can have a map of your network territory. If there's a problem, a light will flash at the exact area the issue is coming from. You can zoom in from a map to a floor plan to a photograph of an equipment rack.
If you feel like your network is not big enough to justify a master with the T/Mon LNX capacity, there are two other options you might want to consider:
T/Mon SLIM
The T/Mon SLIM can be used over LAN and Modem. It monitors up to 64 devices and 10,000 alarm points.
The T/Mon SLIM can be loaded with the Modbus Interrogator module so it'll act as an HMI for your Modbus operations. Also, it supports web browser and email alarm notifications.
T/Mon MINI
A second option is the T/Mon MINI. It provides centralized monitoring for up to 16 devices.
The T/Mon MINI is an awesome test for a larger T/Mon deployment, and it's also a solid long-term alternative for monitoring smaller networks. Just as the first two T/Mon alarm masters, the MINI supports the Modbus Interrogator module to mediate Modbus protocol into a human-readable language.
If you happen to work with legacy equipment, such as serial Modbus, or if you have a very singular scenario, you'll need very specialized gear to achieve good visibility of your remote sites. Some vendors just sell commodities, though, so you'll be out of luck if you need a unique solution. That's exactly why your choice of manufacturer is as important as finding that perfect-fit device.
We, from DPS, are experts in providing personalized RTU and master station solutions.. Utilizing proven design, we aim to prove to you that it doesn't really matter how hard you think your network is to monitor - we can give you customized tools for that.
Don't wait until there is a problem to find a perfect remote monitoring system for you. Let's get your monitoring solution in place.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
