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 1 Week Ago   #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 1 Week Ago   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 348
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 1 Week Ago   #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 1 Week Ago   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 348
Default

NR_UNKNOWN_PID
ericthegeek is offline   Reply With Quote
Old 1 Week Ago   #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; 1 Week Ago at 05:08 PM.
shawn is offline   Reply With Quote
Old 1 Week Ago   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 348
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; 1 Week Ago at 01:49 PM. Reason: Wrote "responder" when I meant "controller"
ericthegeek is offline   Reply With Quote
Old 1 Week Ago   #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 1 Week Ago   #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; 1 Week Ago at 04:40 PM.
shawn is offline   Reply With Quote
Old 1 Week Ago   #9
peternewman
Junior Member
 
Join Date: Oct 2018
Location: London
Posts: 2
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 4 Days Ago   #10
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 348
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
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 09:42 AM
change parameter setting ilek79 RDM General Implementation Discussion 4 January 12th, 2017 10:15 PM
Second configurable DMX address stefkuhb RDM General Implementation Discussion 5 October 22nd, 2014 09:17 AM
DMX Addressing when Footprint is Zero Mark_C RDM General Implementation Discussion 8 January 17th, 2010 11:47 AM
Sub-device response to SET/GET DMX512 start address p_richart RDM Interpretation Questions 2 September 29th, 2006 10:27 AM


All times are GMT -6. The time now is 08:41 AM.


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