Issue in Modbus Multidrop communication over RS485 2 wire bus

We have Modbus Master communicating to 10 Modbus slaves over RS485 2 wire bus. (All the slaves connected to bus in multi-drop)

If the setup is using ASCII standard, the communication is stable and working fine.

When we use Binary standard, It is not working properly. When I analyzed the issue, I came to know that the received packets are getting corrupted in the slave.

When any slave is sending response to the corresponding master request, that response is in turn going to all other 9 slaves as a new request again.
This is happening since they are connected in multi drop 2 wire mode. In that case the other slaves are not able to reject it before a new real request
comes from master.

In ASCII mode it is working because there is a proper start:)) and stop(\r) characters to identify the packet even if there is a overflow of requests.
where as in Binary mode the start and stop are identified by the time delay. If the requests are overflown then slave is not able to recognize the start and stop of the message.

Is Multi-drop configuration is allowed for the 2 wire RS485 ?

If yes suggest me how to handle the above issue?
2 wire RS485 multidrop configurations are very common regardless of protocol.

If my memory is correct, Modbus message headers contain sufficient information to allow any
slave device:
- to ignore any data from the master device if not being addressed
- to ignore any data from any other slave device on that 2 wire configuration

If you are, as stated getting corrupt data you would need to isolate each slave, in turn
to identify which is at fault.
If the slaves are indeed operating the way you've described, this is a serious design flaw in the slave and should be fixed by the vendor.

Have you confirmed that each slave can successfully communicate with the master when no other slave is connected?

One workaround you may be able to do is to configure a "poll delay" on your master so that it waits some time after receiving a response before it sends the next request.
If you can configure a delay at both the Modbus Master and Modbus Slave ends this may address the issue. There may be a stting in the communication driver configuration. Alternately many devices have transmit delays as part of their configurable communication port parameters usually used in conjunction with RTS/CTS hardware handshaking to accommodate modems which need time to stabilize a carrier before receiving data from the attached device.