E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   RESET_DEVICE (http://www.rdmprotocol.org/forums/showthread.php?t=1043)

berntd October 22nd, 2009 03:34 PM

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

sblair October 22nd, 2009 03:41 PM

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.

berntd October 22nd, 2009 03:48 PM

Quote:

Originally Posted by sblair (Post 1807)



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

sblair October 22nd, 2009 04:11 PM

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.

ericthegeek October 22nd, 2009 04:16 PM

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.

prwatE120 October 22nd, 2009 04:39 PM

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

berntd October 22nd, 2009 04:41 PM

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

sblair October 22nd, 2009 04:44 PM

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

berntd October 22nd, 2009 04:52 PM

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

Someone somewhere is still writing code like that!

Regards
Bernt

prwatE120 October 23rd, 2009 01:11 AM

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

ericthegeek October 23rd, 2009 09:36 AM

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.


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

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