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
218 views 4 comments
by anonymous
This is not technically a bug, but rather a design non-optimality

Whatever platform one is using which has "standard" or  "non-standard" byte orders,

it would make sense to group all of the data-types by byte-order rather than interspersing and intermixing

them all in a mish-mash from which one must sherlock-holmes out the ones one needs - over and over...

simple useability suggestion

1 Answer

0 votes
by anonymous
Hello,

Please provide a more detailed description about your use case.

I would take the suggestion to the developers.

Best regards,
by anonymous

Notice how in the dropdown when creating a requestor, all of the data types are grouped by type

with the sub-groups being byte-order ... i.e. 1,2,3,4;  4,3,2,1;  2,1,4,3;  3,4,1,2
My point is that it would be easier to pick from a half-dozen adjacent items of the same byte-order:

i.e Float 1,2,3,4; INT 1,2,3,4; UINT 1,2,3,4...

rather than having all of the types and all of the byte orders thrown to the wind requiring precise picking from among the dross

If one wanted to optimize further, I would:

 make Holding Register (3) the default rather than coils

have the type selection automatically select the number of registers - typically 2

turn off brackets as the default - I can't imagine any possible utility for [ 123 ] - a non-standard extension rather than "normal" useage

those are the basic stylistic changes which would streamline the entering of requestors.

To add more functionality I would allow the requestor-list to be exported and imported...  a subset of a whole system backup/restore

I would abandon the weird enforcing of even modbus register addresses/numbers on serial RS485
I encountered a situation where entering an odd number for the register caused 955 to emit broken request messages which were missing the address and word count words altogether.  Some devices have "odd" register addressing schemes and it is not the role of the 955 to enforce some artificial addressing scheme...  From my investigations with modbuspoll/slave I know that the modbus standard itself is flexible and does not impose such restrictions.
Further, IF there is sufficient stridency to enforce such an artificial restriction, that should be enforced at the entry/parsing level and not at the level where wrong/broken/malformed packets are emitted

by anonymous

I notice that the image was distorted to the point of unreadability in my last comment

hence this zoomed in view

by anonymous
Hello,

Thank you for this extensive post.

I have noted your observations and forwarded to the development team to consider implementing in the future.

Best regards,
by anonymous
as a followon for further modbus comms enhancement I submit this

I am trying to figure out a way to determine the best way that communication status with a modbus device,
either via TCP or Serial  RS485/232 can be read or inferred.
Currently, it appears there are NO modbus status registers available.
Ideally, _each_ modbus requestor should have an individual status register associated with it which can be queried

Alternatively/Additionally a status register for each modbus slave device should be available to be queried.
It appears that when using the Test Button in the WebUI, that the status is read and displayed, but not made available for
IoT status
As it is when comms die, the last read data values remain forever.
I was thinking one could come up with some shell-script kludgeware to do some error checking, but I know of no hooks in shell-script land...  
I'm thinking those data points could be klobbered to zero periodically in thingsboard, but that's super-ugly and puts a lot of needless noise into the data.

Any ideas ?

I suggest setting aside 2 chunks of modbus registers
1 chunk of 32 registers into which overall status for all defined slave devices would be written
0xffff denotes device not configured
0x0000 denotes status OK
0xttss denotes tt=seconds since non-zero status, ss=last modbus status code

for keener-points 1 more chunk of 128 registers into which status for individual requestors would be written

- same scheme as above