Dear Eric Malund,

The hardware we are using had been running successfully for years (now, the model is not in the market) with no field failures and hardware issues.
The tristate logic at slaves end is already implemented in this hardware.

We have no idea about the earlier running software and its logic.

Now, we implemented a fresh software for the same hardware, and facing some minor issues which I had already posted.

So, from our side, no issues related to hardware, and changes in hardware are , to say, not possible for now.

The main problem we are facing is:

The master addresses all present slaves in a sequence. The addressed slave sends acknowledge byte to tell the master to wait for data bytes followed by end of data byte.

So, the master waits for the data bytes reception (if any) + the 'end of data' byte.

In this operation, at some point of time, the following failures are happening:

a) an arbitrary slave is failing to get addressed, I mean to say, failing to send acknowledge.
Then, the master starts counting the fails for 5 times, and then confirms that the slave has lost the communication flow, and treats this case as an error (type 1).

Q1. How to fix this error case, and how to revoke the failed slave to get back into the track?

b) a slave, after getting addressed, is failing to send the end of data byte.
Now, the master notes error (type 2) and sends communication reset command to all slaves, in a way to refresh the communication at slaves end.

This error rate decreased by 50% when we added your trick of sending 'no data byte' before the end of data byte from slave to master.

So, help us with any more changes in the software for the both cases.