As you've found, a properly behaved splitter will often expose problems caused by misbehaving responders. But to the end-user it looks like the splitter is broken because "it works fine when the splitter's not installed".
This is what makes building a splitter such a challenge: Misbehaving devices, noisy 485 lines, and line driver enable/disable transients can leave you in a corner where there's no "correct" behavior.
In my intelligent splitter, I monitor for misbehaving devices and disable RDM on the port if something is talking when it shouldn't. At the end of a unicast request or response, there should be *no* activity on the line for 176us. If I see anything happening on a downstream port during that period I disable responses from that port for a few seconds and report a "jabber" event to the controller. That way the user sees "Jabbering responder found on port 4", rather than unexplained flakyness.
|