RepRapFirmware 2.03RC3 available
-
@dc42 said in RepRapFirmware 2.03RC3 available:
I've just released this at https://github.com/dc42/RepRapFirmware/releases/tag/2.03RC3. It includes a bug fix relating to babystepping, bug fixes relating to using workplace coordinates (mostly relevant to CNC machines), and a few minor improvements.
Great to see that it is kept moving. Thank you very much!
-
Thank you for the updates !
Ive been going bat isht crazy with baby stepping since day one with duet - in that I have to restart printer every print and re mesh bed level etc and resett baby stepping because there seems to be a "stacking" of the offset or some division of the gross sized offset between prints ... Can you elaborate a little on what was corrected / changed pertaining to the babystepping or link to the thread where it was discussed ?
Thanks again ...
Sputty
-
@sputnikoc3d Please check out the changelog here
-
@sputnikoc3d said in RepRapFirmware 2.03RC3 available:
Ive been going bat isht crazy with baby stepping since day one with duet - in that I have to restart printer every print and re mesh bed level etc and resett baby stepping because there seems to be a "stacking" of the offset or some division of the gross sized offset between prints ... Can you elaborate a little on what was corrected / changed pertaining to the babystepping or link to the thread where it was discussed ?
I happened to come across this when I was refactoring some code. Most of the time, the firmware converts from user coordinates (the coordinates in the GCode file you are printing) to machine coordinates. As part of this process, it adds the babystepping offsets. But occasionally it has to convert the other way, for example after homing Z. The code was adding the baby stepping offset instead of subtracting it. So if you had a nonzero babystepping offset when you homed Z, I think the effect would be as if you had reversed the sign of the babystepping offset. But I haven't done any tests of this, or a full analysis.
-
Still the same issue with mesh leveling. 2.02 works perfect.
After installing the first 2.03 RC this issue happened.
Every time you do a mesh level the results are different. So first layers are a pain in the but because you have to ajust z offset every time.
This does not happen in 2.02.
-
If I run a "home all" followed by a "run mesh grid compensation", I get results that look really odd (first pic). Sometimes. Other times, the map looks great.
If I run a "Auto Delta Calibrate" followed by a mesh, I get great results. (second pic). And they are consistent (I didn't post pics, run after run looks very similar. Statistically identical). Every time OK. My bed.g was built for 16 points, 8 factors, probing radius: 280, probe offset (0, 0)
-
@danal said in RepRapFirmware 2.03RC3 available:
If I run a "home all" followed by a "run mesh grid compensation", I get results that look really odd (first pic). Sometimes. Other times, the map looks great.
If I run a "Auto Delta Calibrate" followed by a mesh, I get great results. (second pic). And they are consistent (I didn't post pics, run after run looks very similar. Statistically identical). Every time OK. My bed.g was built for 16 points, 8 factors, probing radius: 280, probe offset (0, 0)That indicates that your homed height setting in M665 is wrong. Run auto calibration, then save the new M665 and M666 figures, either manually to config.g if you are not using config-override.g (i.e. you have no M501 command at the end of config.g), or to config-override.g by sending M500 (if you have M501 in config.g).
-
@caveman said in RepRapFirmware 2.03RC3 available:
Still the same issue with mesh leveling. 2.02 works perfect.
After installing the first 2.03 RC this issue happened.
Every time you do a mesh level the results are different. So first layers are a pain in the but because you have to ajust z offset every time.
This does not happen in 2.02.Please provide:
- Your config.g file
- Your homeall.g and homez.g files
- A simple sequence of operations, starting from power up, that reproduces this
- Your bed.g file, it there is a G32 command anywhere in that sequence.
-
https://drive.google.com/open?id=1qOs25jlWivWjFNs0fw0HE-ar4wUmeRQ3
There are no homeall.g and homez.g files on my meastro?
Powerup machine, do a autocalibrate followed by home, then meshbedlevel.
After this it already shows a completly different map than with 2.0.2.Everytime i do a meshbedlevel after that the results are different.
If you need more info or tests done let me know!
Also after installing 2.03 builds i have way more files on my duet?
-
@caveman A Delta doesn't have a x,y, and z, like a cartesian printer.
