Question

Hello,
I just upgraded to firmware version RUTX_R_00.07.03 on my RUTX11 and it seems that the command modbus_tcp_test is not available anymore. Can you confirm that this command was indeed removed in the last fw version? Is there any alternative? I have some scripts heavily relying on it and would appreciate not to have to rewrite everything...
Thanks in advance

Answer 1

Hello,

In 7.3 modbus_tcp_test functionality has been moved to ubus object modbus_master.

Below is a general description of a string for Modbus TCP:

"tcp.test":{"id":"Integer","timeout":"Integer","function":"Integer","first_reg":"Integer","reg_count":"String","data_type":"String","no_brackets":"Integer","ip":"String","port":"Integer"}

An example command would look the following:

ubus call modbus_master tcp.test '{"ip":"192.168.10.1", "port":502, "id":1, "timeout":1, "function":3, "first_reg":2, "reg_count":"2", "data_type":"32bit_uint1234", "no_brackets":1}'

And would return the device uptime in a following way:

{
        "error": 0,
        "result": "325816"
}

I will send you full usage description in a private message. 

Best regards,

Comments

Hello,

Many thanks for the quick answer. Nevertheless, not sure what I'm doing wrong but it seems that modbus_master is an unknown object on my system:

root@Teltonika-RUTX11:~# ubus -v list modbus_master
Command failed: Not found

A full ubus -v list is also not showing modbus_master as a valid object, what did I miss?

Thanks in advance

---

answering my own comment: it seems that at least one TCP slave should be enabled in Modbus TCP Master section to have modbus_master started and then usable from ubus command. This was not necessary with modbus_tcp_test...

---

All right, after some necessary adaptations (especially registers addresses) everything is working again for me

Many thanks for the quick and efficient support !

For people potentially interested my source code is available here: https://github.com/giacinti/modbus2mqtt

---

I am curious about the  gory details of modbus_master and tcp.test

I notice that there is a plain modbus_master available from the cli
Is that the same functionality as the ubus call modbus_master ?
are all of the "descriptors": mandatory ? or can one supply just the positional parameters in classic *ix style ?

I note that the function is called tcp.test  does that imply a transient temporary functionality ? 

or is it suitable for production code ?

I had previously contrived a means for the telemetry system to push date/time yyyy mm dd hh mm ss to the  PLC to keep the PLCs with rather drifty clocks to remain synchronized.
I was looking for a way to have the teltonika replicate the same functionality and seemed to have run into a dead end
since it seems there was no way to write (function 6) dynamic  data.
I have a good sense that there is sufficient functionality here to perform the required functionality.

Is there any issue with interference/collision between the modbus communications run from the CLI / cron scripts and the

 web-ui configured modbus requestors ?  Maybe the daemon is clever enough to manage that...  ?

Any guidance would be appreciated...  

Oh yeah ... what is the syntax for the data values to be written by function 6 and 16 ?
At this point my ideal scenario would be to write the  someting like:
ubus call modbus_master tcp.test '{"ip":"192.168.1.11", "port":502, "id":1, "timeout":1, "function":6, "first_reg":10007, "reg_count":"1", "data_type":"16bit_uintxxx", "no_brackets":1}'
and better yet:

ubus call modbus_master tcp.test '{"ip":"192.168.1.11", "port":502, "id":1, "timeout":1, "function":16, "first_reg":10007, "reg_count":"6", yyyy,mm,dd,HH,MM,SS,"data_type":"16bit_uintxxx", "no_brackets":1}'

I don't know the 16 bit descriptor nor the "data1" syntax

oh yeah, is the cli modbus stuff 0-based or 1-based ?
seems that is still an active dichotomy - for those for whom the discovery of 0 is a recent phenomenon ;-)

********************************************************************************************************************************************

I figured out some of the data_type codes:

hex ascii   pdu 8bit_int    8bit_uint   

16bit_int_hi_first  16bit_int_low_first 16bit_uint_hi_first 16bit_uint_low_first    

32bit_float1234 32bit_float4321 32bit_float2143 32bit_float3412 

32bit_int1234   32bit_int4321   32bit_int2143   32bit_int3412   

32bit_uint1234  32bit_uint4321  32bit_uint2143  32bit_uint3412  

by inspecting the modbus_master executable looking for recognizeable strings
the 16bit stuff was handled in a klunky way
having established numeric byte order for 32 bit
using that for 16bit was a natural extension (or rather contraction): 

16bit_int12  16bit_int21 16bit_uint12 16bit_uint21
    

---

I can run this and get an OK but it doesn't actually write anything

ubus call modbus_master

tcp.test '{"ip":"192.168.1.11", "port":502, "id":1, "timeout":1, "function":16, "first_reg":10006,

"reg_count":"6", "data_type":"16bit_uint_hi_first", "no_brackets":1}'

OK, I think I figured it out on the drive home...

I was over-thinking it...  I assumed that the cli commands were fully robust implementations

and the UI interface didn't fully implement it.

I see now that the cli functionality and the UI functionality are identical.

modbus_tcp_test and

ubus call modbus_master tcp.test

both implement the same behaviour

when running function 6 or 16 the reg_count parameter is not used as reg_count

it is the data which will be written to first_reg

for Function 6 the reg_count is implicitly 1 and hence reg_count is made superfluous and is used as the data to write

for Function 16 same thing - the multiple register write is simply not implemented...

for what I want to do I need to call tcp.test 6 times:

with successive first_reg and successive date/time fields