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 December 14th, 2017   #1
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default 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 is offline   Reply With Quote
Old December 14th, 2017   #2
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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
prwatE120 is offline   Reply With Quote
Old December 14th, 2017   #3
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

Quote:
Originally Posted by prwatE120 View Post
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
I got it!

thank you Peter
majid is offline   Reply With Quote
Old December 14th, 2017   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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..."
ericthegeek is offline   Reply With Quote
Old December 14th, 2017   #5
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

Quote:
Originally Posted by ericthegeek View Post
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..."
thread is usefull thanks.

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,
majid is offline   Reply With Quote
Old December 14th, 2017   #6
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

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 ?
majid is offline   Reply With Quote
Old December 14th, 2017   #7
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by majid View Post
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 ?
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
sblair is offline   Reply With Quote
Old December 15th, 2017   #8
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

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

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.
majid is offline   Reply With Quote
Old March 14th, 2018   #9
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default OLA SetOversizedDeviceLabel Fail

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
Attached Images
File Type: jpg sniffer.jpg (94.7 KB, 650 views)
majid is offline   Reply With Quote
Old March 14th, 2018   #10
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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
prwatE120 is offline   Reply With Quote
Old March 14th, 2018   #11
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

Quote:
Originally Posted by prwatE120 View Post
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
thanks for reply ,
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();
}
majid is offline   Reply With Quote
Old March 14th, 2018   #12
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old March 14th, 2018   #13
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

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"
majid is offline   Reply With Quote
Old March 15th, 2018   #14
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

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

Quote:
Originally Posted by majid View Post
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
This is a common problem.

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.
ericthegeek is offline   Reply With Quote
Old March 16th, 2018   #16
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

Ok Eric
I got it, I m going to fix it
Maybe save device label to eeprom gradually in background as you mentioned

Thanks
majid is offline   Reply With Quote
Old November 2nd, 2018   #17
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

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 ?
majid is offline   Reply With Quote
Old November 2nd, 2018   #18
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old November 2nd, 2018   #19
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old November 2nd, 2018   #20
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

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


All times are GMT -6. The time now is 06:48 AM.


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