C0135 Original Firmware Properties
Here is why you may be looking for an alternative firmware for the C0135 MODBUS RTU relay board.
One device running the stock firmware, while powered by a weak power supply, replied with "random data" on any MODBUS node-ID used by the master.
Such a behavior isn't good news for anyone who operates a system that needs to be somewhat dependable: it will inevitably jam communication with all devices connected to the same bus.
- writing the value "0" to to holding registers 0 with FC06 sometimes results in "values written correctly" and sometimes in "Error: invalid data" and sometimes in the activation of relay 1. In this case using FC01 for reading coil 1 returns "1"!
- writing the value "0" to to holding registers 1 results in toggling between success and "Error: invalid data"
- using unsupported FCs results in a time out, not in the Exception Code specified by MODBUS
It's likely that the original firmware has more surprises to offer.
As documented in STM8 eForth issue #238, the original firmware tested violates the MODBUS timing requirement minimum 3.5 RS485 char times from request to response:
The stock firmware blatantly violates the silent interval requirements specified in chapter 2.5.1.1 of the spec, namely 0.15ms instead of 3.6ms at 9600 baud.
As the answer comes immediately it will result in a RS485 bus conflict when used with a standard-compliant MODBUS master: the relay module and the MODBUS master are in RS485 transmit mode at the same time and a part of the response from the relay module will be jammed.
Note that this significant timing violation won't be noticeable when testing with a PC and a 80ct "Black+Green RS485 USB" dongle like the one below:
These dongles use "TX = mark" for switching the RS485 direction and use a weak bias circuit instead of ever bringing the bus to "TX = space". This particular dongle uses a CH340G chip and a transistor as the inverter for "mark -> direction=transmit" / "space -> direction=receive". Other dongles use a 74HC04 inverter and a Prolific USB-RS232 (clone) but that doesn't change the fact that transmitting "TX=space" is only passive.
The bottom line is that any dongle that uses an inverter for switching the RS485 direction on TX=mark can't be used for more than a quick check of a single MODBUS node on the workbench. It won't work reliably of you go anywhere near the normal RS485 node count (up to 35) or bus length (up to 1000m). A test done with this dongle also won't expose the MODBUS protocol bug in the relay board stock firmware. More in the analysis of the Green+Black RS485 USB dongle.
Note that a viable CH340E based dongle (a chip with a dedicated direction control output) is in the RS485-CH340E project.
Setting multiple coils with FC15 results in a time-out. There is a non standard way for switching on all relays (using FC05 to write 1 to coil 255) but there is no obvious way for switching them off.
@anklimov provided a useful demonstration of the original C0136 MODBUS RTU relay board features using QModMaster.
Different vendors provide the following description for the set-up of the board:
Modbus RTU Command
Baud Rate: 9600 8 NONE 1
Send hex
Hexadecimal reception
Steps:
1. Software setting the baud rate
2. Set the address (device address used to communicate)
Since the device doesn't use the binary MODBUS protocol, the "send hex" and "Hexadecimal reception" are likely settings for the (unknown) software used for the following examples.
The example continues with the following session log:
Set the address is: 01
00 06 40 00 00 01 5c 1b
Set the address is: 02
00 06 40 00 00 02 1c 1a
Read address
00 03 40 00 00 01 90 1b
The address for the node-id given is 4000hex (16384dec). For MODBUS this is a highly unusual address: it's in fact out-of-range for FC06 "Set Single (Holding) Register". A likely explanation is that the stock firmware uses the MODBUS address as a pointer into the device memory space (0x4000 is the start address of the STM8S EEPROM area).
No example is given for setting the communication properties, so we have to assume for now that there is no way to configure baud rate, start/stop bits or any delays.
Read the software version
00 03 00 04 00 01 c4 1a // [month] broadcast read (only by one device, for all addresses practical, easy to test)
0,003,000,800,010,419 [years] // broadcast read (only by one device, for all addresses practical, easy to test)
00 03 00 10 00 01 84 1e [hour, minute] // broadcast read (only by one device, for all addresses practical, easy to test)
Read the hardware version (PCB version)
0,003,002,000,018,411 // broadcast read (only by one device, for all addresses practical, easy to test)
The use of FC03 "Read Holding Registers" is also interesting. Based on the hypothesis that commas and blanks in the 2nd and 4th line are the result of manual editing it can be assumed that it's really 00 03 00 08 00 01 04 19 (years) and 00 03 00 20 00 01 84 11 (PCB version).
The example for FC05 "Write Single Coil" is a bit dubious since for switching on ("open") relais (or "coils" in MODBUS lingo) a non-zero data value is applied. The standard requires this to be FF00hex.
[1 Address]
The 1st relay open
01 05 00 01 01 00 9d 9a
Relay 1 closed
01 05 00 01 00 00 9c 0a
The 2nd relay open
01 05 00 02 01 00 6d 9a
2 Relay Off
01 05 00 02 00 00 6c 0a
The 3rd relay open
01 05 00 03 01 00 3c 5a
3 Relay Off
01 05 00 03 00 00 3d ca
4 relay open
01 05 00 04 01 00 8d 9b
4 Relay Off
01 05 00 04 00 00 8c 0b
All off
01 05 00 ff 00 00 fd fa
All light
01 05 00 ff ff ff fc 4a
The last example uses a non-standard way of switching on or off all relays.
More tests with the stock firmware are required to learn more about these "solutions" and if other FCs are supported (e.g. FC15 which should normally be used for switching multiple coils).
It's clear that it's more suitable to see it as a development board than as a ready-to-use product!