View Single Post
Old August 27th, 2020   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

I've posted in the past about Splitters and Inline devices. Search for forums for my previous posts and you should be able to find them.

Having built a fully protocol-aware transparent inline device, my advice is: Don't try to build a fully protocol-aware transparent inline device. The error handling will drive you nuts!

Quote:
Originally Posted by Andrew_Parlane View Post
1) 4.2.1.1 Port Turnaround during Discovery. What counts as a discovery request here? Is it anything with the DISCOVERY command class? Or is it only DISC_UNIQUE_BRANCH?
This only applies to the Discover Unique Branch Command.

Quote:
Originally Posted by Andrew_Parlane View Post
2) When should an in-line device return to forwards data flow during non discovery transactions, when errors are detected with the responder's response?
Error handling is the hardest part of building a protocol-aware inline device. The standard is silent on the matter, and much of the time there is no good solution when you detect an error.

The "partial response" problem you mention here is one problem. The other is what to do when there's a checksum error in a request or response. It may look like a checksum error to you, but if the error is due to noise or analog effects on the 485 line it could still look perfectly fine to other devices.

The only advice I can give is: When in doubt, cut off the downstream branch(es) of your inline device, switch back the upstream port that has the controller attached to it, and wait for the controller to come to its senses. This may cause additional corruption to that specific request/response, but should leave your system ready for the next valid request.

Quote:
Originally Posted by Andrew_Parlane View Post
What should the controller consider the start of a reply? A falling edge on the line, regardless of whether it's for a valid break or not?
You can't just look for a falling edge. You'll need a glitch filter to deal with noise and 485 line driver enable/disable transients.

The shortest valid low you should ever see on the 485 line is 4us. It's common to see glitches that are a few hundred nanoseconds long. Most 16x oversampling UARTs won't see them, but a timer or interrupt based edge detector will trigger on them.

If you see any events lows that are <1us you should filter them out and ignore them.

Quote:
Originally Posted by Andrew_Parlane View Post
In the case where a command port receives the start of a response should we disable reception from all other command ports? A well behaving system should not have two responders respond in this case since it's not a discovery message, but there could be badly behaving responders on a system causing this collision. Should the in-line device block that or allow it to reach the controller?
There's no right answer to this question. If you have a good glitch filter, you can usually disable the other ports. However, there are some poorly behaved responders that will put a 1 to 2us glitch on the line even even when they are not responding. If you treat this as the start of a response, then you risk cutting off the port that has the real responder.

But, if you leave the other ports enabled and AND all of them together you risk allowing a glitch through from another branch that will corrupt an otherwise valid response.

Quote:
Originally Posted by Andrew_Parlane View Post
4) If the responder were to send a break and then never send it's first data slot. The controller should timeout the MAB after 88us according to table 3-1. When can it start it's next frame? Table 3-2 line 4 would suggest 176 us after the last rising edge of the responder (end of break), since it's already timed out the MAB after 88us, that would mean the controller could start to transmit in 176us - 88us?
If you strictly follow the standard, then the MAB should never be more than 88us. But, the standard allows responders to have a 2ms pause between data bytes in a response. This 2ms was included to allow a high priority interrupt to do something like update a motion servo. However, some responders have a 1 to 2 ms interrupt that can trigger at any time during the response, including during a Break+MAB. Thus, it's best not to be too strict about enforcing the response's Break+MAB.


And of course: Test, test, test. There are all kinds of corner cases. When I designed mine I build an "RDM Devil" that did nothing more than inject 1 to 4us pulses at very specific times to test my error handling. Injecting them during the 176us time period between packets was especially effective. This is the time period when the 485 line is undriven, and should be held high by the pull-apart resistors, but it often sees noise.
ericthegeek is offline   Reply With Quote