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 October 22nd, 2009   #1
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default RESET_DEVICE

Hi all

If a device can only support one of the 2 reset types (cold/warm) than should it NACK the other as NR_DATA_OUT_OF_RANGE or should it just ACK and not do anything?

Also, should a warm reset also reset the MUTE flag?

Regards
Bernt
berntd is offline   Reply With Quote
Old October 22nd, 2009   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Section 10.11.2
This parameter is used to instruct the responder to reset itself. This parameter shall also clear the Discovery Mute flag.

So regardless, the Mute flag should be cleared.

I only support one reset mode myself, so if I get any non-zero value for the PD then I go ahead and do a reset.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 22nd, 2009   #3
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by sblair View Post



So regardless, the Mute flag should be cleared.

I only support one reset mode myself, so if I get any non-zero value for the PD then I go ahead and do a reset.
Hi Scott,

I see where you are coming from and I suppose one could do the reset for both types requessted.
However, what you say about "any value" somehow does not sound right.

Why else would the spec point out 2 distinct values for the pd for reset?
What if they cime up with other values for different resets in the future?

Surely values other than those 2 are definitely out of range and should be NACK?


Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 22nd, 2009   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Strictly speaking it would be perfectly reasonable to NACK as you suggest. It doesn't say that I must NACK if I receive something out of that range though. It is up to me whether I want to accept it. I tend to be fairly liberal in what I allow in my coding. If I get a RESET_DEVICE message then I'm pretty sure that intended desire was to reset the fixture so it's fairly easy for me to infer the intent and act on it.

I could also take a very strict approach though as you suggest.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 22nd, 2009   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

I would probably NACK with NR_DATA_OUT_OF_RANGE when you see a reset type you don't support.

Hypothetically, a future revision of the standard could define additional kinds of resets, and you'd want a controller issuing one of those resets to know that your devices doesn't support it.
ericthegeek is offline   Reply With Quote
Old October 22nd, 2009   #6
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

I'm with Eric on this.

A reset is pretty severe. If the controller has not issued exactly what is required I would issue a NACK_DATA_OUT_OF_RANGE, and not undertake the reset.

Peter Willis
prwatE120 is offline   Reply With Quote
Old October 22nd, 2009   #7
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Yep, it is a bit like ignoring the DMX_START_CODE == 0.
Look where that got us in the end :D:D


Anyway, should I now perform the same reset for warm and cold or ignore / NACK the one I actually do not support?

Regards
Bernt
berntd is offline   Reply With Quote
Old October 22nd, 2009   #8
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

I would perform the same for both if you only support one. Makes it much easier for the user that is trying to reset his entire rig at once.

As far as ignoring the START Code. I saw a fog machine yesterday that did exactly that....
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 22nd, 2009   #9
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Yep, they are still out there. we get them too, occasionally.

Someone somewhere is still writing code like that!

Regards
Bernt
berntd is offline   Reply With Quote
Old October 23rd, 2009   #10
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

I disagree with Scott on this.

If you dont have the concept of warm reset, NACK the message and ignore.

Or if you ONLYhave warm reset, NACK the cold reset.

Do what you were asked, nothing more. That's why we had two possible argument values.

What I would add is the expectation that if you only support one reset type, I would advocate that should provide the same level of functionality as pulling the power and reconnecting ....


Peter Willis
prwatE120 is offline   Reply With Quote
Old October 23rd, 2009   #11
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Well, philosophically I'd argue that you can't trigger a true COLD_RESET from software. A cold reset involves the power switch or a circuit breaker...

I'm OK with either behavior.
Treating the two reset types as equivalent when you only have one kind of reset is fine.

It's also reasonable to NACK the other kind if you only support one.
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


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


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