Releases: eModbus/eModbus
v1.7.4.stable
What's Changed
- Allow
attachServer(ANY_SERVER, ANY_SERVER, ANY_FUNCTION_CODE, client)to create an "open bridge". This will let pass any request to the client regardless of server ID, hence creating an unrestricted and unguarded access to the Modbus the client is controlling. - Use tskNO_AFFINITY instead of NULL in xTaskCreatePinnedToCore by @guido4096 in #411
- Fix out-of-bounds access in setFunctionCode() by @KOMAD-bit in #412
New Contributors
- @guido4096 made their first contribution in #411
- @KOMAD-bit made their first contribution in #412
Full Changelog: v1.7.3.stable...v1.7.4.stable
1.7.3 stable
What's Changed
- CI update by @bertmelis in #355
- Add function set timeout by @gary7530 in #373
- Prevent unnecessary reallocs by @monsieurvor in #384
- remove the front request only when the request queue is not empty. by @gary7530 in #394
- Update dependencies by @bertmelis in #398
- Fixes and additions for 1.7.3 by @Miq1 in #401
New TCP close-on-timeout function
@mifarelight raised an issue where a TCP connection on a client would hang for a long time if a server was cut off the network. Basically this was caused by the connected() call in the core still reporting true despite the fact that the connection was long gone.
To get around this, a new function was added to ModbusClientTCP:
// Set number of timeouts to tolerate before a connection is forcibly closed.
// 0: never, 1..255: desired number
// Returns previous value.
uint8_t closeConnectionOnTimeouts(uint8_t n=3);
Example:
ModbusClientTCP mbc;
...
mbc.closeConnectionOnTimeouts();
...
That will tolerate 3 consecutive timeouts (the default if called without value) and cut the connection upon the fourth. You can disable that by calling the function with a 0 argument.
New Contributors
- @gary7530 made their first contribution in #373
- @monsieurvor made their first contribution in #384
Full Changelog: v1.7.2stable...v1.7.3.stable
v1.7.2stable
This release is focusing on Ethernet fixes and additions, but is adding also functionality for servers and bridges:
- for
ETH.hbased Ethernet boards (like the WT32-ETH01) now a separateModbusServerETH.hwas created that is to be used instead ofModbusServerEthernet.hfor 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 yourplatformio.inito avoid building problems with the Ethernet modules.
Little fixes and additions
What's Changed
- don't flush, since on arduino this also clears the RX buffer by @zivillian in #312
- New : function to clear message queue by @ameisso in #333
- Remove 'register' for c++17 compatibility by @jmceleney in #334
- New : optional 'userInterval' parameter in RTU begin() calls to intentionally increase the quiet times between messages
- New : optional use of
ANY_SERVERas a server ID inregisterWorker()calls. Read the docs before using this! #339 - Various small bug fixes and streamlining
- Doc changes on eModbus.github.io
New Contributors
- @zivillian made their first contribution in #312
- @ameisso made their first contribution in #333
- @jmceleney made their first contribution in #334
Full Changelog: v1.7-stable...v1.7.1stable
RTU rework
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
SoftwareSerialare possible now - no more dependencies from ESP32 varieties having different UART configurations
- Channels may be switched at run time - a fresh
begin()with a differentStreamobject 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 aHardwareSerial::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
- Matching serial output to snippet at base by @PapaBeans in #217
- stop Async server only if it's running by @dsilletti in #246
- Fix compiler warnings by @bertmelis in #259
- Prevent
ModbusClientorModbusServerobjects to be copied or assigned
New Contributors
- @PapaBeans made their first contribution in #217
- @dsilletti made their first contribution in #246
Full Changelog: v1.6-stable...v1.7-stable
Bunch of flowers
- 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.
RTU rework
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.
ModbusASCII - hot fix
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.
ModbusASCII
The ModbusASCII protocol has been added. Several bug fixes and improvements.
Maintenance release
Maintenance release containing all the fixes and minor improvements of the past months - no new features added.