FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
231 views 3 comments
by anonymous

I just noticed there is a new Firmware out RUT9_R_00.07.03.2 

I decided to update the firmware...
II see that the modbus serial stuff has been completely reorganized into a far more logical and intuitive configuration

but I also see that it is just as disfunctional as before and actually shows the identical comm  logs in modbus slave

I am using ModbusPoll as the reference implementation of competent serial modbus RTU comms

to simplify the scenario I have created a stripped down ModbusPoll environment consisting of only two variables

this is what the comm stream looks like:

Tx:000473-0B 03 1B 60 00 02 C2 5B 

Rx:000474-0B 03 04 42 A0 88 FA A2 2A 

Tx:000475-0B 03 1B 5E 00 02 A3 97 

Rx:000476-0B 03 04 00 00 00 00 50 33 

Tx:000477-0B 03 1B 60 00 02 C2 5B 

Rx:000478-0B 03 04 42 A0 88 FA A2 2A 

Tx:000479-0B 03 1B 5E 00 02 A3 97 

Rx:000480-0B 03 04 00 00 00 00 50 33 

When I connect ModbusSlave and monitor what the RUT955 emits:
Tx:007470-0B 03 01 C1 32 
Rx:007471-0B 83 03 21 33 
Tx:007472-0B 03 01 C1 32 
Rx:007473-0B 83 03 21 33 
Tx:007474-0B 03 01 C1 32 
Rx:007475-0B 83 03 21 33 
Tx:007476-0B 03 01 C1 32 
Rx:007477-0B 83 03 21 33 

If we analyze the MPB request : Tx:000473-0B 03 1B 60 00 02 C2 5B

0B is the ID (11) 

03 is the Read Holding Register modbus transfer type

1B 60 is the address (7008)

I'm not positive what the 0 is 
02 is the number of registers to transfer
C2 5B is the CRC

The request from the RUT 955 is a lame incomplete facsimile
Tx:007476-0B 03 01 C1 32 

OB is the ID   OK
03 is read holding Register   OK

01 is what ?  the First Register Numer and Register Count parameters appear to be ignored and discarded

C1 32 is the CRC OK

I notice that the error code is now processed and displayed, Thank you!
Request failed, result: Failed to get response: Illegal data address

Yeah, no sit sherlock, the data address is not merely illegal, it is totally missing 

by anonymous
weird!
I thought this post was lost...
When I attempted to submit it there was no confirmation - just a spinning wheel

When I attempted to refresh it it just said "Too many posts try again later (or never)"

When I examined the thread, there was no post - so I re-posted the item a few hours later when I got home

I have started making a practice of copy-pasting my message into an email message

for safe-keeping in case it get lost in the posting process...

Several times I get bit by some goofy "12000 character limit" message and it refuses to post

I suspect it has to do with posting screen-shots directly into the message

my guess is that saving screenshots as files and then attaching those images as files is treated differently

from directly posting  the image - when every pixel counts as a byte or two or three whereas files probably only count as the length of the filename and the image contents are retrieved/displayed "for free"

1 Answer

0 votes
by anonymous

Hello,

When configuring MODBSU requests in Teltonika devices, instead of using register addresses, refer to register numbers, for example, if your register address is 7008, define first register number as 7009. For example:

Using 7008 does indeed return error:

Best regards,

by anonymous
Nope.
The register vs number issue is different.

I have clearly shown that the RUT 955 does not send the required address and register count in its request message.
The RUT has no prior knowledge about the location or organization of the structures, registers, addresses, numbers in the device.

I am quite familiar with that dance in modbus devices.  There is a general sloppiness about whether one thinks in terms of 0-based references or 1-based references (C vs BASIC etc) in modbus.
I begin by working that out in ModbusPoll where the exploration environment is flexible and one obtains immediate feedback

I have shown that when modbuspoll requests the data, it correctly includes the register address/number in the request message

and the device responds accordingly.

In the case of the RUT (maybe still being in the rut long after fall ;-) it fails to include the address/number in the request

Re-Read my comment again

If the address is "off" by one, the device will still return the data, except when the receiving system reconstructs

the received 16-bit data chunks into 32bit INTs or FLOATs, the result will be non-sensical

the 16-bit chunks will simply point to an adjacent register
 

In the previous Firmware, I observed exactly the same bug/deviant behaviour.

It seemed possible that since the requests (for the _serial_ RTU devices) were composed in TCP form, that perhaps the address was being lost in the gatewaying / translating from TCP to RTU

In this case, the expression is very clearly TCP-free all-serial with no explicit/implicit gatewaying and yet

the register address/number and quantity is being discarded and not included in the RTU request which hits the 485 wires.
Please refer/escalate this matter.
by anonymous
we were finally able to get the serial modbus transfers working today - by sheer obstinacy
we did offset the address by one in a non-intuitive direction and then it started working

my point remains that the 955 sends out malformed request packets for either the even or odd registers
I have already shown that the address information is simply missing from the request packet

If it was felt necessary to enforce some non-standard behaviour, it would be more appropriate to enforce it

at the entry/parsing phase rather than secretly send malformed packets

on the current firmware, it is clear that some of the response codes are being processed and displayed when using the TEST function

the error for 7008 or whatever is not an inherent error in the 955, it is the error packet returned by the device when it receives a malformed packet with a non-sensical address