View Single Post
Old March 18th, 2011   #11
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 369
Default

Quote:
Originally Posted by head_up View Post
Thanks, ericthegeek, u rescue me from long hours cursing!
Happy to help. There are quite a few knowledgeable people who read this forum. We all want RDM to succeed.

Quote:
Originally Posted by head_up View Post
the controller is sending to me requests which are with PD 0x02 (E120_STATUS_ADVISORY !? why this ?! ) at ~1 sec. I'm not sure, but i think this is like "Are u here?". Is this correct?
Many controllers periodically poll every RDM responder to make sure it is still connected. A controller can use a variety of PIDs to do that polling. Some use MUTE, some use GET QUEUED_MESSAGES, some use GET STATUS_MESSAGES. All it's doing is making sure that the responder is still connected. If doesn't matter if the responder NACKs, or ACKs; Any response tells the controller that the responder is still connected.

Quote:
Originally Posted by head_up View Post
For now i'm answering with NACK - but the controller continue to send me this requests... is this problem or i must respond with STATUS_MESSAGES with a PDL of 0x00?
If you don't support queued messages at all, then your behavior is correct. You can NACK the request.

That changes once you add support for Queued Messages. If you receive a GET QUEUED_MESSAGES PID from the controller, and you don't have any messages to deliver, then you have to respond with a STATUS_MESSAGES response (E1.20-2006 section 10.3.1).


Quote:
Originally Posted by head_up View Post
I thing support of queued messages is absolutely mandatory for proxy device, but for now i can't add it (for some other reason).
An RDM responder (including a proxy) must be able to respond to any valid RDM request within 2ms (Table 3-4 line 2). If the devices you are proxying for can always provide the info you need in that time, then you don't have to support queued messages. But, if getting the info you need from the far side of the proxy can take longer than 2ms, you must ACK_TIMER to request and queue up the proper response as soon as the information becomes available.

If you are doing an RDM to RDM proxy, then you must support queued messages. The responder on the far side of the proxy can take the full 2ms to respond, which leaves you no time to pass it along to the controller.

If your list of proxied devices can change, then you must support queued messages. You have to queue a PROXIED_DEVICE_COUNT PID message any time your list of supported parameters changes if you are acting as a managed proxy.

Quote:
Originally Posted by head_up View Post
When i must respond the list of devices and the list is too long for single message - can i use for now E120_RESPONSE_TYPE_ACK_OVERFLOW ? i think this is very close to E120_QUEUED_MESSAGE support about this data stream.
Yes, if your list of PROXIED_DEVICES is too large for a single packet, then you must use ACK_OVERFLOW.
ericthegeek is offline   Reply With Quote