![]() |
|
RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard. |
![]() |
|
Thread Tools | Search this Thread | Display Modes |
![]() |
#1 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
6.3.3 says responder shall response GET/SET command with TIMER_ACK when it takes more than 2ms to do command,
and put the response in queue after doing command but in SET RESPONSE packet, PD is not present and PDL = 0 so what should be put in queue , while PD is not present ? in my case it takes 5 ms to save START_ADDRESS in EEPROM, so my responder must respond SET_COMMAND_RESPONSE TIMER_ACK 6ms, I am confused about what to put in queue after saving data in EEPROM |
![]() |
![]() |
![]() |
#2 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
![]()
Majid
you should queue what you would have responded with if there had been NO need to issue the ACK_TIMER. In other words, a SET_RESPONSE packet with PID = START_ADDRESS and PDL = 0. Peter |
![]() |
![]() |
![]() |
#3 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]() |
![]() |
![]() |
![]() |
#4 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]()
The spec for ACK_TIMER has some ambiguity, so not everyone implements it the same way. I generally recommend avoiding ACK_TIMER and only using it if you absolutely have to.
This older thread has a lot of discussion about scheduling EEPROM write. http://rdmprotocol.org/forums/showthread.php?t=1218 Specifically, see the paragraph in my post that starts with "Some people feel this way..." |
![]() |
![]() |
![]() |
#5 | |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]() Quote:
I didn't use ACK_TIMER at first, set address is successful but the controller (XMT-350) shows warning after setting address, I traced and found out its because of EEPROM write delay. warning is annoyning , I will try use queue to handle that seems a little complicated but it worths ! I also plan to implement SET DEVICE_LABEL, it is 32 bytes and write delay will be up to 100ms, |
|
![]() |
![]() |
![]() |
#6 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
I wonder if the responder response a command with ACK_TIMER T ms,
will the controller stop asking ALL commands during T ms ? or the controller may ask other commands except queued command during T ms ? |
![]() |
![]() |
![]() |
#7 |
Administrator
|
![]()
There are no requirements on the controller here so it may continue to ask for other PIDs besides the one it has been ACK_TIMER on.
__________________
Scott M. Blair ![]() RDM Protocol Forums Admin |
![]() |
![]() |
![]() |
#8 | |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]() Quote:
so the responder need to be a sort of multitasking, continue responding commands and doing previously queued commands, but I expect controller not to ask previously queued command again before required time elapsed anyway I implemented queue and problem seems fixed, there is no annoying "COMMUNICATION WARNING ... " message any more just a progress bar appears with "SENDING" caption and then dissapears automatically. |
|
![]() |
![]() |
![]() |
#9 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
I have implemented Get/Set DEVICE_LABEL
It works fine with XMT-350 and ENTTEC USB PRO MK2 but during RDM responder test, OLA says "SetOversizedDeviceLabel Fail" SET: pid: DEVICE_LABEL (0x0082), sub device: 0, data: 'this is a string which is more than 32 characters' Request status: Response Timeout Failed: expected one of: CC: Set, PID 0x0082, NACK Write protectAttachment 50 CC: Set, PID 0x0082, NACK Format Error CC: Set, PID 0x0082, NACK Packet size unsupported CC: Set, PID 0x0082, NACK Unsupported command class CC: Set, PID 0x0082, ACK, fields [], values {} I have already handled over sized condition then when I use sniffer to trace the bug, I see there is not SET DEVICE_LABEL at all from OLA during test. please help me to solve this regards |
![]() |
![]() |
![]() |
#10 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
![]()
Try running the RDMIntegrity tests. There is comprehensive string testing and error reporting.
If your responder does receive a SET text string that is longer than 32 characters, I would expect a NACK : FORMAT ERROR to be returned. Peter |
![]() |
![]() |
![]() |
#11 | |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]() Quote:
I also handled over size by responding NACK FORMAT ERROR as you said but there is not SET DEVICE_LABEL at all from OLA (please see previous post attachment) I think my code does not response because there is no Set command during test 7 transactions, I am not sure. here is my code : if (ucRxData[INDEX_PDL] <= 32) { // normal response } else { // page29 ucTxData[INDEX_RESPONSE_TYPE] = RESPONSE_TYPE_NACK_REASON; ucTxData[INDEX_SUB_DEVICE] = ucRxData[INDEX_SUB_DEVICE]; ucTxData[INDEX_SUB_DEVICE + 1] = ucRxData[INDEX_SUB_DEVICE + 1]; i = INDEX_CC; ucTxData[i++] = CC.SetResponse; ucTxData[i++] = ucRxData[INDEX_PID]; ucTxData[i++] = ucRxData[INDEX_PID + 1]; ucTxData[i++] = 0; // PDL = 2 , will be assigned before checksum... ucTxData[i++] = NR.FormatError >> 8; // page29, Table A-17 page 117 ucTxData[i++] = NR.FormatError; ucTxData[INDEX_MESSAGE_LENGTH] = i; ucTxData[INDEX_PDL] = i - INDEX_PD; rdm_send_tx_buffer(); } |
|
![]() |
![]() |
![]() |
#12 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]()
Are you sure the SET didn't happen before the 7 messages you're showing in the screenshot? The OLA tests can generate detailed logs. I don't remember the command line option, but it should give you a better idea of what's happening.
IIRC, OLA will try to SET, then after the SET it will do a GET to see if the SET worked. The following GET happens regardless of whether the SET was ACK'd. It looks like some of the responses may be getting dropped. For example, there's no response to the GET QUEUED_MESSAGE requests. |
![]() |
![]() |
![]() |
#13 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
Thanks Eric
. You are right my code does not reply when queue is empty. I need to fix it. . My device does not support STATUS_MESSAGE Shall I response with STATUS_MESSAGE PDL=0 ? . I am not sure understood last sentence of 10.3.1, 3rd paragraph : "A STATUS_MESSAGE response with a PDL of 0x00 does not imply that the responder supports the STATUS_MESSAGES PID" |
![]() |
![]() |
![]() |
#14 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
OK
after implementing 10.3.1 I could see the SET DEVICE label transaction from OLA on sniffer, I traced the bug, it was because of short timeout of my code on receiving RDM packet, I increased my timeout to accept longer packets, and solved now my device passes "SetOversizedDeviceLabel" only two further fails remains: "SetBroadcastDeviceLabel" and "SetVendorcastDeviceLabel" related to EEPROM when I temporarily use RAM instead of EEPROM to save Device Label, OLA test result: Failed=0, Not Run=59, Passed=348 when I save Device Label to EEPROM, Failed=2, Not Run=59, Passed=346 |
![]() |
![]() |
![]() |
#15 | |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]() Quote:
When a responder receives a unicast request it can take up to 2ms to respond. So, if the responder software takes a while to parse the request and respond, the controller will wait. But after a broadcast or vendorcast request, the next request from the controller can arrive in an little as 176us. This means that your responder needs to be ready for a new request much sooner than with a unicast request. You don't have to be finished handling the prior request, you just need to be ready to accept a new one. Often this means double buffering your receiver and doing some processing of the broadcast/vendorcast request in the background. |
|
![]() |
![]() |
![]() |
#16 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
Ok Eric
I got it, I m going to fix it Maybe save device label to eeprom gradually in background as you mentioned Thanks |
![]() |
![]() |
![]() |
#17 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
I progressed to "Fail = 0" and "Warning = 0" on OLA Responder Tester
my device supports GET_DEVICE_HOURS, but not SET_DEVICE_HOURS at first I ignored SET_DEVICE_HOURS command, and OLA warned me to response with NR_WRITE_PROTECTED or NR_UNSUPPORTED_COMMAND_CLASS also table A-17 says : "NR_UNSUPPORTED_COMMAND_CLASS may be used where GET allowed and SET not supported" when I NR_UNSUPPORTED_COMMAND_CLASS , OLA advisory says: "returned unsupported command classs" when I NR_WRITE_PROTECTED , OLA advisory says: "was write protected, try changing the lock mode if enabled" my question is how can I pass this advisory messages ? |
![]() |
![]() |
![]() |
#18 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]()
Unsupported Command Class is the correct response in this case.
The automated test suites (such as the OLA Responder Test) are great tools for finding problems with your implementation. But they're not a formal compliance test, and your implementation may be just fine even if you get some "failures". In this case, it's just telling you that you NACK'd the SET command. Yes, that's right, you NACK'd the SET and that's exactly what you meant to do. You should ignore the advisory message. That's why it's an advisory. I generally recommend that you treat the automated test suites like warnings from a compiler. They can help you find mistakes and errors, and things you may not have thought of. But if the behavior was intentional, and you understand why you did it that way, than you can safely ignore it. |
![]() |
![]() |
![]() |
#19 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]()
I realized I should have given an example in my prior post:
In several of my implementations I have a mix of sensors. Some of the sensors are GET'able and SET'able, but others are GET only. This drives the Automated test suites crazy, and they return lots of warnings. Sometimes it makes sense to SET a sensor. Let's say you have a fog machine that measures the heater current, and tracks MIN/MAX current. For that sensor, you can use SET to reset the min and max values. But for the Fog Fluid Level sensor there's nothing to set. It's reading a physical level, and doesn't track min/max. SET'ing that sensor doesn't do anything, so it's appropriate to NACK it. In cases like this it's legit to NACK SET for some sensors, and ACK it for others. I could "fix" the test suite warnings by always ACK'ing SET, but that would be misleading since the SET didn't actually do anything. |
![]() |
![]() |
![]() |
#20 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
Thanks for your complete explanations
. Great example, it clarifies the subject. Thanks for sharing your invaluable experiences. Last edited by majid; November 2nd, 2018 at 11:00 AM. |
![]() |
![]() |
![]() |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|