EModbus Versions Save

Modbus library for RTU, ASCII and TCP protocols. Primarily developed on and for ESP32 MCUs.

v1.7.2stable

1 month ago

This release is focusing on Ethernet fixes and additions, but is adding also functionality for servers and bridges:

  • for 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.
  • The older special Ethernet library by @maxgerhardt was removed. eModbus now uses the standard Ethernet library instead
  • The ModbusServers 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.
  • Bridges now can have filtering functions for all requests and/or responses coming through the bridge. Hence you may manipulate both requests and responses to cope with different capabilities of the requesting clients or the servers responding.
  • Note to all users of Platformio: please be sure to add lib_ldf_mode = deep+ to your platformio.ini to avoid building problems with the Ethernet modules.

v1.7.1stable

3 months ago

What's Changed

New Contributors

Full Changelog: https://github.com/eModbus/eModbus/compare/v1.7-stable...v1.7.1stable

v1.7-stable

1 year ago

Changes

Serial handling

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:

  • there is no more fiddling with UART configurations inside the library any more
  • other channels, like SoftwareSerial are possible now
  • no more dependencies from ESP32 varieties having different UART configurations
  • Channels may be switched at run time - a fresh begin() with a different Stream object will be sufficient

Con:

  • This is breaking the previous interface
  • There is a service call 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.
  • it will be more difficult to tell where a certain issue may be originating

Async TCP

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.

What's Changed Else

New Contributors

Full Changelog: https://github.com/eModbus/eModbus/compare/v1.6-stable...v1.7-stable

v1.6-stable

1 year ago
  • added RTU Broadcast handling
  • added RTU sniffer
  • make getter calls const for const message objects
  • allow unregistering servers/function codes
  • add error counters to servers and clients
  • miscellaneous bug fixes

Documentation will be updated in short.

v1.5-stable

2 years ago

This release brings a reworked RTU receive logic.

  • Thanks to @OekoSolveMG's and @TLS1000 help and patience we could fix a long-living issue that would strike with lower baud rates. The symptoms were repeated E2 (CRC) and E5 (packet length) errors.
  • @EmbeddedDevver provided an improvement to the async TCP logic that is vastly increasing the throughput.
  • on request now it is possible to use function codes that are illegal as seen from the Modbus standard (🙈 )
  • Some physical RTU setups seem to be difficult to tune to work flawlessly. A work-around has been added to skip "ghost" zero bytes generated by the bus electronics 👻
  • plus some fixes of minor issues.

v1.4.1-fixed

2 years ago

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.

v1.4-stable

2 years ago

The ModbusASCII protocol has been added. Several bug fixes and improvements.

v1.3-stable

2 years ago

Maintenance release containing all the fixes and minor improvements of the past months - no new features added.

v1.2-stable

3 years ago

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.

v1.1-stable

3 years ago

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:

  • synchronous requests
  • onResponse callback
  • RTScallback
  • lambda functions as callbacks
  • updated Linux examples

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.