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 |
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. |
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 |
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. |
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. |
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 |
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 |
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.... |
Yep, they are still out there. we get them too, occasionally.
Someone somewhere is still writing code like that! Regards Bernt |
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 |
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 03:40 AM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.