View Single Post
Old May 9th, 2017   #12
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

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.
ericthegeek is offline   Reply With Quote