Modbus RTU - Home Automation Question

Hi everyone.

My experience with Modbus RTU is very limited however I need some help with my Home Automation system.

I have a battery storage system that has an inverter and meter. The meter is set to ID-01 and i assume the inverter is the modbus master. The company supplying the inverter has given me a piece of software that uses my USB to RS485 Converter. This software allows me to interrogate the inverter which i am looking to do outside of the software via a small home automation PLC.

I am really struggling to get anything other than their propitiatory software to do any of the interrogation. Its definitely using Modbus RTU to communicate and it all wires into the same RS485 ports on the inverter the ID-01 Meter uses.

The company has given the modbus RTU Address listing and thats about it. I know the Baud rate etc... but nothing else.

What would anyone suggest to do to get this working?

Cheers,

Mike
 
The buzzer on the TV quiz game started squawking EHHHHHHHHHH at your statement "I assume the inverter is the Modbus Master". That's a false assumption. Field devices are generally a Modbus slave/server. The proprietary software that you have has Modbus Master/client functionality.

And I'm not guessing - a Modbus Master NEVER has a Modbus RTU Address listing (unless it has concurrent slave functionality, which a PLC might, but drives do not), what I call the slave register map, because only slave/servers have a address listing/map. So your PLC will need to be a Modbus master/client functionality to read directly from the inverter.

Some Modbus rules:
Slaves are passive, they are silent unless spoken to and only acknowledge a message addressed to them (slave ID 01 in this case)

The labeling of the RS-485 driver lines is not consistent throughout the industry. Wiring is supposed to be (+) to (+), (-) to (-) or A to A, B to B. You lucked out this time connecting your USB/RS-485 converter (anyone has a 50% chance of getting it right). But some vendors label the other way. So when you cannot establish communication (master times-out because it gets no reply at all) then try swapping the driver line wires at one end.

All RS-485 serial setttings must be identical on both ends.

The dreaded one offset in register addressing. Programmers start counting from zero: 0, 1, 2, 3. Real people start counting from 1: 1, 2, 3, 4. Slave register maps have register addresses that are either referenced to zero or to one but rarely does the Modbus documentation spell it out. It's important because you want to read data from a specific register, not the adjacent register. Hexadecimal addresses are typically zero based. Addresses that use the leading numeral to designate memory area, like the leading numeral three for Input Registers, (3)xxxx or the leading numeral four for Holding Registers (4)xxxx are almost always one based. For example, a Holding Registers would start at (4)0001, even though the binary in the Modbus message itself has the register identified as 0000, addressed with Function Code 03 (read Holding Register).

If the inverter has floating point (FP) or 'real' values, you might discover that the PLC will read the data but come up with NaN (Not a Number) or really bizzare values like 4.0234e-16 when the value should 59.72. The weird numbers come from misinterpreting 32 bit floating point number. There are 4 word/byte orders for IEEE754 32 bit floating point values, two of which are commonly used in Modbus (sometimes called Big Endian, the other Little Endian Byte Swap). Some master/clients offer a means of choosing which format to use for interpretation. Others ignore the multiple formats and the PLC needs some bit banging to move the bytes around to get them into the order the PLC uses to interpret 32 bit FPs.

It pays to use shielded twisted pair cable for the RS-485 communications around inverter/drives and do not run it next to or in parallel with the heavy current carrying conductors.

The PLC needs to be programmed to do something with the data it receives, typically move the data somewhere.
 
Thanks for your reply David.

Spent some days now trying to work this out and like always with Modbus in previously working life it makes my head spin.

I am getting very little support from the company who supply the product, all they did is supply me with their Modbus RTU & TCP Documents which are translated from Chinese.

I am now very stuck and given up on the RTU. though i think i have found out whats happening. The power inverter is a modbus Master that polls a small electricity meter (ID01). When using their software they supplied me which they say is modbus and it does work. Its just a small 300kb EXE file that runs over a USB to RS485 converter. I plugged that into another USB to RS485 convert and did a scan and looks as though its transmitting with Modbus ID 17, suggesting the Software is slave device.

I have tried so many pieces of software to try and get it working, but very little is deciphered.

I then played with Modbus TCP and used the port 8899 which is their modbus Tcp port i think (using Modbus POLL).
using the IP Address of the inverter and port 8899.


Tx:000000-00 19 00 00 00 06 11 03 00 01 00 01
Tx:000001-00 1A 00 00 00 06 11 03 00 01 00 01
Tx:000002-00 1B 00 00 00 06 11 03 00 01 00 01
Tx:000003-00 1C 00 00 00 06 11 03 00 01 00 01
Tx:000004-00 1D 00 00 00 06 11 03 00 01 00 01
Tx:000005-00 1E 00 00 00 06 11 03 00 01 00 01
Tx:000006-00 1F 00 00 00 06 11 03 00 01 00 01
Tx:000007-00 20 00 00 00 06 11 03 00 01 00 01
Tx:000008-00 21 00 00 00 06 11 03 00 01 00 01
Tx:000009-00 22 00 00 00 06 11 03 00 01 00 01
Tx:000010-00 23 00 00 00 06 11 03 00 01 00 01
Tx:000011-00 24 00 00 00 06 11 03 00 01 00 01
Tx:000012-00 25 00 00 00 06 11 03 00 01 00 01
Tx:000013-00 26 00 00 00 06 11 03 00 01 00 01
Tx:000014-00 27 00 00 00 06 11 03 00 01 00 01
Tx:000015-00 28 00 00 00 06 11 03 00 01 00 01
Tx:000016-00 29 00 00 00 06 11 03 00 01 00 01
Rx:000017-59 59 00 01 00 9E 01 02 57 46 32 30 31 36 47 31 33 36 00 00 00 00 00 00 00 8A 32 04 43 45 32 30 32 34 47 30 31 39 00 3C 00 3C 0C 71 0C 71 0C 73 0C 73 0C 71 0C 73 0C 71 0C 73 0C 73 0C 71 0C 73 0C 73 0C 71 0C 71 0C 73 0C 73 01 3C 01 4F 01 47 01 3F C7 2D 01 21 00 00 C6 AF 00 00 40 E3 00 00 3E 80 00 00 0A 0D 00 00 06 10 00 00 00 00 00 00 00 00 00 0F 00 10 04 05 00 00 00 0F 00 00 3E 80 01 4F 01 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 D8
Tx:000018-00 2A 00 00 00 06 11 03 00 01 00 01


I suddenly got a received note. I think my problem lies in how they are breaking their packets up? I just think my knowledge is now limited at this stage and being able to fault find.

Can you or anyone at all help me with this. I am completely going mad.

Thanks in advance for the information

Mike
 
Something doesn't make "Modbus" sense here.

Apparently the inverter, a Modbus RTU Master, is communicating to a meter, a Modbus RTU slave, over RS-485. Correct?

The specification/rule for Modbus RTU is that only one Master is allowed on the network in order to avoid collisions between data packets because of the way RS-485 works (tristating). An RS-485 Modbus RTU network assumes one and only one Master where the master polls then waits for each slave to respond/reply. There is no bus regulation for multiple masters, like there is in Modbus Plus, a token-passing licensed version of Modbus.

So, the proprietary software can't be a Modbus Master that communicates to the inverter over that same RS-485 link without the high probability of disrupting the RS-485 RTU communications between the inverter and the meter.

What is interesting is that the request messages you posted appears to be a properly formatted Modbus TCP request messages with an MBAP header, NOT a Modbus RTU message.

The first 7 bytes are an MBAP Modbus/TCP header.

Taking the first message: 00 19 00 00 00 06 11 03 00 01 00 01

- first two bytes: 0019(h) is the transaction number and you'll note that the value increments with each message

- Second two bytes is the protocol identifier, always 0000(h)

- 3rd set of two bytes is the number of bytes in the message to follow:
0006(h) or six bytes.

- 11(h) is the Slave/unit/note ID
- 03(h) is the Function Code (Read Holding register)
- 0001(h) is the start address, 0001(h) or (4)0002 (decimal) [0000(h) = (4)0001 decimal]
- 0001(h) is the requested quantity of registers, or one register at 0001(h) or (4)0002

That all makes sense for Modbus TCP over Ethernet.

For reasons unknown, there is no reply until the 17th request generates a reply, but the reply does not make sense, which since it's a TCP formatted message over RTU, why would one expect a reply?

- 5959(h) transaction request
- 0001(h) = protocol identifier, ? ?
- 009E(h) is the number of bytes following
- 01(h) slave identifier - ?
- 02(h) Function Code ? (read discrete input status
- 0257(h) byte count (599 dec)
- a slew of data values

If the proprietary software really is a Modbus Master, then it would have to connect to a separate physical port, not the 485 port used for the Inverter communicating to the meter because that puts two masters on the same RTU network (violates thr Rule). There are devices that are simultaneous/concurrent Modbus RTU Master/slaves, but the master and slave functions use separate RS-485 ports, or an Ethernet port and an RS-485 port.

Maybe the proprietary PC software, knowing what it is communicating with (the inverter), can disable or halt the Inverter/Meter comm long enough to communicate with the inverter. But you can't mimic that with ordinary Modbus software without having the proprietary function documented for you.

Does the inverter have an assignable Ethernet port? Try the software with the Ethernet port.

Is the Modbus RTU address listing you've been provided for the inverter or the meter? Maybe the Chinese think you've asked for the meter slave map?

It just occurred to me, could the Modbus slave register list refer to the proprietary software, not the inverter, nor the meter?

Maybe the proprietary program is a Modbus Slave program that uses a slave ID outside the normal range, like 254 (the spec says slave ID's limited to 1-247).

The inverter master periodically polls to see if 254 is out there. If it is, then it writes data to the specified registers. That allows the proprietary software to reside on the network as an almost-ordinary Modbus RTU slave.

It does not explain the MBAP header in the RTU traffic.
 
The company supplying the inverter has given me a piece of software that uses my USB to RS485 Converter.
The company has given the modbus RTU Address listing and thats about it.
I am getting very little support from the company who supply the product, all they did is supply me with their Modbus RTU & TCP Documents which are translated from Chinese.
Typically the Modbus documentation is you would need in order to establish successful Modbus communications to a device. However, sometimes these documents do require a bit of deciphering by someone experienced in Modbus.

Perhaps if you would attach the above-referenced documentation and software, we would be able to better help you solve your issue.
 
Hey.

So what i think is happening is the Software is Modbus RTU Slave with no idea what the slave address is. I had a guess of HEX 11 (ID 17).

I am basically trying to emulate what the software is doing with my home automation system. Though to confuse things my home automation system can only be a MOdbus TCP Master or Modbus RTU Master. So i would probably need a convert RTU to TCP Slave or something.

I have attached a copy of their software as a ZIP File.
I have played around with all of the Modbus Slave/Master Simulators to no success.

Note the inverter has a WIFI Only port. I have a feeling that is using a PORT 8899 as no other parts were open apart from 80.

ANy help is greatly appreciated.

Thanks
Mike
 

Attachments

OK, I tracked down the issue. The manufacturer implemented Modbus RTU wrong. The CRC bytes are in the wrong order. So of course this will only work between their own products.

The inverter is a Modbus RTU slave and uses slave address 17. The software is a Modbus Master and sends the following requests to slave address 17 (using 0-based addressing, since that's what's used in the inverter's Modbus RTU documentation):

Read Holding Register Addresses 0 - 59
11 03 00 00 00 3c 4b 47

Read Holding Register Addresses 60 - 119
11 03 00 3c 00 3c 47 87

Read Input Register Addresses 0 - 59
11 04 00 00 00 3c 8b f2

Here's what those requests are supposed to look like, when following the Modbus RTU specification (note that the last two bytes are swapped):

Read Holding Register Addresses 0 - 59
11 03 00 00 00 3c 47 4b

Read Holding Register Addresses 60 - 119
11 03 00 3c 00 3c 87 47

Read Input Register Addresses 0 - 59
11 04 00 00 00 3c f2 8b

Regarding Modbus/TCP, the document you attached seems to indicate that only the "Datalogger" device supports Modbus/TCP, not the inverter. The datalogger may use some proprietary protocol to communicate to the inverter. This is further supported by your claim that only ports 8899 and 80 are open. Modbus/TCP uses port 502.

I think you have two options for getting this to work.

1. Contact the manufacturer and get them to fix their inverter firmware and their software to correctly implement the Modbus RTU protocol.

2. Use a gateway device that can convert this incorrect version of Modbus RTU to standard Modbus RTU or Modbus/TCP. ICC's gateways support a Generic Serial Master driver that would be capable of communicating to the inverter. The Mirius gateway can perform the conversion to standard Modbus RTU. If you want to go directly to Modbus/TCP, then you can use the ETH-1000.

Mirius:
http://www.iccdesigns.com/protocol-gateways/66-mirius.html

ETH-1000:
http://www.iccdesigns.com/millennium-series/10-eth-1000.html
 
One other option I just thought of, in the Modbus TCP Protocol document you attached, the "Datalogger" is described as a "Wi-Fi, 3G and 4G dongle" and it seems it's this datalogger that supports Modbus/TCP.

So the other option would be to obtain a Wi-Fi DataLogger, which would presumably allow you to communicate Modbus/TCP over WiFi to your home automation system.
 
Thread starter Similar threads Forum Replies Date
G Modbus 3
P Modbus 15
M Modbus 21
L Modbus 2
A Modbus 1
Top