-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On Broadcast write mbusd wait's for feedback and provides feedback #61
Comments
Thanks for pointing to this issue. The problem seems to be more complex though. Since Modbus/TCP neither specifies Unit ID 0 as a broadcast address nor defines the broadcast function at all, some of Modbus/TCP slaves (especially old ones) could use zero ID as a valid unicast slave address. But I agree mbusd should handle zero Unit ID more gracefully. I'll look into it. |
@3cky Thanks. Sorry but I thought
I can say it does get very messy when devices e.g. arduino slaves start an action on a broadcast and repeated broadcasts come in. PS: thank for sharing this lib, works like a charm. |
@dgoo2308 I've pushed the fix for RTU broadcast address writing, please test. |
@3cky so sorry for delay, I I'll try to squeeze the test in before my holiday next week otherwise it will be the second week of September. I did notice for the tests that FC5 broadcast, write coil, is not tested. |
looks very good, I did a quick test with int main(int argc, const char * argv[])
{
printf("ModBus version: %s\n",LIBMODBUS_VERSION_STRING);
modbus_t * CTX_Broadcast = modbus_new_tcp_pi("mbus-1.local", "502");
if (CTX_Broadcast == NULL) {
fprintf(stderr, "Unable to allocate libmodbus context\n");
return -1;
}
if (modbus_connect(CTX_Broadcast) == -1) {
fprintf(stderr, "Connection failed: %s\n", modbus_strerror(errno));
modbus_free(CTX_Broadcast);
return -1;
}
modbus_set_slave(CTX_Broadcast, 0);
/* output enable broadcast*/
int r=modbus_write_register(CTX_Broadcast,13,0x1);
if (r==-1)
{
fprintf(stderr, "Fail broadcast %s\n", modbus_strerror(errno));
}
modbus_close(CTX_Broadcast);
modbus_free(CTX_Broadcast);
return 0;
}
results in a nice log without timeouts and no reply. Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select() returns 1
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_open(): accepting connection from 192.168.1.75
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 queue_new_elem(): length now is 1
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn[192.168.1.75]: state now is CONN_HEADER
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select(): max_sd = 5, t_out = 000060:000000
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select() returns 1
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn[192.168.1.75]: state now is CONN_RQST_FUNC
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select(): max_sd = 5, t_out = 000060:000000
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select() returns 1
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn[192.168.1.75]: read request fc 6
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn[192.168.1.75]: state now is CONN_RQST_TAIL
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn[192.168.1.75]: request: [00][06][00][0d][00][01]
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn[192.168.1.75]: state now is CONN_TTY
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 tty: state now is TTY_RQST
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select() returns 1
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 tty: written 8 bytes
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 tty: request written (total 8 bytes)
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn[192.168.1.75]: state now is CONN_HEADER
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 tty: state now is TTY_PAUSE
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn[192.168.1.75]: broadcast request sent
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select(): max_sd = 5, t_out = 000000:100000
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select() returns 0
Aug 30 16:10:06 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 tty: state now is TTY_READY
Aug 30 16:10:07 mbus-1 mbusd[912]: 30 Aug 2020 16:10:06 conn_loop(): select(): max_sd = 5, t_out = 000059:000000
Aug 30 16:10:07 mbus-1 mbusd[912]: 30 Aug 2020 16:10:07 conn_loop(): select() returns 1
Aug 30 16:10:07 mbus-1 mbusd[912]: 30 Aug 2020 16:10:07 conn_close(): closing connection from 192.168.1.75
Aug 30 16:10:07 mbus-1 mbusd[912]: 30 Aug 2020 16:10:07 queue_delete_elem(): length now is 0
Aug 30 16:10:07 mbus-1 mbusd[912]: 30 Aug 2020 16:10:07 conn_loop(): select(): max_sd = 4, t_out = 000060:000000 |
A write to unitId 0 is considered a broadcast and no devices should acknowledge although
mbusd
wait's for a response from servers, which it should not do as the servers are not allowed to acknowledge this.This leads also to resends due to the time-outs and blocks the bus during that time () of waiting 3 times for 8 bytes.
Log unpatched:
solution tested for FC05 broadcast
Log with patched version:
Result no more timeouts and a working solution.
The text was updated successfully, but these errors were encountered: