View Single Post
Old January 6th, 2020   #5
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