E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion
Register FAQ Community Calendar Today's Posts Search

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

 
 
Thread Tools Search this Thread Display Modes
Prev Previous Post   Next Post Next
Old November 26th, 2015   #11
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 390
Default

Quote:
Originally Posted by dj41354 View Post
Yeah, I was ignoring it... The fact that I need to respond to every unicast GET or SET was not understood. Thank you for that nugget... I'm getting there (slowly).
Good, glad you found the problem. It sounds like you're making good progress in the implementation.

When to respond or not respond is a bit more complicated then you might expect. Here's an overview:

Discovery Command Class - Discover Unique Branch:
Respond iff all of the following requirements are met:
  • You are unmuted
  • The packet is properly formed (valid checksum, correct PDL length, etc.)
  • You are within the requested discovery range given in the upper and lower bounds
  • The packet destination address is to you (this means Broadcast, a Vendorcast to your MFGID, or a unicast to your UID)

Otherwise, don't respond.


Discovery Command Class - Mute/Unmute:
Respond with an ACK iff the request is a valid request and unicast to you.

Do not respond if the request is a Broadcast or Vendorcast
Do not respond if the request is corrupt or malformed.

Note 1: Due to a quirk in how the standard is written, you are not allowed to NACK a discovery command class request. This means if you get a corrupt or invalid discovery request the only thing you can do is ignore the request and not respond. However, many responders will NACK an invalid discovery command class request. While this is technically not allowed, it's a common behavior and will not cause problems most real-world systems.


Discovery Command Class - Unknown PID:
Do not respond (see Note 1 above)


Get/Set Command Class:
Respond with ACK, ACK_TIMER, ACK_OVERFLOW, or NACK as appropriate iff the request is unicast to your UID.

Do not respond if the request is a Broadcast or Vendorcast


Unknown Command Class:
The standard is not clear what you should do in this case.

One interpretation is that you should ignore the request and not respond. Another interpretation is that you should NACK with an appropriate Reason Code.


The DMXter's "Specific Tests" menu can help you work through the various corner cases. I believe the automated test suites also cover many of these conditions.

If you run into more questions, feel free to post them here. Supporting RDM developers is the reason this forums exists. Everyone benefits when new implementations are done well...

Last edited by ericthegeek; November 26th, 2015 at 10:19 PM. Reason: Spelling
ericthegeek is offline   Reply With Quote
 

Bookmarks


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
New PID "Slot Labels" este_ RDM General Implementation Discussion 5 August 14th, 2014 09:26 AM
New PID "CURVE DEFINITION" este_ RDM General Implementation Discussion 0 July 13th, 2014 03:16 PM
Refreshing "parameter_description" ? theguenni RDM General Implementation Discussion 7 March 3rd, 2012 08:06 PM
Refreshing "parameter_description" ? theguenni RDM General Implementation Discussion 0 February 29th, 2012 02:36 PM


All times are GMT -6. The time now is 03:56 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2026, vBulletin Solutions, Inc.