Open jrlomas opened 1 year ago
This is a really interesting approach. What is your experience with it?
However, I am not sure if the approach is sufficient since the offset is already subject to a variance.
And wouldn't it be easier to choose an appropriate z endstop position so that this position plus the configured max. deviation results exactly above the plate? :thinking:
wouldn't it be less complicated and heat generating by doing it like the ercf statistics in a save_variables txt file, since you only want to record the last 10 occurences? doing sql for that purpose is IMHO overkill and maybe an issue for the slower SBCs used as replacement for a pi.
Yes, I think that would be enough.
However, I don't see any real gain. You can limit the deviations in both directions by now (offset_margins). Accordingly, this does not even have to be around the zero point (by using min and max). But even that would not be a problem if you adjust the Z-end stop position accordingly. Or could the restriction to a mean value be made much tighter? Or am I missing something else here?
This plugin adds support for an embedded sqlite3 database that stores historical calibration offsets. It is used to determine if the z offset has varied over 3 standard deviations over the past 10 runs, stopping the print and avoiding destroying one's buildplate. If changing nozzles, the pull request implements a new command RESET_HISTORICAL_OFFSET, as to ignore the historical offset and wait for another 10 runs to start to implement the safeguard.