Clearify ACK_TIMER than QUEUED_MESSAGE

[sandor]

Hello,

I've read several post about ACT_TIMER and QUEUED_MESSAGE, please help me to sum and clear the things about it:

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?
2. In the ACK_TIME response do I have to inc the message count before I send the reply to the controller or not?
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)
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)?
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?

Thanx in advance!

Sandor
www.pls.hu

[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.

[sblair]

Sandor,

Just to add another voice here I agree with all of Eric's responses.

On item #1 there is a lot of differing feelings on this and it is very implementation specific. My opinion on it matches Eric's but I know there are some people that believe everything should be ACK_TIMER unless the EEPROM write process is completed.

[sandor]

Hello,

Thank you guys for the replies.
My personal experiance that if I use ACK while I save datas in EEPROM which is longer than 2mS the ACK_TIMER is better. If I do not reply within 2mS the controller can ask me where am I (with e.g. GET_STATUS) and it can recognise false that I'm no more on the line.

Regards,

Sandor

[ericthegeek]

I recommend writing the EEPROM in the lazy loop to avoid this problem rather than blocking your RDM routine for the entire time that it takes to complete the EEPROM write.

These older posts have more details:
http://www.rdmprotocol.org/forums/sh...61&postcount=6
http://www.rdmprotocol.org/forums/sh...12&postcount=2

You don't always have 2ms to process a SET. You can take but to 2ms to respond to a unicast request, but that doesn't apply to broadcast/vendorcast requests. The controller can broadcast a SET command, and then issue a GET for the same data 176 microseconds later. If you're blocked handling the broadcast set, you'll miss the next request.