-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warning on negative delay in IVVI driver #44
Comments
I tried suppressing them a bit in my current experiment but a snippet of the form below does not work. Presumably because it is comming from logging.warning (qcodes.utils.helpers line 85) and not from warning.warn. If anyone knows the equivalent command to suppress a specific warning from logging please let me know. import warnings
with warnings.catch_warnings():
warnings.filterwarnings("ignore")
IVVI.dac1.set(100) |
Ah right - the solution I proposed before was to allow And if you do want to suppress warnings, it looks like you can do (unfortunately doesn't seem that there's a built-in context manager for this...): root_logger = logging.getLogger()
log_level = root_logger.level
root_logger.setLevel(max(log_level, logging.ERROR))
# code to ignore warnings in
root_logger.setLevel(log_level) We should probably start scoping our logging to |
I think having sweep-delay = None is not the desired solution, we definately do want this to be slowed down for chip safety reasons and not vary wildly whenever the software feels like it. I think that changing the scope of the logger is also not the way to solve this. It does make the problem go away but it is not a sustainable solution. I do not want to suppress warnings in general ( I get a lot of useful ones all the time), I only want to suppress this specific warning in when calling this specific command. That's where the with construction is nice, it is just that it does not work here (or I have not found it's equivalent). I think that scoping qcodes error messages is a great idea but also one that requires a bit of thought. I think that for now using the default (and well described) logging levels makes sense. Making a custom logger at some point may give some added value but I think we want to save that for another day(/issue). |
ok... so you want to make sure there's some delay, but you're not comfortable increasing the delay such that it's always limited by software? What about a |
@alexcjohnson , even though that would indeed solve the problem I am not a big fan of adding another parameter looking at how complex the parameter class already is. I would instead opt for either, finding some way to manually suppress the warning, or changing the default behaviour of sweep delay to be what you describe for min_sweep_delay. What do you think? |
I don't think we should make a practice of suppressing warnings, we should code such that they are only emitted when the user should really be warned about something. Even here this could suppress behavior you would consider dangerous (though I guess we should change this so each delay resets the start time): what if the first delay was really long, then after that the delays were all super short but they fit within the accumulated negative delay time. We could do something like make a few different plugin classes that just do setting - the default one |
@AdriaanRol a bit more followup after chatting with @alan-geller - you're saying that the 50ms time it takes to execute one So I think when we're making stepped setters, we should really make it explicit what both the minimum (target) and maximum step times are. In this case I'd imagine something like 30ms and 60ms to allow for some potential speedup to help you without sacrificing safety, while continuing to monitor for glitches. That could be with another argument to |
@alexcjohnson In the future we may also want to be able to change these values as it depends not only on the instrument driver but also on the sample/usage of the instrument. I guess that would be a separate issue but definitely something we want to think about. |
closed by #47 |
@alexcjohnson
As we discussed previously when I was developing the driver for the IVVI I get warnings when setting values on the IVVI rack.
These warnings relate to the fact that it takes more time to set the dac-value than the specified delay.
I see several different solutions to this problem and would like to get input on what should be done
My current preference goes to explicitly going for ignoring the warning. This has obvious drawbacks so I would like some input on what the best course of action is here.
The text was updated successfully, but these errors were encountered: