Modbus communication issues

I’m trying to use Electron to monitor an energy meter using Modbus. I’m using the MODBUSMASTER library. At first, the data from the meter seemed to be corrupted and after analyzing the traffic using a RS485 USB adapter, I noticed that the Electron was sending a request for another holding register. It looked like the library added 1 to my requested address, so I had to substract 1 from the requested address in order to work.

After fixing this, I only get a few minutes of reliable communication with the energy meter, then all the requests fail. It starts working again after I restart the Electron.

I’m using the MAX485 transceiver on a breadboard.

Has anybody tried the ModbusMaster library on the Electron ? Did it work properly ? Do you have any advice for troubleshooting this ? In my case it looks like the library has several bugs.


It looks like that library’s GitHub repo is here: Perhaps raise an issue there and the library creator can help?

I tried to contact the authors and I’ve got no answer so far. Does anybody have any idea why would the library only work for a few minutes or so ?

@stelian, looking at the library, I don’t see much that can go wrong. Perhaps it is something in your code so can you please post it?

1 Like

It works now. Initially, I had the Kickstarter version of the Electron, with 2G. I replaced it with the 3G version and now it has been working continuously for 3 days without an issue. I still don’t know the cause.

UPDATE : It was a hardware problem. I was unaware of the fact that the MAX485 doesn’t work properly with a 3.3 V supply. There is a 3.3 V version of the chip, but I gave it 5 V and added a level shifter on its RO pin.

I’m using Electron to monitor energy meter as well. Peekay’s library works awesome for either 485 or 232. However, I found a minor issue:
in Modbusmaster.h variable that controls modbus response timeout is defined as uint8_t, therefore limiting timeout to 256 milliseconds. I found it not long enough for some older meters (some need 500-700 ms).
I think unit8_t should be uint16_t at least to allow for longer waits.
The line of code is
// Modbus timeout [milliseconds]
static const uint8_t ku8MBResponseTimeout = 200; ///< Modbus timeout [milliseconds]