E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old May 14th, 2018   #1
sandor
Junior Member
 
Join Date: May 2018
Posts: 4
Default Clearify ACK_TIMER than QUEUED_MESSAGE

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

Last edited by sandor; May 14th, 2018 at 07:03 AM. Reason: add one more question
sandor is offline   Reply With Quote
Old May 14th, 2018   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by sandor View Post
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..."


Quote:
Originally Posted by sandor View Post
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.


Quote:
Originally Posted by sandor View Post
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.


Quote:
Originally Posted by sandor View Post
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.


Quote:
Originally Posted by sandor View Post
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.
ericthegeek is offline   Reply With Quote
Old May 14th, 2018   #3
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old May 15th, 2018   #4
sandor
Junior Member
 
Join Date: May 2018
Posts: 4
Default

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
sandor is offline   Reply With Quote
Old May 15th, 2018   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
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
QUEUED_MESSAGE & Status Types pkleissler RDM Interpretation Questions 13 August 1st, 2019 03:23 AM
QUEUED_MESSAGE - must controllers support this? berntd RDM General Implementation Discussion 2 October 31st, 2013 10:06 PM
Please clarify: QUEUED_MESSAGE (10.3 Collection of Queued and Status Messages) berntd RDM Interpretation Questions 1 September 27th, 2013 06:33 PM
QUEUED_MESSAGE - ? berntd RDM General Implementation Discussion 9 November 24th, 2009 08:48 AM


All times are GMT -6. The time now is 03:09 AM.


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