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 polling is one critical part of the overall architecture of the Modbus protocol.
Let's walk though the basics of Modbus communication and talk about how you can get the most out of this technology.
The Modbus protocol specification revolves around a "polled" architecture. This is distinct from other "asynchronous" protocols where data is transmitted immediately upon creation.
A Modbus poll, therefore, is when a Modbus master asks a Modbus slave device for updated status information. It is a simple and routine aspect of the protocol.
In most substantial Modbus systems, a poll takes place many times per second. The master device will poll each of the holding registers of a device in sequence, then move onto the next Slave ID. Eventually, the process loops back around to the beginning and starts again.
As noted above, Modbus polling typically happens on a schedule. That's because we're typically using this protocol in the context of an automated alert system. It does no good to have an alert system if it only asks for system status when you request it.
If we depended entirely on manual Modbus polling, we'd never see a problem when it is just starting to evolve. Imagine that you stepped away from your monitoring system overnight, then wake up to a smoking crater at one of your sites when you run a poll in the morning.
Manual polls absolutely have a function, however. These are useful when you want up-to-the-minute information from your remote site.
Imagine that you're logged into the user interface of your SCADA HMI or other Modbus master. You identify a single register in the list that you want to poll. It might be something like "battery voltage" or "door status".
You double-click on the icon for that register, and your HMI will issue a poll and show the Modbus data for it.
When you're setting up a new Modbus system, you'll often encounter trouble when your masters and slaves aren't communicating well with each other. Because there are multiple elements in a monitoring setup like this, you need to isolate each part to effectively troubleshoot.
That's where a Modbus master simulator or slave simulator becomes important. By replacing one side of the system or the other, you can test whether your equipment will work under ideal conditions.
A simulator will send or receive test strings without any of the potential obstacles inherent with an actual device. This takes variables out of the system so you can pinpoint any problems.
If you work at a larger company, you may already have some kind of test center available where you have access to Modbus simulators.
Whether you're setting up a system, testing with a simulator, or doing anything else, you must know what version of the protocol you're using. If you're not using compatible equipment on both sides, you're not going to have very good luck at all.
The subtle differences between Modbus TCP/IP and Modbus RTU (which is not exactly linked to an RTU monitoring device) are out of the scope of this article. Suffice it to say, you must simply compare product documentation to ensure that you're using compatible Modbus devices.
There is also a question about whether your Modbus traffic is transmitted using RS-485 serial or IP LAN. Again, you can't put RS-485 on your network or vice versa. There are converters that will do this job pretty easily, but that's one more thing you need to think about if you're building a single comprehensive monitoring system.
If you need to collect data from Modbus registers to monitor generators or any other equipment, you need to understand your options.
At the very bottom of the market, there are literally free options that you can play around with. These are great when you're just learning, but free software running on a simple PC workstation is not a great idea for protecting mission-critical operations.
Next up is paid software that you install on your own server. You'll purchase and activate this software with a license key, usually scaled to how many users you have.
Modbus master software like this can actually be quite good. You just need to be careful what you choose. There's a big difference between $50 Modbus programs and $150,000 professional software.
Finally, don't forget that some alarm master stations are purchased as a hardware-software appliances. You still need to do your homework, but the inclusion of hardware does mean that you have one less thing to worry about during your purchase transaction.
Certain masters in this category, like T/Mon manufactured by DPS Telecom, support many other protocols beyond Modbus. This can be a great help when you need to bring an entire network of devices together. I've seen battery banks that use SNMP, generators that use Modbus, and RTUs that use their own proprietary protocol. If you want to get everything into one system, you need some kind of mediator.
Note that some people use T/Mon as a mediator instead of the absolute head-end.
One method is to bring Modbus, SNMP, and other protocols into T/Mon and use its list and map views to monitor your network. Another method is to bring, for example, only Modbus into T/Mon. That data can then be sent northbound up to a higher-level SNMP manager that has no way of natively accepting Modbus. In this way, T/Mon is useful as a Modbus mediator despite the presence of a higher-level master at the top of the system. The choice here is yours.
Whether you're stuck in the planning stages or are having trouble turning up an actual Modbus system, I can help you solve the problem.
I deal with Modbus a lot. Other than SNMP, it's the most common industry standard that I deal with. If I need assistance, I have access to the entire DPS Engineering team here at our headquarters.
Call DPS now at 1-800-693-0351. You can also email us at sales@dpstele.com
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...
