How to work with multiple servers

[focussing]

I have 3 identical boards in my system which I want to control using a C# application.
The boards have 2 dip switches to set the slave address to 1 2 or 3 (0 is broadcast).
During initialization the server is inialized with the address:

    uint8_t    serverAddress = GpioGetBoardAddress();
    nmbs_error err           = nmbs_server_create(&nmbs, serverAddress, &platform_conf, &callbacks);

Tested all boards separately with dip switches set to 1 or 2 or 3. Communication works top on every slave address.

When I test with all 3 boards connected on the bus with all having their own address (board1 has addr1 etc) communication is unstable.
I (manually, so very slow) send read_holding_registers to all slave-addresses, and only one of the slaves replies with the correct answer, the others do not response, these 2 are hanging.

This is an urgent problem...
Please respond.

Best regards!

[focussing]

I just had the following effect; I have addresses 2 and 3 present. When I send a message to address 1 (which is currently not present on the bus), the reply from address 3 is received, and address 3 does not reply at all and hangs!

[alpytron]

Hi,
I think I'm seeing issue with the same root cause, though my symptom is different: CRC errors at the master rather than a hung slave.

Setup: two RTU servers on one bus, addresses 1 and 2, single master. Each works fine in isolation. With both connected, the master intermittently reports CRC errors on responses.

Tracing it: recv_req_header() only sets msg.ignored when the unit id isn't ours - it then keeps going. The function-code handlers run recv_msg_footer() (the CRC check) before the if (!ignored) guard, so a server fully parses and CRC-checks every frame on the bus, including the other server's responses. A response has a different byte layout than a request, so the non-addressed server miscounts the payload, reads the wrong two bytes as the CRC, and fails the check. Worse, the NMBS_ERROR_TIMEOUT path in nmbs_server_poll() doesn't flush, so the tail of that frame is left in the buffer and gets misparsed on the next poll — which can spuriously match the local address and make the server transmit, colliding with real bus traffic (the CRC errors the master sees).

So I think #115 and this are the same underlying bug — address filtering happens after parse/CRC instead of before. What fixed it for me was bailing out as soon as the address doesn't match: after reading the unit id, if it's not ours (and not broadcast), discard the rest of the frame up to the inter-frame gap and skip the handler entirely, so a foreign frame is never parsed, CRC-checked, or replied to.

Now I patched my copy and I would be happy to share that.