Minor bugs in the RepRapFirmware Configuration Tool
-
I have been playing with the RepRapFirmware Configuration Tool today in order to create some templates for a Railcore II, and I have noticed that under Compensation > Bed Compensation: That increasing the Number of probe points to 5 works fine (and decreasing it to 4 again) but decreasing the number of probe points to 3 leaves 4 points on the web interface (and in bed.g, so it needs manual editing afterwards for 3 point levelling)
Secondly: there appears to be a floating point bug with "Max instant speed change". E.g. set results in on E0/E1 of 0.34mm/sec results in config.g containing:-
M566 X1000.2 Y1000.2 Z30 E20.400000000000002:20.400000000000002(I've also seen it with 16.667mm/sec on X and M566 containing X1000.0200000000001 also)
Lastly: I notice that custom configuration section only gets added to the end. The Railcore config uses M584 (to Map Z to drivers 5, 6, 7 at the end) and M671 (for Leadscrew locations) near the start of the config.g . Will this cause any problems with it being placed at the end, after axis and motor configuration?
Or would it be possible to have a "pre" custom configuration in the configurator? -
@cheeseandham said in Minor bugs in the RepRapFirmware Configuration Tool:
M566
M566 accepts values in mm/min, so if you input 0.34mm/sec in the RRF Configuration Tool, 20.4 is what you really do want the have in the resulting M566 command
-
@themelle said in Minor bugs in the RepRapFirmware Configuration Tool:
M566 accepts values in mm/min, so if you input 0.34mm/sec in the RRF Configuration Tool, 20.4 is what you really do want the have in the resulting M566 command
Absolutely, 20.4 is what you want in the M566 command if you type in 0.34mm/sec in the RRF Configuration tool.
I'm not sure you want 20.400000000000002 though?
-
Floating point numbers are ugly. Yeah, you wanted 20.4, and not 20.400000000000002, I'd guess that the numbers are typecast as float, and probably should be typecast as double-precision. Seems like something that happens in python more often than not, and has led me to be in the habit of forcing double-precision any time that I'm expecting non-integer values for anything.
For the 16.667mm/sec, You SHOULD see 1000.02, but chances are you actually wanted a 1000 value, so you were probably expecting to edit that one anyway. (Thank the Babylonians and their fantastic base 60 math.)
I would probably suggest that for anything specified in mm/min, it is probably best to limit to one decimal place, or 3 for mm/s.
-
Also for the Maestro the Microsteppings configuration are not generated.
There is not M350 line generated in the config.g -
Thanks for the notes, I'll fix them soon!
-
I just noticed another bug
The beta value is not correctly written to the config.g file
For example if i select B4388 for bed
and B4138 for E0The resulting config.g contains these lines
M305 P0 T100000 B4725 C0 R4700 ; Set thermistor + ADC parameters for heater 0
M143 H0 S120 ; Set temperature limit for heater 0 to 120C
M305 P1 T100000 B4725 C0 R4700 ; Set thermistor + ADC parameters for heater 1
M143 H1 S280 ; Set temperature limit for heater 1 to 280C -
Thanks for the report, I've just fixed this.
-
OK, so in this new firmware tool, bed.g now calls G29 for mesh bed compensation, and doesn't allow you to set probe points.
So we can't use this new tool for setting bed.g with Bed levelling using multiple independent Z motors as we could with the v1 tool.
Not a complaint, just an observation
, as I guess this setup is in the minority.Thanks for updating it Chris.
-
@cheeseandham That is true, the old bed point compensation is deprecated and it should be replaced by the new mesh bed compensation. Nevertheless the config tool can still generate n-point bed.g macros but to do so you have to select an older firmware version.
I'll add support for multiple independent Z motors soon.
