Clearify ACK_TIMER than QUEUED_MESSAGE

[ericthegeek]

Originally Posted by sandor

1. As soon as I get a SET message for parameter modification but I need more time than 2mS to finish that SET command I HAVE TO reply to the controller with ACK_TIMER reply, am I correct?

In my opinion, if you've validated the request and have started making the change it's OK to ACK it rather than ACK_TIMER.

If the set is is going to take a long time (multiple seconds) then you might want to use ACK_TIMER, but for most cases I don't believe it's necessary.

This thread has some discussion about SETs with ACK_TIMER in the context of scheduling EEPROM writes (the most common case)
http://rdmprotocol.org/forums/showthread.php?t=1218
Specifically, see the paragraph in my post that starts with "Some people feel this way..."

Originally Posted by sandor

2. In the ACK_TIME response do I have to inc the message count before I send the reply to the controller or not?

The message count field should be incremented when the actual response is ready for collection, not in the ACK_TIMER response. For example, if the controller requests GET DMX_PERSONALITY, the ACK_TIMER 5 seconds DMX_PERSONALITY response would have a message count of 0 (assuming there are not other messages to collect). Then, when the data is available 5 seconds later the responder should increment the message count.

Originally Posted by sandor

3. Till the given time not spent, the controllel can address other responders, just exclude my unit which needs time to finish the previous job (e.g. save the data to EEPROM/FLASH for the got SET command)

The controller can address other responders in the intervening time.

The controller can also address the same responder in the intervening time.

Some responders don't support this and can't handle a request that arrives while they are busy with an ACK_TIMER, but there's nothing in the standard that forbids a controller from trying, and I'd argue a well implemented responder should be able to handle it.

Originally Posted by sandor

4. When the TIME spent, the controller send QUEUED_MESSAGE to the responder which sent the ACK_TIME. Here I have to reply with the ACK for the previous SET (which requested TIME)?

Correct.

Originally Posted by sandor

5. In my reply if it is an ACK, do I use the TRANSACTION_NUMBER what I get from the controller for the QUEUED_MESSAGE or what I got in the SET command what for I replied with ACK_TIME?

The consensus is that the response should use the transaction number from the GET QUEUED_MESSAGE and not the transaction number from the original GET/SET request.

As of today, if you search the forum for ACK_TIMER, is shows 29 relevant threads. It's worth the time to read all of them, there's a lot of good discussion.