InvalidDiscoveryPID: FAILED

[lomo1316]

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.

[sblair]

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.

[lomo1316]

Originally Posted by sblair

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

[prwatE120]

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

[peternewman]

Originally Posted by sblair

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

Originally Posted by lomo1316

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

Originally Posted by prwatE120

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.

Originally Posted by lomo1316

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.