In Optional Settings → Scale and Thickness, it is possible to enter a value using either a decimal point or a comma, for example 1.002001 or 1,002001, and then click Save. In this case, the system:
does not show an error;
does not convert a comma to a decimal point;
does not convert a decimal point to a comma.
However, values in the configuration file are always stored using a decimal point:
Maslow_Scale_X: 1.002001 Maslow_Scale_Y: 1.003001
The value 1.002001 can be entered in Optional Settings → Scale and Thickness, and it is saved with six decimal places.
However, only three decimal places are displayed in FluidNC Settings:
1.002
When adjusting the value using the arrow controls, only three decimal places are available as well. Additionally, a comma is inserted automatically when editing the value with the arrows.
Proposed solution
Numeric values should be handled consistently across all parts of the software:
Allow input only with a decimal point (.).
Use one consistent number format in the user interface.
Validate the entered value and show an error if the format is invalid.
Keep the same behavior in the YAML configuration file, Optional Settings, and FluidNC Settings.
It would also be useful to define one consistent precision format. For scale parameters, three decimal places may be sufficient: 1.002 1.003
Over a 2-meter distance, the difference between scale values 1.002 and 1.003 is approximately 1 mm. Therefore, three decimal places may be sufficient for practical CNC use, unless higher precision is required by the machine mechanics or the calibration algorithm.
Hello.
I updated the firmware from your repository, which can be found here
I recorded a video, but unfortunately, the problem hasn’t been resolved.
Basically, this bug doesn’t interfere with the software’s operation, but it’s still a bug.
You can watch it here.
That is super interesting, good catch! I’m not able to replicate it but I believe that is because it is language specific. My browser is setting the . at the divider instead of a ,.
It seems to me like the real solution is to remove the up and down arrows from those input fields. I don’t think that those are numbers we want to be incrementing by arrow usually anyway
I think this is a good solution that doesn’t require any major changes to the code.
We also need to limit the number of decimal places that can be entered.
I’ve also seen some forum posts where people are having trouble understanding how to scale correctly; often, when users cut out squares or circles, the shapes end up squashed, and they don’t understand how to apply scaling properly.
I¢ve also seen some forum posts where people are having trouble understanding
how to scale correctly; often, when users cut out squares or circles, the
shapes end up squashed, and they don¢t understand how to apply scaling
properly.
the scaling factors do not fully correct distortions for circles and squares.
that is usually a matter of the anchor locations or flexing.
The problem is that the errors from bad anchor locations are not nice and linear
in ways that the scaling can fix across the entire workpiece, they are curves
that change the error (and even direction of error) in different parts of the
work area. tweaking the scaling factor can get your one piece to work well, but
if you were to cut that same piece in a different place, you would have
different results.
I’m not saying that scaling factors are worthless (there are people who use them
and are happy with the results), just that they are a (useful) hack, not a real
solution.
