|
RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard. |
|
Thread Tools | Search this Thread | Display Modes |
October 22nd, 2009 | #1 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
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 |
October 22nd, 2009 | #2 | |
Administrator
|
Quote:
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 |
|
October 22nd, 2009 | #3 | |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Quote:
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 |
|
October 22nd, 2009 | #4 |
Administrator
|
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 |
October 22nd, 2009 | #5 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
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. |
October 22nd, 2009 | #6 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
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 |
October 22nd, 2009 | #7 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
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 |
October 22nd, 2009 | #8 |
Administrator
|
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 |
October 22nd, 2009 | #9 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
Yep, they are still out there. we get them too, occasionally.
Someone somewhere is still writing code like that! Regards Bernt |
October 23rd, 2009 | #10 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
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 |
October 23rd, 2009 | #11 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
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. |
Bookmarks |
|
|