In this video, see a few simple steps. We'll start polling data from a backup generator (propane/diesel) using Modbus protocol. This example use the web interface of the NetGuardian DIN remote monitoring device.
There are two variants of the Modbus protocol: "Modbus RTU" and "Modbus TCP (IP)". One of these is Modbus RTU protocol. This variation is more compact, and uses binary communication. In this format, a Modbus RTU message is always followed by a cyclic redundancy check checksum, which are used to detect transmission problems.
The second variant is Modbus ASCII. This version is more verbose, and it uses hex ASCII encoding of data that can be read by human operators. A different type of checksum, the longitudinal redundancy check checksum, takes place after ASCII data transmissions. ASCII is the less secure of the two variants.
As it is also less efficient than Modbus RTU, operators must take care. Only utilize Modbus ASCII for the transmission of data to devices which do not support the RTU format. Modbus ASCII can also be useful when RTU messaging cannot be properly applied.
Modbus communications take place between a centralized master and up to 247 connected electronic devices on a single network. The design is commonly referred to as a "master/slave" protocol.
The system "master" requests information from connected Modbus devices, which are referred to as "slaves". Slave devices only send information to the master in response to these requests, and do not initiate messages. The master can also write information to the slave devices, but the slave devices cannot write information to the master.
When a slave device transmits a communication to the Modbus master, it begins the message with a unique address identifier. This is a number ranging from 1 to 247. This enables the master to identify which specific device is responding with the requested information.
Registers are formatted according to one of several "function codes" based on the data contained. You might have an analog fuel level value stored as an 8-bit integer. Instead, a register could use those same 8 bits to store 8 different binary values (door open, power fail, etc.) in a bitmap.
Just like any SCADA devices, the official Modbus function of "data acquisition" can vary.
The most common thing you probably think of is external sensors. You have a process that involves heat, so you put a temperature sensor near it. You have a sealed chamber, so you add a pressure sensor.
That's not the only way to acquire data, though. Many devices self-monitor and report via Modbus. Generators are a great example. They monitor their own fuel levels, temperatures, pressures, and more.
Finally, there are synthesized registers that depend on soft values like timers and calculations. "Time since last maintenance" could be tracked as an analog value, perhaps. Some generators have over 1000 registers to poll. Most of them aren't a physical sensor reading.
No matter what protocol you choose to use, you must never forget certain things.
Always focus on open protocols that don't trap you. By reading this article, you've already done that.
Open standards empower you to choose a new manufacturer later. Closed protocols written by one manufacturer don't do that.
Also, look for devices that speak in multiple protocols. You should always standardize as much as possible, but something WILL come up.
You'll want a piece of equipment, but it only understands DNP3 or CANBUS. Without the right HMI, good luck.
Even if you don't need it today, look for a multi-protocol HMI. That box might be called a "master station" if it does more than just SCADA.
Any SCADA system you choose will have a big impact on you. Your operations are important. SCADA protects those operations.
That's why you need to choose a manufacturer with a track record. "Big brands" can work, but sometimes they're too big to care about you unless you're huge also.
Proven providers who maintain a custom focus on your needs can be great. Look for a team that will back you with tech support. That tech support shouldn't be massively expensive.
Also, ask any sales rep you talk to whether designs can be changed. What if you need something unexpected. Will you get a solution, or will they just shrug?
Great shorthand for this is whether a company has its own engineers. Devices built overseas and merely sold in your country can be a problem. Good luck changing those designs when you need to.
Ideally, your SCADA manufacturer has strong control over design, manufacturing, sales, and support. That's a priceless tool for the problems you can't predict.
To protect yourself and your company, you need to get educated. The more you know about Modbus and SCADA generally, the better.
That's why I recommend these guides for you next. You have a full white paper on SCADA.
You can also read about the T/Mon HMI if you're evaluating solutions now. Finally, keep learning about tech with the RS485/RS232 article below.
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 a custom PDF application diagram that's a perfect fit for your network.
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 a Custom Diagram