How should a device with footprint=0 respond to setting the DMX start address?

[peternewman]

Actually re-reading your post, I'd perhaps suggest there are three states, and maybe that's where our disagreement comes from:

Transient:
Failed this time, may work later, worth retrying
E.g. Proxy Reject, Buffer Full
I'd probably put hardware error in here too, but perhaps retry fewer times than some of the other errors

Final:
Won't work without changes to the packet or potentially external changes
E.g. write protected, data out of range

Terminal (other, better names are available I'm sure):
Will never work without changes to the packet
E.g. format error
Personally I would put unknown PID/unsupported command class in this section, I believe you feel it should go in the one above?

E.g. setting the DMX address to 510 will fail (or at least should) while the fixture is in 10 channel mode, but if we switch it into 1 channel mode, the exact same packet will then succeed. Likewise for a locked/unlocked device, or a slot label request to slot 10 between the two different personalities.

However a set DMX address with a PDL of zero will fail terminally with a format error; it can never work regardless of what we do to the fixture. I think unknown PID/unsupported command class should be in the same category, otherwise I have to keep retrying a set DMX address to see if the fixture has now decided to allow me to do so.

[ericthegeek]

Originally Posted by peternewman

Actually re-reading your post, I'd perhaps suggest there are three states, and maybe that's where our disagreement comes from:

Fully agree. You probably noticed that I didn't include every NACK Reason code in my category list because, as you point out, there are varying degrees of finality.


Please don't think I'm trying to give a prescription on how to handle NACKs. Rather, I'm suggesting a way to think about NACKs and what their purpose is.



Some requests won't ever work. Some might work if the personalty changes. Some might work if an external factor changes ("can't strike the lamp now, but might be able to if the line voltage increases"). Some requests just got unlucky and might work 10 milliseconds later. It's a range rather than two or three hard categories.



When implementing a responder, you need to pick a sensible Reason Code based on what you want the controller (and user) to know. Most importantly the responder must NACK. There are lots of responders out there that never NACK (they just ignore any requests they don't understand). This causes *lots* of problems.



When implementing a controller you need to determine how to handle each NACK. Retry? Write an error in a debug log? Notify the user. The "Right" way to do this will vary from controller to controller. Any "Well thought through" implementation is probably fine since you've taken the time to think about it.