modbus_set_slave() disallows Slave IDs above 247 #38
Comments
|
I think I'll increase standard conformance (for modbus_reply for example) and offer a new setting to disable it! |
ghost
assigned 
|
Dear Stephane, is there now a way to address a slave address greater than 247 without patching the library? Thank you for the feedback |
|
Nope, not yet. |
|
I prefer to call this 'quirks' instead of compliance, see my proposal here: https://github.com/mhei/libmodbus/commits/quirks |
|
Quirks or compliance. Opinion asked on mailing list. |
|
I intend to relax the rules by default and to offer a strict mode. |
|
Running into this again, how are we going on getting this into a released version? |
|
Some devices use 248 address for point to point communication. I was using Qmodbus testing, and getting crazy. Thanks that it has a Modbus monitor I discovered this issue. Please enable a mechanism to override this. |
|
This is an opensource project. If you want to customize the source code to do something unique, go ahead. That is one of the advantages of opensource.
From the manual you linked:
The address 0xF8 (248) is used as the general address, this address can be only used in ****** single-slave environment and can be used for calibration ******* etc.
The 248 special address is a unique function of this specific device in a very specific use case outside the documented MODBUS address range from 1-247.
You are on your own.
From: plbarrio ***@***.***>
Sent: Sunday, July 11, 2021 6:06 AM
To: stephane/libmodbus ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [stephane/libmodbus] modbus_set_slave() disallows Slave IDs above 247 (#38)
Some devices use 248 address for point to point communication.
https://innovatorsguru.com/wp-content/uploads/2019/06/PZEM-004T-V3.0-Datasheet-User-Manual.pdf
I was using Qmodbus <https://github.com/ed-chemnitz/qmodbus/> testing, and getting crazy. Thanks that it has a Modbus monitor I discovered this issue.
Please enable a mechanism to override this.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#38 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFDSAIDIMLMFQWLRQCWLDTTXFUI3ANCNFSM4ASZZMJQ> . <https://github.com/notifications/beacon/AAFDSAKWBIHW7ZJZAG4PLFDTXFUI3A5CNFSM4ASZZMJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGRI4EOY.gif>
|
|
Yes, I know that is an opensource project and that I could fork my self, I have even located the line code. I also know that 248 address is not standard. The problem with that device is that is the default address and some users can have problems with it. This library is 'de facto' modbus standard. I was using Qmodbus for testing the device, but my final idea was to use with Influx and Telegraf. But i am not confident that telegraf is not using this library and what i see in its source code there is a note as 248-255 address are 'reserved'. Yes i have to test, but i think we should save all this testing to users even for non standard address. https://github.com/influxdata/telegraf/tree/master/plugins/inputs/modbus I see that the package is sended, but the slave response causes an exception '[inputs.modbus] Error in plugin: modbus: exception '2' (illegal data address), function '131' I was just asking for a 'non-standard' flag, which other users above in this thread have suggested to be merged. I think that it is a pity that i have to start a virtual windows machine and use non open source software to change this device address due this issue. I know that i could program it myself but i have still nightmares debugging 'easy modbus' from Omron PLCs. |
|
I think it's time to resolve this issue! @mhei started a branch to set the various quirks (https://github.com/mhei/libmodbus/commits/quirks). I need your feedback to know if we should use a smart mask or stupid global flag. Does the term 'quirk' is clear for everyone? |
|
Even 6 years after my PR, I still like the idea of naming it "quirk" - stolen from Linux kernel where similar things exists for e.g. USB devices 😇
From library user view, or do you means inside the library itself? The later might be addressed with more convenience macros...
Yes, my original PR was just an initial shot, room for improvement is always there. I think that for each "quirk" it should exactly be documented how this affects the library and which are the consequences from user point of view. |
|
Quirk is good for me :) there's a few things that could be covered... |
|
Quirk is fine for me too, I don't really care. However,
I'd prefer the default setting to be full compliance to the standard. Any additional quirks or nice features should be opt in by the user IMO. |
|
See updated |
Useful functions when you are confronted with equipment which does not respect the protocol, which behaves strangely or when you wish to move away from the standard. Thank you @mhei for the great initial version.
modbus_set_slave() disallows Slave IDs above 247. A particular modbus device that I am using defaults to a slave ID above 247 (specifically, 254) and does broadcast on IDs 255 and 0. This means that I cannot interact with this device directly.
There are workarounds involving taking the device onto it's own bus not shared with other devices and then using the broadcast address to set the device ID to a normal value. However, this is not ideal for my situation.
in modbus-tcp.c and modbus-rtu.c exists the following line:
I recompiled the library with these lines changed to:
and this fixed my issue.
I believe this restriction is in place in order to adhere to modbus standards, however, with the large number of non-compliant devices out there, I believe libmodbus should give this power to the developer. Another possibility is printing a warning message if this is performed while the library is in debug mode when using addresses from that range.
The text was updated successfully, but these errors were encountered: