![]() |
|
RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard. |
![]() |
|
Thread Tools | Search this Thread | Display Modes |
![]() |
#1 |
Junior Member
Join Date: May 2018
Posts: 4
|
![]()
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 |
![]() |
![]() |
![]() |
#2 | |||||
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]() Quote:
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:
Quote:
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:
Quote:
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. |
|||||
![]() |
![]() |
![]() |
#3 |
Administrator
|
![]()
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 |
![]() |
![]() |
![]() |
#4 |
Junior Member
Join Date: May 2018
Posts: 4
|
![]()
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 |
![]() |
![]() |
![]() |
#5 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]()
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. |
![]() |
![]() |
![]() |
Bookmarks |
|
|
![]() |
||||
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 |