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

[shawn]

When a device's DMX footprint is 0, what should happen when trying to set the DMX start address? On one hand, the OLA RDM tests say this should return an error. But on the other, setting a start address may be desired if the device is internally set to a new, non-zero, footprint sometime later.

Thoughts?

[ericthegeek]

Most controllers won't display the UI that allows you to set the DMX address when the responder has a zero slot footprint. This means you won't even be able to send the SET request most of the time.


But if the responder does receive a SET request, it should NACK it and not act upon the request.

[shawn]

Which kind of NACK do you think would be best?

[ericthegeek]

NR_UNKNOWN_PID

[shawn]

I’m not sure I agree with that. The PID is known. I think the E1.37-2 reason, NR_ACTION_NOT_SUPPORTED, might be more appropriate (I found it after I asked). It specifically covers the case where the current setup doesn’t accommodate the request.

Update: I'll add: I'm working on a system where the device is programmable; also a library and API that can be incorporated into other embedded projects. It may change its footprint depending on how it's initialized and also on other external factors. i.e. the footprint is potentially dynamic.

[ericthegeek]

IMO using NR_ACTION_NOT_SUPPORTED is a very bad idea.

That NACK Reason code was not defined until E1.37-2 in 2014. Many controllers (especially older controllers and those that have not implemented '37-2) will not recognize it.

It's best to stick with the NACK Reason Codes that are defined in the core E1.20 document. You should only use the NR Codes from E1.37-x when the PID explicitly requires it, or you have no other valid choice.

Changing the personality can potentially change everything in a responder. Most controllers understand that when you change personalities you need to forget almost everything you know about the responder and re-query it.

In the case where the personality has a zero slot footprint, the DMX Address PID is not supported in that personality. It may be supported when you change to another personality, but as long as it's in the original personality NR_UNKNOWN_PID is the appropriate response.




For your API, most controllers won't expect the slot footprint to change on the fly. If it's truly dynamic from minute to minute you may have problems.

When a controller sees the same Model ID and Personality, it's reasonable for it to expect the responder will have the same footprint. It's probably best to have a different Device Model ID for each config. You could have the Model ID passed in during init.

[shawn]

Thanks for the explanation and for the additional comments on differing model IDs. The reasoning and the spec are a little clearer. I have more experience with the devices and not the controllers; hearing it from that perspective was helpful.

[shawn]

Just to clarify: Is it only necessary to send NR_UNKNOWN_PID for the SET version of DMX_START_ADDRESS? I know the spec says to return 0xFFFF for the GET version, but this seems a little asymmetrical.

[peternewman]

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.

[ericthegeek]

I'd suggest using NR_UNKNOWN_PID for GET also for the reason you mention (symmetry), but either behavior is OK.


You will need to use 0xFFFF in the Device Info Response since that field is always present no matter what the footprint.

[mikemac]

Why a NACK and not an ACK? Since the footprint is zero, the device isn't going to use any slots so it really shouldn't matter what the DMX address is set to. I would think returning a NACK to a controller could confuse it as it thinks it is sending a valid request.

[sblair]

Originally Posted by mikemac

Why a NACK and not an ACK? Since the footprint is zero, the device isn't going to use any slots so it really shouldn't matter what the DMX address is set to. I would think returning a NACK to a controller could confuse it as it thinks it is sending a valid request.

Mike, welcome to the forums!

There's two issues here. If the Footprint is zero then that means the Start Address PID is probably not a supported PID. The language in the current version of RDM creates some confusion here because the Start Address PID isn't one that is supposed to be sent in a SUPPORTED_PARAMETERS but it is also allowed not required if it doesn't have a footprint.

The other scenario is that the general view is that a device shouldn't ACK something unless the action has been completed. If you send a SET and it didn't actually do the set then that should be a NACK. If it allows you to actually change the address for use with other personalities that do have a non-zero footprint, then I agree that would be an ACK.

[peternewman]

I'm just going to echo part of my earlier post:

Originally Posted by peternewman

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

The asymmetry there is no different to almost every other PID.

Originally Posted by sblair

The other scenario is that the general view is that a device shouldn't ACK something unless the action has been completed.

Devil's advocate, should it ACK a SET of 0xFFFF?

[ericthegeek]

Peter,



There can be endless battles about which NACK Reason Code to use in a myriad of situations. There's no "right" answer to many of those cases. This is especially true when looking at cases like this.


Fortunately, even though there's no canonical answer, it doesn't really hurt interoperability. For most real-world situations there are only two categories of NACKs: Transient and Final (my terms, not anything that's defined in the standard). In general, it doesn't really matter which specific NACK you use, as long as you use one from the right category.


A transient NACK represents a situation where the request failed this time, but might succeed if you retry. This category includes Proxy Reject and Buffer Full. In these situations, the controller might want to retry before notifying the user of a failure.


A final NACK tells the controller that the request has definitively failed. There's no point in retrying because it will fail again. This category includes Unknown PID and Format Error. For these cases the controller will usually notify the user, and the NACK Reason code just gives the user a hint about why it failed It would be unusual for the controller to try and programmatically act on a NACK in this category.



Seen from this perspective, the NACK Reason should be selected to give the user the best understanding of what's gone wrong, and an inkling of how to correct it. With only a few codes to pick from this can be challenging, but it's all that's available.


There are obviously some grey areas here (Hardware Fault, Write Protect), but IMO it's a good way to approach NACK'ing.





In the past, there have been some requests to make NACK'ing extremely prescriptive; Each PID would have a list of ways it can fail, and an explicit requirement of which NACK to use. It's impossible to enumerate everything that can go wrong. In the end, it's up to the implementer to make sensible choices.

[peternewman]

Originally Posted by ericthegeek

Transient and Final (my terms, not anything that's defined in the standard). In general, it doesn't really matter which specific NACK you use, as long as you use one from the right category.

I agree with the concept of this entirely.

Originally Posted by ericthegeek

A final NACK tells the controller that the request has definitively failed. There's no point in retrying because it will fail again. This category includes Unknown PID and Format Error.

And this, for a given message content, I'd always expect to get a format error back, which is the heart of my objection to Unknown PID, and why I'm a bit surprised to see you classify it as final but then suggest using it in a somewhat transient way.

Assuming it has personalities with zero, and great than zero footprints, then I'd suggest that not being able to set the address is transient (until we change personality) rather than final. In comparison, if it's got no sensors, or you can't set the language, those things are likely to be final for the life of the fixture.

As a controller GUI developer, I'd like to be able to use NACKs like unknown PID/unsupported command class to make my GUI more user friendly, by disabling the ability to change stuff I know won't ever work, which I can't do if a final state is actually transient. In comparison, when I get a write protect, I can disable submission and prompt the user to unlock the device.

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