Modbus library for RTU, ASCII and TCP protocols. Primarily developed on and for ESP32 MCUs.
This release is focusing on Ethernet fixes and additions, but is adding also functionality for servers and bridges:
ETH.h
based Ethernet boards (like the WT32-ETH01) now a separate ModbusServerETH.h
was created that is to be used instead of ModbusServerEthernet.h
for these boards.ModbusServer
s now are supporting ANY_SERVER as a server ID to register a worker to. There are clients in the wild that seem to be using the server ID to signal stuff to servers. WARNING: servers registering ANY_SERVER workers will get all requests, especially on RTU, that not necessarily are meant for them.
Note that workers explicitly registered to a certain server ID/function code combination always will have precedence before the ANY_SERVER workers.lib_ldf_mode = deep+
to your platformio.ini
to avoid building problems with the Ethernet modules.ANY_SERVER
as a server ID in registerWorker()
calls. Read the docs before using this! https://github.com/eModbus/eModbus/pull/339
Full Changelog: https://github.com/eModbus/eModbus/compare/v1.7-stable...v1.7.1stable
This release brings a major rework of the ModbusRTU
handling. The arduino-esp32
core has integrated some more ESP-IDF modifications for UART handling from version 2.0.x on that we have adopted for eModbus.
Problem was, we fixedly required a HardwareSerial
as the communication object for our RTU classes. This prevented other channels like SoftwareSerial
to be used instead.
Now the RTU calls will accept any object that is derived from Stream
- including a HardwareSerial
. Moreover the Stream
object now will be passed in the begin()
calls of ModbusClientRTU
and ModbusServerRTU
and is not needed any more in the definition of these objects..
Minor: the start/stop calls of ModbusServerRTU
have been moved to begin
/end
for consistency with ModbusClientRTU
.
Pro:
SoftwareSerial
are possible nowbegin()
with a different Stream
object will be sufficientCon:
RTUutils::prepareHardwareSerial(HardwareSerial& interface);
, that must be called before you will do a HardwareSerial::begin()
. It will set up the required buffer sizes in the UART for Modbus to work correctly. If you will omit this call, you may encounter CRC and packet length errors.The asynchronous TCP client currently is being rewritten for a more stable operation on ESP8266. Things already have improved a lot, but there is some more to come in a later release.
ModbusClient
or ModbusServer
objects to be copied or assignedFull Changelog: https://github.com/eModbus/eModbus/compare/v1.6-stable...v1.7-stable
Documentation will be updated in short.
I missed a point in handling RTU serial flush - fired it after the rtsPin toggle already had been made. This prevented RTU messages being sent correctly.
The ModbusASCII protocol has been added. Several bug fixes and improvements.
Maintenance release containing all the fixes and minor improvements of the past months - no new features added.
This release sees to the addition of the CoilData
type. This type can be helpful dealing with the Modbus "coils" or "digital input" data types that have a specification not too well suited for C/C++ implementations.
Further the RTU receive handling has been changed to more relaxed timings. Especially larger RTU messages before could get stuck in the middle, resulting in a set of error messages.
Several bug fixes and minor additons are included as well.
Please also refer to the updated documentation.
This release brings a couple of new features, a rewrite of essential parts of server, client and bridge code plus a number of bug fixes. New features are:
Please see the updated documentation on the documentation site for details.
Warning: the ModbusBridge
classes' constructor signatures have been changed in relation to the previous release.