Download our free SCADA tutorial.
An introduction to SCADA from your own perspective.
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 protocols are popular for all sorts of industrial devices. You'll find generators, HVAC systems, and plenty of other devices that use a Modbus communications protocol to share their current status.
There are two major variants of this protocol: Modbus RTU & Modbus TCP.
Traditionally, Modbus RTU was used by (you guessed it!) RTUs that needed to communicate information back to a Modbus master or SCADA HMI. Despite the name, Modbus RTU is used by many different kinds of devices today.
Modbus RTU was commonly sent via RS485 serial. This daisy-chained communication channel allowed multiple devices to report to a single HMI port in a master-slave configuration. Each slave device was able to speak by sending traffic toward the master device. That allowed the Modbus network structure to remain fairly simple.
Modbus TCP is named because it differed from early Modbus by using TCP/IP for reading/writing register values.
It's important to remember today that the names of these two variants don't always apply anymore. You'll sometimes see Modbus RTU used by other types of devices and encapsulated over IP.
No matter the variant, all standard Modbus communication follows the same messaging structure. Everything revolves around storing values in registers and then reading them. There are several data types in play here.
A discrete input can be stored, for example, as a single bit. More broadly, input registers store values that your Modbus-based device has collected. You might have multiple discretes stored as single bits, while an analog value or even ASCII characters might be stored in an 8-bit register (the least significant bit being the 0 bit and the most significant bit being the 64 bit).
The different types of registers are classified by the function codes used to poll them. A "1" in the Function Code field is used to "Read Coil" (check the status of a control relay). A "2" is "Read Discrete Input" (check the status of a discrete input). "3" is "Read Holding Registers" (collect data from multi-purpose read/write registers). There are many more in the Modbus spec.
Registers are requested by their "starting address", which is a 16-bit value that uniquely identifies each register within the device. Master requests to an RTU or other device will always make reference to the desired register(s) to be reported.
One fairly new device type that entered the marketplace a few years ago is the Modbus-polling RTU. These are remote-monitoring devices that don't just collect alarms from discrete relay outputs, but also by collecting Modbus data from other devices.
One example of such a device is the DPS "Modbox". This is built on the same platform as a traditional NetGuardian RTU but has added serial ports and firmware to interact with important devices like generators.
What you absolutely have to keep in mind while evaluating devices like this is the number of input registers and holding registers you can poll. The Modbox wasn't the first device of its kind that we built. At DPS, I had clients years ago who wanted to poll a small-to-medium number of registers.
That led to initial variants of small and medium NetGuardian RTUs like the M16 or the DIN. These were equipped to handle 32 or 64 registers. Because this is a reasonable number, it fits easily in the existing NetGuardian memory space.
Then, one day, a large government entity approached me about a similar but much larger device. Their goal was to 100% collect from a generator that has over 1000 registers. This was a big, hairy goal because the storage for 1000+ registers was not inconsequential on an embedded RTU platform. Still, we managed to make it work with some clever redesigns.
Over time, we then added Function Code support to handle the full range of Modbus register types that this client wanted to collect.
Since you're researching the Modbus protocol specification, it's likely you're working on a project that will involve a master station in some capacity.
We've already discussed some of the specifics of Modbus, but let's take a minute to go through some of the key elements of a good master station - both for this protocol and in general.
First, any master station that you're considering has to support all of the protocols that you use in your network. Sure, you're using Modbus, but what other gear do you have? Do you also use the popular SCADA protocol DNP3? What about SNMP from the telecom world?
What you never want to do is have multiple incompatible systems. That multiplies the staff you need to operate your SCADA system, the training you have to give them, and the chance that someone misses an important event.
Second, you need the single master station you choose to be reliable. There's no sense in reducing device count only to create a single point of failure. Look for proven hardware, redundant hard disks (or even SSDs), and redundant power supplies.
Finally, look for a high level of service that's included with your Modbus master. Unless you're a hobbyist, your network is tremendously important to each and every one of your users. Protect it with a manufacturer who will support you.
This starts with the initial design of your system before you buy. It continues with turn-up and training. It ends with on-going tech support and even regular "tune-up" visits from a factory-trained engineer.
I'm part of the team that designs and evolves T/Mon to be an effective multi-protocol master. It implements each piece of advice I mentioned above.
If you have Modbus and other protocols in your network (or even just Modbus), take a minute to review some of the key elements of T/Mon. If you want to manage all of your remote equipment with easy-to-understand map displays, automatic if-then responses, and email/SMS alerts, it could be an effective tool for you.
Like all DPS systems, T/Mon includes free lifetime tech support and free Factory Training.
To go over Modbus generally or discuss a specific project, just give me a call: 1-800-693-0351.
