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

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

Reply
 
Thread Tools Search this Thread Display Modes
Old September 5th, 2010   #1
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default Correctly handling ACK_OVERFLOW

What's the correct behavior for this? The standard says "the controller should continue to send get commands for the same PID" but mentions nothing about what the PD field should contain.

Does that mean the PD and PDL fields should remain identical to the first message or can I send no data for the subsequent get commands?

For the two examples in the spec (proxied devices and supported parameters) it doesn't matter because the PDL is always 0 but I can imagine a case where the PD contained data specific to the GET request.

Thanks,

Simon
nomis52 is offline   Reply With Quote
Old September 5th, 2010   #2
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

Simon

It is a very good question - and as the standard does not explicity state anything, a responder would be best advised to cope with either case.

It seems preferable that if the initial GET had a payload (and thus the PDL != 0), this should be repeated in all subsequent GETs until the responder stops replying with the ACK_OVERFLOW.

This needs to be documented in the next erratta.

Peter
prwatE120 is offline   Reply With Quote
Old September 5th, 2010   #3
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Quote:
Originally Posted by prwatE120 View Post
Simon

It seems preferable that if the initial GET had a payload (and thus the PDL != 0), this should be repeated in all subsequent GETs until the responder stops replying with the ACK_OVERFLOW.

This needs to be documented in the next erratta.

Peter
Thanks, that's what I expected. Is there a bug list for open issues where these things are tracked or do people just remember to bring them up at the next meeting?
nomis52 is offline   Reply With Quote
Old September 5th, 2010   #4
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Here's a related problem: The standard states "The responder shall abort a partial transfer of overflow data for a PID when receiving a command
for a different PID before the overflow data transfer is complete."

It says nothing however about what happens if the src UID differs. In multi-controller setups like E1.33 we're going to need to be careful to ensure one of the following:

i) other get/set messages can't be interleaved when an ACK_OVERFLOW sequence is occurring on the DMX side
ii) if interleaving is allowed, the responders need to track the transfer status per src UID and only reset if a different PID is received from the same src UID.

I'll have a guess that no one has designed their responders to handle case ii) so I think we'll have to go with i). This means that gateways are going to have to buffer the entire message.
nomis52 is offline   Reply With Quote
Old September 5th, 2010   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

I think Peter's right. A responder should be able to handle both.

This could make things difficult for the controller. If the controller issues two issue back-to-back PIDs with different Parameter Data, it may be ambiguous what the response contains.

Looking at the PID list in E1.20, there are 6 PIDs that are likely to grow enough that they require an ACK_OVERFLOW
  • PROXIED_DEVICES
  • STATUS_MESSAGES
  • SUPPORTED_PARAMETERS
  • LANGUAGE_CAPABILITIES
  • SLOT_INFO
  • DEFAULT_SLOT_VALUE

The biggest potential culprit here is STATUS_MESSAGES (The others all have a PDL of zero). If the controller changes the "Status Type" field part-way through an ACK_OVERFLOW sequence, there's no telling what it will get. Fortunately in case of STATUS_MESSAGES, the response contains the "Status Type" for each of the status reports which should eliminate the ambiguity.

This is probably more of an issue for MFG specific PIDs.

> Is there a bug list for open issues where these
> things are tracked or do people just remember
> to bring them up at the next meeting?

In the past, we've gone through old forum threads before re-opening the document for editing. I think Scott also keeps an errata list.

> It says nothing however about what happens
> if the src UID differs. In multi-controller setups
> like E1.33 we're going to need to be careful to
> ensure one of the following:

This a big part of the reason I don't like E1.33 being multi-controller: It makes ACK_OVERFLOW handling much more complicated. But, multi-controller is highly desirable from an end-use standpoint, so I think the E1.33 gateway will have to initiate the entire overflow sequence on the DMX side, and buffer it for the IP side.

The only other option I can see would be for the E1.33 controllers to all collaborate to make sure ACK_OVERFLOWs are never interleaved, perhaps with a token-ring style "permission to talk" message. For a variety of reasons, I don't think this is practical.

During E1.20 development, there was a lot of discussion of how a responder should handle a change in the controller's UID. We could never reach a consensus. Some felt it should be ignored. Others wanted the responder to un-mute and reset several other protocol elements. In the end it was left un-defined.
ericthegeek is offline   Reply With Quote
Old September 5th, 2010   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

I agree with Peter and Eric's comments on the issues you raised.

On the errata side, as Eric mentioned I go back through and scrub all the discussions for errata issues whenever we re-open the doc. I also have a doc that I list them in as they come up in our meetings too.

Originally with the MUTE flag we had the devices clear the flag when they saw a change in Source ID. That proved to create an enormous mess, so the devices should generally be completely agnostic to the Source ID. The issue you raised about them getting interleaved in E1.33 is a valid one and something we will need to address in it.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 6th, 2010   #7
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Thinking about this a bit more, it's not clear if STATUS_MESSAGES should ever use ACK_OVERFLOW in the first place. Multiple status responses are packed into a single packet. But, STATUS_MESSAGES has its own queuing mechanism, so if you have more status conditions to report than will fit into a single response, you can use that queuing mechanism to get the additional statuses.

Again, a controller should probably handle both, but I'd argue a responder shouldn't generate ACK_OVERFLOWs for STATUS_MESSAGES responses.
ericthegeek is offline   Reply With Quote
Old September 6th, 2010   #8
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Eric and I did a bit of testing with an ArtNet node yesterday. I've documented the behavior at http://opendmx.net/index.php/ArtNet,...t_Interleaving
nomis52 is offline   Reply With Quote
Old September 6th, 2010   #9
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Quote:
Originally Posted by ericthegeek View Post
Again, a controller should probably handle both, but I'd argue a responder shouldn't generate ACK_OVERFLOWs for STATUS_MESSAGES responses.
Agreed, when's the next revision due out ?
nomis52 is offline   Reply With Quote
Old September 6th, 2010   #10
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by nomis52 View Post
Agreed, when's the next revision due out ?
I'm still working on getting the last rev released!
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 28th, 2011   #11
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default The time has come.

It has now become apparent that I will have to implement ACK_TIMER for FW upload over RDM, ug.

This post is just to report a minor documentation detail 6.3.3 Page -28- ACK_TIMER response (PD) = 0x00000258.
This is a 16 bit field...
hamish is offline   Reply With Quote
Old January 28th, 2011   #12
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Hamish,

That error in the example has already been fixed in the soon-to-be-published-almost-any-day-now errata.

Also bulk data transfers can be accomplished without using ACK_OVERFLOW. I know that came up in discussion over the weekend. It can also be done without ACK_TIMER unless you're having timing issues where you need to be able to go away for a while.

I can send you a draft version of the Bulk Data Transfer document that we abandoned. It might at least give you some useful concepts/model to use.

Scott
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 29th, 2011   #13
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default

Scott

Just to confirm, this is a 16 bit timer value?
I think I may have posted in the wrong thread here, it was ACK_TIMER that I had in mind.
On the upload front, it is going to be done in pages, so no requirement for the ACK_OVERFLOW.
As I see it at the moment, I will not be able to avoid the ACK_TIMER during the re-configure process.

As this is going off topic for this thread, I'll start a new one when I make some headway. Meanwhile, anything you have to throw into the melting pot would always be appreciated.

Last edited by hamish; January 29th, 2011 at 06:11 AM. Reason: Wrong thread
hamish is offline   Reply With Quote
Old January 29th, 2011   #14
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Yes. Ack timer gets a 16bit value in tenths of a second.
ericthegeek is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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
ACK_TIMER Handling ericthegeek RDM General Implementation Discussion 8 January 20th, 2011 08:15 PM
Command Class / Parameter ID mismatch handling dangeross RDM Interpretation Questions 2 April 16th, 2009 01:39 PM


All times are GMT -6. The time now is 05:42 AM.


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