Both connected using modbus wires, GND that modbus device requires and Mikrotik seems to not give a f*&^ about connected to GPIO GND PIN 1 (parity, baud ok)
Address of my holding register according to parameters manual is 40004
About the syntax, I would try with command transceive and function 3, read-holding-registers seems like an "alias" of some kind, and in case you should try exactly as the example in the given page shows.
Well, my guess Is that if you ask in a "wrong" way or at a "wrong" address, you get no response (no matter the timeout).
But It Is just my opinion.
The only certain thing Is that since 1000ms Is the absolute maximum allowed you cannot raise It.
No idea about the wire connection of your device, generally speaking the common gnd Is needed whenever there can be a different potential between the two devices.
That’s true.
I’m judging by my current equipment that fetches params already with ~2sec timeout and only then it works (barely).
I’ll leave some datapoints for future users:
The A+,B-,GND connection is valid and can work with KNOTs, just use GPIO, pin 1 (upper right when holding the device “normally”)
most modbus devices should expose some kind of ‘ping’ function, which can at least tell you that IO-wise everything is OK. Check in manual for “device identificatation function” and invoke it like so `/iot modbus transceive address=1 function=43 data=0E0100`, function in decimal format, the payload likely doesn’t matter much but the one in example is “some standard one”
As of my case:
I can read the Device ID
I can’t read the registers, timeout all the time, using /iot modbus transceive address=1 function=3 data=00030001
00030001 still seems "wrong" to me, the data is a STRING, composed by a set of two HEX tuplets, according to
(and citing myself): Modbus RTU with Knot - #2 by jaclaz
30001-30001=0->0000
1 register x 2->0002 (or maybe 1 is fine? or for function 3 it isn't needed and can be 0?)
The only sure thing again is that 00030001 does not mean the first register (which is probably what you want to retrieve), the 30001 is the address of the register and its corresponding Modbus address is 0x00,0x00 that combines on the tuplet 0x0000.
Modbus is an ancient protocol, constrained by the hardware at the time - typically a maximum of 64kB for program and data so often protocol data is taken directly from memory rather than being nicely formatted.
Looking at the datasheet for the target device the registers have addresses in the range 40001-65534 decimal so /iot modbus tranceive address=1 function=3 data=9c610001 should return the room temperature (register 40033).
The main issue is that the maximum timeout you can configure on the Mikrotik is 1000mSec, and unless the target device is configured to poll the specific variables you will be requesting it requires a timeout of 2.1 seconds.
But if added to the LOG set, timeout for the register read reply should be 0.5s, so, doable, once the register is added to the LOG through use of that Modbus Manager/Updater program.
It is the addressing and format to use with the Mikrotik command that is not clear (at least to me).
If you say that (notwithstanding what is written in Mikrotik help) the first tuplet is the absolute register address in hex:
40033->9C61
and that the second tuplet is the number of registers:
1->0001
it is logical and easy to test, IF that register can be added to LOG.
To read 40033 you have IMHO to use function 3 and convert it to:
40033-40001=32->0x20->0x0020
and the second tuplet 0x0001
In Modbus, relative addresses are just a little bit more complicated than this. Relative addresses actually span a range beginning at zero, while absolute addresses begin with “1” as the least-significant digit. This means there is an additional offset of 1 between a Modbus relative address and its corresponding absolute address. Returning to the hotel analogy, imagine the very first room on the third floor was room 301 (i.e. there was no room 300) and that the relative address represented the number of rooms past that first room. In this unintuitive scheme, room 314 could be specified as “the 13th room after the starting room on the third floor”. If this seems needlessly confusing, you are not alone. Welcome to Hotel Modbus.
A few examples are given here for illustration:
Read the content of contact register 12440: Modbus read function 02; relative address 2439
Read the content of analog input register 30050: Modbus read function 04; relative address 49
Read the content of holding register 41000: Modbus read function 03; relative address 999
Write multiple output coils in register 00008: Modbus write function 15; relative address 7
In each case, the pattern is the same: the relative address gets added to the first address of that range in order to arrive at the absolute address within the Modbus device. Referencing the first example shown above: 2439 (relative address) + 10001 (first address of register range) = 12440 (absolute address). Thankfully, the only time you are likely to contend with relative addressing is if you program a computer using some low-level language such as assembly or C++.
Most high-level industrial programming languages such as Function Block or Ladder Diagram make it easy for the end-user by allowing absolute addresses to be directly specified in the read and write commands. In a typical PLC program, for example, you would read contact register 12440 by simply specifying the number 12440 within the address field of a “read 02” instruction.
The timeout is indeed my problem, I’ve created the LOG.SET file to test reads.
First:
To add even more confusion, according to linked Mikrotik Manual about data parameter:
Input data string that usually specifies register address and data to be sent.
For example:
data=20000001
The data string is 4 bytes long. "0x2000" is the command to the register (2 bytes long) and "0x0001" (2 bytes long) is the device's address.
See the Modbus device's specifications for the exact data string that needs to be sent.
I’m also confused about absolute vs relative address - seems that both methods work
Unfortunately the LOG.SET for my device accepts 20 parameters top, which is far too low for me.
I’ve submitted the Mikrotik bug about too low configurable timeout (it is ridiculous)
It Is possible that in the range of possible values 0x0000-0xFFFF "low" values are considered relative addresses and "high" ones are considered absolute ones?
Since each "section" contains 9999 registers, the "switch" should happen at 10000 or 0x2710 ...
Or It Is the device that when a register Is added to the LOG offers the "other" address?
No way to know for sure, due to the timeout issue with non-added-to-LOG registers.
to test, IF that register can be added to LOG.