SET_COMMAND_RESPONSE TIMER_ACK
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 |
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 |
Quote:
thank you Peter |
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..." |
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, |
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 ? |
Quote:
|
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. |
OLA SetOversizedDeviceLabel Fail
1 Attachment(s)
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 |
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 |
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(); } |
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. |
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" |
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 |
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. |
Ok Eric
I got it, I m going to fix it Maybe save device label to eeprom gradually in background as you mentioned Thanks |
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 ? |
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. |
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. |
Thanks for your complete explanations
. Great example, it clarifies the subject. Thanks for sharing your invaluable experiences. |
All times are GMT -6. The time now is 05:57 AM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.