Provide values for Bed Level Correction in Prusa MK2/3 #242
Comments
|
Sorry, don't use prusa. Thre correction adjustment view in the newer version though does give adjustment screw angles in degrees, is that what you mean? |
Do you have a link or docs that explain how this process works? |
|
Here are the official docs on what I am suggesting: I'm pretty sure that the mesh values can be used to calculate these calculation values. I personally use a Prusa i3 MK2 with v3.0.12 firmware. Some other links that may be useful: The above were googled from "Prusa Bed Level Correct" |
ayourk
changed the title
|
This issue has been automatically marked as stale because it has not had activity in 14 days. It will be closed if no further activity occurs in 7 days. |
|
Bump |
|
lol there are other bugs/requests ahead of you. |
|
I forgot to comment because of the stale tag, that's what the bump was for. |
|
No worries, I had already tagged the enhancement label, which removes the stale... |
|
Have you guys seen the Prusa Leveling Guide plugin? I ran across this over the weekend and seems to fit your exact needs. |
|
It appears to be more for the MK3 users than the MK2 users. |
|
The prusalevelinguide is only valid from mk3 onwards with the Nylock mod. |
|
Understood. Would make more sense for the other plugin IMO to incorporate this since it's prusa specific mod but I will keep this feature request on the list. |
|
Do you think this would work in your situation for getting those numbers or is there some other math involved other than just the screw turns?
|
|
The value that is calculated is more quadrant based and is expressed in Z-axis nozzle height in microns. |
|
After going back and looking at the Thingiverse link, I think I need to clarify the feature request. Did you want to add the whole process of printing the piece, taking the measurements and enter those values or purely base the values off of the measured probe points like described below @ayourk? Given the following set of mesh points.
I'm calculating the average of each of the back_half_avg:-0.0003200000000000036 I would think that those numbers would be multiplied by 1000 for the micrometer value? Resulting in the following rounded numbers. back [um]: 0 Does that seem right or should the values be inverted? |
|
That pretty much is what I'm looking for. Front = front edge of the Y-axis=0; X-axis=0 along the left side. But there is a small catch. Some versions of the firmware need that value either halved or doubled (I can't remember). The 0.0000 value is considered the be the exact center of the bed. The help article near the beginning of this issue mentions this. |
|
Ok, so the math logic in theory is sound and doesn't need to be inverted? If so it's just a matter of including a multiplier option for different firmware versions. |
|
Positive values mean the nozzle needs to be moved farther away from the bed. Negative values means that the nozzle needs to be moved closer to the bed (as per the article). I guess I'll have to test the new changes to see how it compares to my printer. |
|
I'll try to integrate the math into the plugin and upload tomorrow. I'm a little concerned the orientations of front and left might be wrong based on your description. Seems rotated to the way the mesh is reported. |
|
This sounds promising! I will test right away when available! |
|
Ok, just for some quick tests I've gotten the math integrated and writing out the corrections into the developer console of the browser. I can work on integrating the information in the UI once we know this is working right. If you want to give it a test for me you can use the URL below in Plugin Manager > Get More > ...from URL and click the Install button. Let me know how off it is and hopefully it doesn't damage your bed/nozzle. https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/archive/0.1.15.zip |
|
Were any of you able to validate the numbers I was getting in the developer console for these corrections? |
fix axis label colors, resolves #278 make colorscale limits allow option auto for the old method of coloring, resolves #275 add responsive option to plotly config, resolves #274 first stab at SD card support, resolves #223 fix little issue with reactive option where graph was getting overlaid on top of correction table change home button press to a different strategy, resolves #265 update plotly to version 1.54.7 add option to download snapshots on graph rendering completion, #239 remove custom home button in preference of resetCameraLastSave3d, resolves #265 numpy versioning for possible better install times, at least in python3 add initial prusa bed correction calculations for testing in #242 fix array reference fix repetier bug introduced in last update fix x axis flip issue, resolves #185 update sponsors add plugin conflict notice to known issues for Custom Control and System Command Editors added axis zeroline colors
fix axis label colors, resolves #278 make colorscale limits allow option auto for the old method of coloring, resolves #275 add responsive option to plotly config, resolves #274 first stab at SD card support, resolves #223 fix little issue with reactive option where graph was getting overlaid on top of correction table change home button press to a different strategy, resolves #265 update plotly to version 1.54.7 add option to download snapshots on graph rendering completion, #239 remove custom home button in preference of resetCameraLastSave3d, resolves #265 numpy versioning for possible better install times, at least in python3 add initial prusa bed correction calculations for testing in #242 fix array reference fix repetier bug introduced in last update fix x axis flip issue, resolves #185 update sponsors add plugin conflict notice to known issues for Custom Control and System Command Editors added axis zeroline colors
|
Hi! Is there any progress update on this feature? Is there any way to help in development and/or testing? I'm a MK2.5S user and would love something like this to work on my machine, was just hacking a solution with the Prusa Level Guide extension when I saw this thread |
|
I don't think the math is quite right, but if you open your browsers developer console you'll see the um values listed out when the mesh is graphed on the console tab. |
|
It should be noted that without setting the center to the origin point and the z offset checkbox to on the values are very off (got >200 while prusa allows for <100 values). After setting both I got results that even could be entered to the machine - which makes sense to me, since I think these values don't apply to the middle (that's how I see it anyway). In any case, after the problem was resolved, I used the values given in the dev console to print this calibration model from Prusa themselves, and it turned out great - one of the best first layers I've ever had on my machine. |
|
Just to confirm, you set use these two options to enabled and the um values actually worked as expected?
|
What firmware version are you using? |
Yes, I used these values and the calibration model went as expected (at least way better than the calibration I tried to do myself).
I have a Prusa i3 MK2.5S with firmware 3.9.3-3556, which is the latest one afaik. |
* add ability to configure graph height in visualization settings, #462 * add min, max, and variance values of graphed mesh, #286 * add OctoDash support, create Custom Action with `[!WEB]http://127.0.0.1:5000/plugin/bedlevelvisualizer/bedlevelvisualizer` as the command. * adjust the tables for better theme support, #479 * add option for showing mesh data on tab, #496 * remove tooltip hover on tables, #490 * add Prusa adjustment values to graph (still needs verification), #242 * add appearance > title setting to automatically downloaded snapshots, #494 * update docs and screenshots, #335, #358, #468
Any chance you could provide the values to use after running your plugin to set in the Mesh Bed Level Correction function of the Prusa firmware?:
Left side [um]?
Right side [um]?
Front side [um]?
Rear side [um]?
The text was updated successfully, but these errors were encountered: