View Single Post
Old December 8th, 2018   #9
peternewman
Junior Member
 
Join Date: Oct 2018
Location: London
Posts: 5
Default

I'd be inclined to disagree with you Eric, or at least look at another NAck Reason Code. Although I'd agree not to go using one from a different standard.

For what it's worth, the OLA RDM tests currently allow the following:
  • NR_UNKNOWN_PID
  • NR_UNSUPPORTED_COMMAND_CLASS
  • NR_DATA_OUT_OF_RANGE
https://github.com/OpenLightingProje...py#L2300-L2302

To me, NR_DATA_OUT_OF_RANGE sounds ideal, from the RDM standard description "Value for given Parameter out of allowable range or not supported.".

Unknown PID seems like it could have the potential to confuse controllers, do you support the PID or not? To some extent likewise with Unsupported Command Class if you support it sometimes...

There's currently a public review of E1.20, which is an excellent time to try and resolve such issues:
http://tsp.esta.org/tsp/documents/pu...eview_docs.php

I'd agree you shouldn't change it dynamically, but if you really wanted, you could silently track the requested changes (while still NAcking), so when it next has a start address, you could default to the last one set (if valid), as if someone had set it on the front panel, although that may be more confusing than anything else. You'd want to queue a response too.
peternewman is offline   Reply With Quote