Some Understanding of Modbus?

I should say that i am first and foremost an electrician who is moving direction towards the Building Management Systems of controls. So I am hoping that I am in the right place to learn and pick up some golden nuggets of information and understanding of the Modbus network structure.

I've been installing BMS systems in commercial projects, these recently changed from all field devices including AHU's HRU's being hard wired connected to the BMS panel for monitoring/controlling, to the new system which now splits the control of the AHU and the AC both separate to the BMS panel. All communication is now via a modbus network, which is completely new to me. On advice, I have downloaded a modbus scanner and whilst I can get it to operate I have not a clue at what I should be looking for?

The numbers seem to bear no resemblance to what I have read and watched on the web. So how much have I too learn???

So where am I? Well I understand (at least I think) the significance of the Baud rate, word, parity, stop bits, but have no idea of what they mean in real terms. I understand the slave Id, I have followed the modbus formula - but when I run the scanner the figures I see before me don't look anything like what I've seen.
The numbers are in pairs when I'd expect them to be in fours??

Any direction would be helpful, I'll answer any questions as best as I can, please be patient.
The Modbus Specs are of more value for those who are writing firmware/software Modbus code, but you'll need to implement Modbus between different vendors' devices, so for what you're doing I'd recommend

- Chipkin's Modbus for Field Technicians

- B+B's SmartWorx eBook on RS-485 (chapters are on-line)

I'll get to your numbers game question ("the figures I see before me don't look anything like what I've seen.") But before that, understand that Modbus does not define the format of the data it handles. It's like a mule. A mule doesn't know or care what load it carries, whether it's a sack of beans, a keg of gun powder, or a load mining tools. It just carries the load from point A to point B.

Like the mule, Modbus doesn't know or care whether the data it carries is process variables (temperature or pressure), switch status, the version number of the firmware, or Shakespeare. To Modbus it's just a bunch of binary bits, ones and zeroes. The task of Modbus is to get the bits from one end to the other. It's up to the software/firmware in the master and slave devices to interpret those bits properly so that the 16 bits in a Modbus register make sense.

In a practical sense, Modbus is both the hardware transport of bits back and forth and the application level of interpreting the values so that the bits make sense.

When you say a Modbus Scanner, I assume you're talking about a generic Modbus master that runs on a Windows PC. There are a number of those out there, some freeware, some are low cost when the trial version expires.

Some Masters display data in "traffic mode" which shows the entire Modbus message. Traffic mode shows all the numerical representations of contents of the Modbus message (typically leave out start and stop bits, just the data words), including the CRC error check values.

I rarely, if ever, use traffic mode because I'm not writing code and I don't need to see all the contents of a Modbus message. I assume the vendor has a properly working Modbus application and formats the Modbus message packet properly.

Instead, I use the mode that displays the contents of the data register or registers, because I need to make sure that the master/client is addressing the proper register in the slave/server. The register address is shown with its data value. The format of that value can typically be changed. The format can be a decimal value, a hexadecimal (hex) value (00-FF), a binary (ones and zeroes) value or a floating point (real) value. Decimal and floating point are the formats that make the most sense to humans, but sometimes one needs hex to pick out which bit is used for a switch or a coil.

Integers are whole numbers: 54, 9327, 10332. The 16 bit Modbus register can handle positive integers from 0 to 65535 and plus/negative integers between -32767 to +32767.

Sometimes an integer value is assumed to have, say, a one-digit decimal point as defined by the vendor and presumably documented in the Modbus section of the manual. So the integer value you see is 9329 but it needs to be interpreted as 932.9. It's up to the application to insert the decimal point for proper interpretation of the data value.

For numbers larger than what an integer can handle, there's long integers, two sequential 16 bit Modbus registers or floating point (also called 'real').

Be warned that not all master/clients can handle long integer values without some custom programming to handle the word and byte order of how the value needs to be interpreted.

The byte/word order issue also applies to floating point (FP) values. There are two major floating point formats (goes back to Intel vs Motorola microprocessor days). People used to refer to FP formats as little-endian or big-endian which on occasion would be mistranslated into Little Indian or Big Indian. Most master/clients provide a choice between the common floating point formats, so if the value should be 35.72 and the value comes out as -71.41285^17, then it's probably being interpreted with the wrong word/byte order. Although it could also be one register from one data value and the other register from a different value because of the one-offset addressing issue.

The one-offset issue comes up a lot. It happens because coders think in binary and start counting from zero whereas normal people (with 10 fingers) count in decimal and start counting with the number one (you never hold up one finger and say 'zero', and then two fingers and say 'one' do you? Well, coders do. In their defense, zero is the first register, one is the second register. cardinal vs ordinal numbers, if you're interested). So when you're trying to get the data out of a certain Modbus register it can take some experimentation to figure out whether the master/client wants the one-based decimal register number or the zero-based indexed offset value or the zero-based hexadecimal register value.

What is not well documented are the challenges of RS-485, the hardware transport layer for Modbus RTU (and the rarely used Modbus ASCII). (Ethernet is inherently isolated which eliminates a lot of electrical issues that 485 has)

Take the situation of wiring a master and a couple slaves on the commonly used 2 wire RS-485 network. Multiple 485 slaves are wired as a "daisy chain", all in parallel, from one to another to another.

Even if the EIA485 specification defines the polarity of the driver lines, A/B or (+)/(-), different vendors label them differently. So although the concept is to connect A on one end to A (all A terminals connected together) on the other end and B on one end to B on the other end (all B terminals connected together), what happens is that sometimes it just doesn't work because one of the vendors labels them the other way around.

The bad news is that the communications doesn't work when wired like that, but the good news is that wiring driver lines backwards does not damage the drivers, the wiring just needs to be swapped for that device. I know of one case where one division of a major vendor labels it one way, another division labels it 'backwards'.

RS-485 should be terminated with termination resistors at the nodes on the ends of the daisy chain (usually the master is at one end, although it can be in the middle somewhere) in order to prevent reflected energy from cause a comm error. Terminating in the middle of a daisy will kill communications.

2-wire 485 is a misnomer. RS-485 should be 3 wire with a signal ground. But many vendors do not implement a wiring terminal for signal ground and end up using the chassis ground. Chassis grounds at different locations can be at different ground potentials which can create common mode voltage which can affect the driver lines to the point where the comm won't work. The quick solution is to use and an isolated RS-485 repeater, which optically isolates the RS-485 input from the RS-485 output and eliminates the ground loop. I'm old school and I always use an RS-485 isolator to protect the RS-485 port on the master and if there are more than 4 slaves, I'll put a 485 isolator half way down the daisy chain to protect at least half the devices from damage due to an electrical fault that puts voltage on the 485 driver lines.

An RS-485 daisy chained, multidrop network should have a single point biasing with the (+) driver line biased to the +Vcc supply with a resistor and the (-) driver line biased to the signal ground with a resistor. But the practical problem issue is getting access to those power and ground points when the vendor does not provide them.

PC's have never had native RS-485 ports. So one always has to deal with a converter to get RS-485. The older serial port RS-232/485 converters that were 'port powered' were subject to power starvation by the PC. The newer USB/RS-485 converters do not have that particular issue, but I always recommend isolated converters because it solves common mode ground loop problems.
if I understand this correctly, the message is in hexadecimal code, so to translate it into readable message do we just use a straight translation from hex?

In one essence this seems more straightforward than I'd imagined. Then in the other sense it seems that it's almost impossible to translate, as there appears to be no given set standard for how different systems utilise the format, in that different manufacturers interpret the Modbus coding differently?
1. hexadecimal
No, hexadecimal is just for us humans to more readily identify a string of bits. Machines use binary, ones and zeroes. So, technically, the Modbus (and HART, Foundation Fieldbus, Profibus and all the other) message is binary.

But it is really hard for me to talk to you about, say, a problem that involves the interpretation of binary bit stream: 1111001000000001. It's a little easier to put spaces every four characters 1111 0010 0000 0001, but it's even easier to call each four binary bit words a hexadecimal character. Then we get F201. Machines don't bother with hex because they operate in binary.

In implementing Modbus, you need to deal with hex:

- when the vendor specifies their addressing mode in hex and you need to translate the known slave address at indexed hexadecimal offset value 156 to (4)0342 because that's what the master/client uses for register addressing.

- when bits are packed into a word and you need to decode the word and you use hex to make it easier to make sure you get the exact pattern correct (notice how many zeroes there are in a row in my example above?)

2. Translation
I don't think I've run into Modbus slave or master that hasn't dealt with integer data. If a 16 bit integer word does the trick, any master/slave combo can do it.

Many/most masters now deal with either of the two common 32 bit floating point format. A couple of the freeware 'scanners' only use one FP format (surprisingly).

Few masters deal with 64 bit floating points and might require some coding.

Same with 32 bit long integers, some do but there are word/byte order issues. This forum and the PLC forums have threads on moving data around to get it into the correct format.

Data like "date of manufacture" can be tricky because the data is coded. Just look at home formats there are for a date in an Excel spreadsheet. Someone picked a format and used that. So how do interpret it at the other end? Might need some coding, but frequently no one cares so it doesn't matter. It's data that's never used so it isn't an issue.

Because it's an open standard and there's no Modbus-organization-stamp-of-approval, one gets what one gets. But that's why you're so highly valued and paid so much - you can figure it out, right?
HI David,

Thanks for your time and input on this subject matter.

so ok, computers etc talk to each other in binary, got it,
the binary is arranged into groups of four for our benefit,
we then translate the blocks of four into hexadecimal for ease of translating into a readable language??

so when using a programme such as the CAS modbus scanner the figures that we see are in hexadecimal or binary, i note that we can switch between hex, bin, dec, im just trying to understand what it is that the modbus is communicating otherwise how will i ever know of it is working correctly?

you have answered why i'm not paid that much though!!!!