E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   SET_COMMAND_RESPONSE TIMER_ACK (http://www.rdmprotocol.org/forums/showthread.php?t=1273)

majid December 14th, 2017 03:53 AM

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

prwatE120 December 14th, 2017 04:37 AM

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

majid December 14th, 2017 07:33 AM

Quote:

Originally Posted by prwatE120 (Post 3125)
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

ericthegeek December 14th, 2017 09:44 AM

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

majid December 14th, 2017 12:48 PM

Quote:

Originally Posted by ericthegeek (Post 3131)
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 December 14th, 2017 11:27 PM

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 ?

sblair December 14th, 2017 11:59 PM

Quote:

Originally Posted by majid (Post 3133)
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.

majid December 15th, 2017 03:36 AM

Quote:

Originally Posted by sblair (Post 3134)
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 March 14th, 2018 05:02 AM

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

prwatE120 March 14th, 2018 05:10 AM

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

majid March 14th, 2018 06:05 AM

Quote:

Originally Posted by prwatE120 (Post 3150)
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();
}

ericthegeek March 14th, 2018 09:26 AM

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.

majid March 14th, 2018 07:41 PM

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 March 15th, 2018 05:56 AM

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

ericthegeek March 15th, 2018 09:20 AM

Quote:

Originally Posted by majid (Post 3154)
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.

majid March 16th, 2018 07:49 AM

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 November 2nd, 2018 09:02 AM

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 ?

ericthegeek November 2nd, 2018 09:47 AM

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 November 2nd, 2018 09:58 AM

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.

majid November 2nd, 2018 10:36 AM

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 07:59 PM.

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