driver/make Decadac verbosely fail for out-of-range voltages #857
Conversation
|
👍 is there still any chance for a +- 1 over/underflow that we need to catch? |
|
Hmm, good question. I guess it is always better to be on the safe side. |
| @@ -26,12 +26,14 @@ def _dac_v_to_code(self, volt): | |||
| based on the minimum/maximum values of a given channel. | |||
| Midrange is 32768. | |||
| """ | |||
| if volt < self.min_val or volt >= self.max_val: | |||
There was a problem hiding this comment.
Is this >= on purpose? Without looking at the implementation, as a user I would interpret max_val as the maximally allowed value....
There was a problem hiding this comment.
It is on purpose, but I agree that it is not too fitting.
The thing is that min_val maps to 0 and max_val maps to 2**16. So that's one value too many. But I think that current technology can solve even this.
|
I would like to merge this but can we add the checks back to ensure that off by one does not give an overflow? |
|
@jenshnielsen Yes, I'll do that today. |
|
There we go. This issue is really a good case for having a simulated instrument so that we may have a test for such safety measures. |
Author: William H.P. Nielsen <whpn@mailbox.org>
driver/make Decadac verbosely fail for out-of-range voltages (#857)
|
If I understand #904 correctly, the code we just merged is wrong! |
|
No more than before I would say? |
|
No, not more than before, but still dangerous. |
It is very dangerous to have instrument drivers silently fail you when you ask them to do stupid things. If I ask the Decadac to output 1000 V on one channel, it is highly unlikely that I actually meant "go to the end of your range ASAP", and rather, I should be informed that I am trying to do something wrong.
This PR protects the Decadac against "out of range attacks". I hope that I found the right place in the driver to implement the safety precaution.
Changes proposed in this pull request:
ValueErrorif asked to set an out-of-range voltage.@jenshnielsen @spauka