E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old December 1st, 2018   #1
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 16
Default How should a device with footprint=0 respond to setting the DMX start address?

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?
shawn is offline   Reply With Quote
Old December 3rd, 2018   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.
ericthegeek is offline   Reply With Quote
Old December 3rd, 2018   #3
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 16
Default

Which kind of NACK do you think would be best?
shawn is offline   Reply With Quote
Old December 3rd, 2018   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

NR_UNKNOWN_PID
ericthegeek is offline   Reply With Quote
Old December 3rd, 2018   #5
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 16
Default

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.

Last edited by shawn; December 3rd, 2018 at 04:08 PM.
shawn is offline   Reply With Quote
Old December 3rd, 2018   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.

Last edited by ericthegeek; December 7th, 2018 at 12:49 PM. Reason: Wrote "responder" when I meant "controller"
ericthegeek is offline   Reply With Quote
Old December 7th, 2018   #7
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 16
Default

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 is offline   Reply With Quote
Old December 7th, 2018   #8
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 16
Default

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.

Last edited by shawn; December 7th, 2018 at 03:40 PM.
shawn is offline   Reply With Quote
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
Old December 10th, 2018   #10
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.
ericthegeek is offline   Reply With Quote
Old December 15th, 2018   #11
mikemac
Junior Member
 
Join Date: Dec 2018
Location: Arizona
Posts: 1
Default

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.
mikemac is offline   Reply With Quote
Old December 15th, 2018   #12
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by mikemac View Post
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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old December 16th, 2018   #13
peternewman
Junior Member
 
Join Date: Oct 2018
Location: London
Posts: 5
Default

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

Quote:
Originally Posted by peternewman View Post
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.


Quote:
Originally Posted by sblair View Post
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?
peternewman is offline   Reply With Quote
Old December 16th, 2018   #14
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.
ericthegeek is offline   Reply With Quote
Old December 17th, 2018   #15
peternewman
Junior Member
 
Join Date: Oct 2018
Location: London
Posts: 5
Default

Quote:
Originally Posted by ericthegeek View Post
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.

Quote:
Originally Posted by ericthegeek View Post
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 is offline   Reply With Quote
Old December 17th, 2018   #16
peternewman
Junior Member
 
Join Date: Oct 2018
Location: London
Posts: 5
Default

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.
peternewman is offline   Reply With Quote
Old December 17th, 2018   #17
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

Quote:
Originally Posted by peternewman View Post
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.
ericthegeek is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to handle DMX Footprint overrun RobbG RDM General Implementation Discussion 3 May 8th, 2017 08:42 AM
change parameter setting ilek79 RDM General Implementation Discussion 4 January 12th, 2017 09:15 PM
Second configurable DMX address stefkuhb RDM General Implementation Discussion 5 October 22nd, 2014 08:17 AM
DMX Addressing when Footprint is Zero Mark_C RDM General Implementation Discussion 8 January 17th, 2010 10:47 AM
Sub-device response to SET/GET DMX512 start address p_richart RDM Interpretation Questions 2 September 29th, 2006 09:27 AM


All times are GMT -6. The time now is 08:11 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.