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
Critical Bug: Use of %f instead of %e for values truncates values #821
Comments
Thanks for raising this issue. If your device is able to understand exponential notation, you can change it there. I'm not sure, that every device understands exponential notation (not even all SCPI ones). Some might truncate at "e" producing undesired results, others might raise an error. Another idea: Maybe we should put a corresponding note into the documentation as well. |
Thanks for raising this! I agree that %g is probably the more sensible default choice. For all instruments where you want to move away from %f, you'll have to check (with a device if available, or in the manual) if the resulting numbers format is accepted by the device. |
@maor1993 AGW401x - is probably this product. |
Let's put a hint in #779 regarding small numbers. |
Thanks for looking up the manuals. Would you mind opening a PR with the changes, @maor1993 ? You do not have to change all instruments possible. It is more important, that devices continue to work (down to 1e-5) than to break at any input. If you're in doubt, whether it will work for a given instrument, leave as is. |
Hey, I've been working with this library for a while using the DSOX1102G I noticed that once I use a value smaller than 1e-6, the scope does not receive it correctly and uses the smallest value possible.
This issue occurs as the python default %f max decimal points is 6:
The more concise solution would be to use %e which is always supported by SCPI devices:
Looking at the repo there are about 19 devices use %f and not %e
This is uncaught by testing as it was never tested for.
The text was updated successfully, but these errors were encountered: