E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old December 9th, 2019   #1
lomo1316
Junior Member
 
Join Date: Dec 2019
Posts: 2
Default InvalidDiscoveryPID: FAILED

In my test with 'RDM Responder Tests',the following problem occurred:
InvalidDiscoveryPID: FAILED
Send an invalid Discovery CC PID, see E1.20 6.3.4
DISCOVERY: pid: 0x000f, sub device: 0, data: ''
Response: RDMResponse(type=NACK, reason="Unknown PID"), PID: 0x000f, TN: 26
Failed: expected one of:
RDM_TIMEOUT
RDM_PLUGIN_DISCOVERY_NOT_SUPPORTED

so, a question I have: Whether all PIDs less than 0x0010 are Discovery CC PIDs.
lomo1316 is offline   Reply With Quote
Old December 9th, 2019   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Welcome to the forums. Which RDM Test Platform are you using? There's a couple out there so knowing that will help.

The Discovery Command Class is 0x10. This is detailed in Table A-1. The PID values are in Table A-3 in the document.

What are you are probably seeing is that Section 6.3.4 stipulates that a NACK is only sent for unknown GET_COMMAND and SET_COMMAND requests.

If you see a Command Class for DISCOVERY_COMMAND then you should not send a NACK.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old December 9th, 2019   #3
lomo1316
Junior Member
 
Join Date: Dec 2019
Posts: 2
Default

Quote:
Originally Posted by sblair View Post
Which RDM Test Platform are you using? There's a couple out there so knowing that will help.

What are you are probably seeing is that Section 6.3.4 stipulates that a NACK is only sent for unknown GET_COMMAND and SET_COMMAND requests.

If you see a Command Class for DISCOVERY_COMMAND then you should not send a NACK.
Thanks for your reply.Now I begin to understand my mistake.I use "OLA RDM Responder Tests &Publisher"(Sorry,I don't know why I can't upload the attachment),I have some instances, please tell me the following responses are correct?

In the case of unicast:

CC: 0x10, PID:0x000F(Unknown PID) ------> Response : RDM_TIMEOUT
CC: 0x20, PID:0x000F(Unknown PID) ------> Response : NACK, NR_UNKNOWN_PID
CC: 0x30, PID:0x000F(Unknown PID) ------> Response : NACK, NR_UNKNOWN_PID

CC: 0x20, PID:0x0002(DISC_MUTE) ------> Response : NACK, NR_UNSUPPORTED_CC
CC: 0x30, PID:0x0002(DISC_MUTE) ------> Response : NACK, NR_UNSUPPORTED_CC


CC: 0x10, PID: >0x0003(Not Discovery PID) ------> Response : RDM_TIMEOUT
lomo1316 is offline   Reply With Quote
Old January 6th, 2020   #4
peternewman
Junior Member
 
Join Date: Oct 2018
Location: London
Posts: 11
Default

Quote:
Originally Posted by sblair View Post
What are you are probably seeing is that Section 6.3.4 stipulates that a NACK is only sent for unknown GET_COMMAND and SET_COMMAND requests.
Indeed Scott, OLA is sending an imaginary PID (0x000f) rather than sending a DUB or Mute/Un-Mute, as a DISCOVERY_COMMAND command class.

You can see the code here, which as it's Python is reasonably human-readable:
https://github.com/OpenLightingProje...s.py#L167-L190
Quote:
Originally Posted by lomo1316 View Post
I have some instances, please tell me the following responses are correct?

In the case of unicast:

CC: 0x10, PID:0x000F(Unknown PID) ------> Response : RDM_TIMEOUT
CC: 0x20, PID:0x000F(Unknown PID) ------> Response : NACK, NR_UNKNOWN_PID
CC: 0x30, PID:0x000F(Unknown PID) ------> Response : NACK, NR_UNKNOWN_PID

CC: 0x20, PID:0x0002(DISC_MUTE) ------> Response : NACK, NR_UNSUPPORTED_CC
CC: 0x30, PID:0x0002(DISC_MUTE) ------> Response : NACK, NR_UNSUPPORTED_CC


CC: 0x10, PID: >0x0003(Not Discovery PID) ------> Response : RDM_TIMEOUT
Almost lomo1316, but the last one, 0x0003 is a discovery PID, so you should ACK via DISCOVERY_COMMAND_RESPONSE (assuming the response was valid).
Quote:
Originally Posted by prwatE120 View Post
I suggest you also consider using RDMIntegrity for your testing. It produces log files you can email others that show the exact sequence of testing. It also (with the appropriate hardware) allows checking of the RDM Timing, which is critical to correct/reliable RDM behaviour. The issue, as Scott as identified, is that NACK is only applicable to the GET/SET command class. If the command class is not as per Table A-1 you cannot reply. Peter
I think that's a little unfair Peter, the OLA RDM Responder Tests produce logs too, which is exactly what was in the first post, they just snipped it, or possibly only ran, the single failing test. Indeed I'd argue that because the OLA tests are open source, meaning anyone can inspect the exact code the test is running (see the link earlier in this post), that should either give them a strong nudge in the right direction, or allow them to raise a bug if they think there should be a different interpretation of the standard (somewhat frequent) or occasionally because OLA is at fault, because we're not infallible; nobody is. The OLA tests also allow checking of timing too with suitable interfaces. Although data/response issues such as this will occur regardless of the transport mechanism, be that conventional DMX/RDM, ArtNet or E1.33.
Quote:
Originally Posted by lomo1316 View Post
Sorry,I don't know why I can't upload the attachment
I can't either; I've reported this to the webmaster of these forums, hopefully they'll be able to fix it soon.
peternewman is offline   Reply With Quote
Old December 10th, 2019   #5
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

I suggest you also consider using RDMIntegrity for your testing. It produces log files you can email others that show the exact sequence of testing. It also (with the appropriate hardware) allows checking of the RDM Timing, which is critical to correct/reliable RDM behaviour. The issue, as Scott as identified, is that NACK is only applicable to the GET/SET command class. If the command class is not as per Table A-1 you cannot reply. Peter
prwatE120 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 05:30 AM.


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