(!)Fix screws_tilt_calculate tool

Hello! :handshake:
I’ve tried something on my Reborn 1 printer and got good test results :head_shaking_vertically:
I was 3 years old with the problem that the Screws_tilt_calculate tool did not correctly recommend twisting the tables of the table !!.
The main pain arose when trying to use the old surface map for the new homing. He recommended that he go to the first base point, which itself needs to be adjusted.
You can’t choose any base point at all! :no_entry:
It is necessary to calibrate to the height of the operation Bltouch = Z_Offset. :white_check_mark:
Then the old surface map will always be high -quality on the real surface of the table with an error = error of Bltouch.

For clarity in the figure, I portrayed:
red - “zero plane”,
Green - the height of the Bltouch operation is also Z_Offset,
4 black virtual points measured using Bltouch.

It shows that only point number 3 is near the desired “zero plane”,
And it was proposed to smooth the table to point number 1 (base) = 2.900, which is not right.
It is necessary to smooth on Z_Offset = 2.960.

Here is an example of “old” recommendations for z_offseet = 2.086:
BACK left screw : x=45.0, y=267.5, z=1.94791 : adjust CW 00:00
BACK right screw : x=305.0, y=267.5, z=1.96416 : adjust CCW 00:01
FRONT right screw : x=305.0, y=42.5, z=1.93947 : adjust CW 00:01
FRONT left screw (base) : x=45.0, y=42.5, z=1.95260

After my adjustments, now we get the following recommendations:
BACK left screw : x=45.0, y=267.5, z=-0.12715 : adjust CCW 00:11
BACK right screw : x=305.0, y=267.5, z=-0.15778 : adjust CCW 00:14
FRONT right screw : x=305.0, y=42.5, z=-0.14872 : adjust CCW 00:13
FRONT left screw : x=45.0, y=42.5, z=-0.13590 : adjust CCW 00:12

I checked the performance of the method for all homing options:
1- without endstops according to Z_Offset Bltouch;
2 - “hybrid homing” on endstops and then screws_tilt_calculate and then a surface map.

“Hybrid Homing” smooths all 4 important planes relative to each other:
4. Portal XY ( -)
3.
Table surface map (relative to the tables of the table at the 2nd stage)
2. Physical plane of glass (according to screWs_tilt_calculate and table screws)
1 steel table frame (on endstops)

Screws_tilt_calculate issues recommendations for all 4 tables of the table independently!

If you do homing by Z_Offset Bltouch, then only planes of 2.3.4 are aligned,
And the table frame remains distorted and presses on the mechanics of the table sliding.

I wish everyone a pleasant daily use of the improved instrument. :grinning_face:

Hello @bUilder !

Please in English language.

Are you sure you have chosen the correct sub-forum?

1 Like

I’m not sure that I understand what you are proposing.
The idea behind SCREWS_TILT_CALCULATE is as follows:

  1. The first screw is always taken as the “base.” It is defined as the virtual zero point and used as a reference. This is why you will never receive a recommendation for it.
  2. The current value of the base remains unchanged if your probe hits the center of the base screw.
  3. The tool provides recommendations for the other three screws to align them to the height of the base screw.

This means that after processing, all points over the respective screw centers have the same distance relative to the probe’s trigger point. This is exactly the intended outcome.

Yes, you don’t understand, you’re just retelling me what I already know.
I said above that this algorithm is WRONG!
I worked on this issue for 20 hours today!
I checked it on all the homing table options.
Everything works correctly, according to my thoughts.
Read and try to understand, and not stretch what is written to your knowledge.

Don’t think, just take it and try :wink:

I very well understand your approach.

Current approach:

  • The bed surface over the first screw is set as “reference height.”
  • The other screws are adjusted to achieve the same reference height.
  • The z-offset is not taken into account, since it is a constant and has no meaning in this approach.

Your approach:

  • You choose no fixed reference point.
  • Your approach aims to align each screw to the z-offset value.

While it might not be incorrect, my opinion is:

  • The only scenario where this approach might be useful is when combining a fixed z-endstop with the probe-based SCREWS_TILT_CALCULATE.
  • This is a relatively rare approach and offers no real benefits, in my opinion, compared to using the probe to home Z.
  • For the vast majority of users, your approach just increases the number of screws to be aligned without adding any significant value.

Maybe I missed something, though.

1 Like

Your approach: this is a “method of successive approximation” to the level of an incorrect point - these are not logical actions.
And I suggest aiming directly at the z_offset plane,
This plane is parallel to the portal kinematics!!, and the table plane should be aligned with it.

Why do we so carefully calibrate z_offset on a piece of paper or a steel feeler gauge? - And then at the most crucial moment we stop using it?? Why and for what??

I was talking in 1st message about the number of “planes” that should be parallel (ideally).

The steel table frame, if the printer has one, also needs to be aligned so that the table sliding elements do not warp - is this important or not? What do you think?

why is SCREWS_TILT_CALCULATE the most crucial moment? In this step we want to make the bed parallel to the ganrty. If zero plane shifts it doesnt matter, because you do SCREWS_TILT_CALCULATE in calibration and not before starting a new print. You should rehome z after SCREWS_TILT_CALCULATE anyways.

I would argue generating a bed mesh or homing with the probe is the most crucial moment. And in both cases z_offset is taken into account.

As indicated before, I might be missing something. Generally, my understanding is:

  • Everything in a 3D printer is somewhat relative and subject to various sources of error, such as parallelism, perpendicularity, etc. Particularly problematic are twisted or skewed profiles, especially in the X/Y gantry, as they affect the probe/nozzle correlation.
  • The z-offset is also an “arbitrary” but constant value that describes the distance between the probe’s trigger point and the nozzle tip. As such, it is as “valuable” (accurate or less so) as the probe’s trigger point itself.

Standard Use Case:

The probe is used to home z, perform SCREWS_TILT_CALCULATE, bed-meshing, etc.

  • With the current approach, SCREWS_TILT_CALCULATE levels all screws relative to the “reference screw” and the probe’s trigger point.
  • After doing so, subsequent z-homing ensures that the z-offset is properly applied, resulting in a consistent system.

==> In my opinion, there is no added value in adjusting four screws instead of just three to use the z-offset right from the beginning.


Rare Case:

The probe is only used for SCREWS_TILT_CALCULATE, bed-meshing, etc., while z-homing is done via a separate microswitch endstop.

  • With the current approach, SCREWS_TILT_CALCULATE levels all screws relative to the “reference screw” and the probe’s trigger point (as mentioned above).
  • Subsequent Z-homing does not consider the probe’s Z-offset.

==> The effective bed surface becomes “detached” from the nozzle’s tip, leading to unpredictable results. In this scenario, your approach would have its merits.

I cannot see where the current system is an approximation or lacks logic. It has one flaw, as described above, but I would anyway consider this “rare case” as not recommended.

In this case, your first point will automatically be equal to zero always, and the recommendation “00:00” will always be issued for it, everything is as usual.
Nothing new is happening, I was very worried that this method would break after my interventions, but I switched the printer to this mode of operation specifically to test the correctness of the operation. The test showed an excellent result, the first point was with the recommendation 00:00. You will see the console exhaust yourself when you try the corrected tool.

Here!!! I just fixed this version of the work, I understood in 3 years where the error was in the code, and now this version of the work can do everything correctly, with even an advantage over the “Standard Use Case” in that it also aligns the table frame and the sliding mechanism from skewing.

BACK left screw : x=45.0, y=267.5, z=-0.12715 : adjust CCW 00:11
BACK right screw : x=305.0, y=267.5, z=-0.15778 : adjust CCW 00:14
FRONT right screw : x=305.0, y=42.5, z=-0.14872 : adjust CCW 00:13
FRONT left screw : x=45.0, y=42.5, z=-0.13590 : adjust CCW 00:12 <<<<------ !!!

Here are the necessary recommendations for turning the table screws so that everything turns out correctly.

It’s time to try :slight_smile:

And it was precisely because of “this mistake” that they started getting rid of the limit switches on the table frame, because they didn’t understand where the mistake was. :grinning_face_with_smiling_eyes:

As a result, they decided to “cut off the horse’s sore leg instead of curing it” :laughing:

Is that not the same as:

BACK left screw : x=45.0, y=267.5, z=-0.12715 : adjust CW 00:01
BACK right screw : x=305.0, y=267.5, z=-0.15778 : adjust CCW 00:02
FRONT right screw : x=305.0, y=42.5, z=-0.14872 : adjust CCW 00:01
FRONT left screw : x=45.0, y=42.5, z=-0.13590 : adjust CCW 00:00 <<<<------ !!!

?

Those 2 examples that I put in the first message were for “Rare Case:” .
This is where you can see the difference in how much the old code gave an error compared to the corrected code.

Again: This procedure is just for leveling the bed only. Nothing more.
It has nothing to do with the first layer distance for printing.
After the screws_tilt_calculate_procedure, you always do G28 after this to get the correct Z axes distance.

If the Marlin system is implemented the same way as it was in Clipper, then they need to make the same correction.

Marlin is not intended to be a copy of Klipper ore vice versa.

Nobody forces you to do G28 after screws_tilt_calculate_procedure, immediately remove the table map and start the printer to print (this is for your “Standard method”).

For a new print, the procedure is the same: Homing (G28 only the first time), screws_tilt_calculate_procedure, surface map from memory. And no more G28, only for the first homing. In all slicers, remove g28 from the start codes.

I don’t care anyway, Кlipper rules :slight_smile:

:face_with_hand_over_mouth:

It’s Klipper

Fixed it, thanks

1 Like

Honestly, I do.
I do a screws_tilt_calculate only one in a while or after I did some work on the bed.
Otherwise I start every print with a G28.

Why would you do screws_tilt_calculate before every print?

Further, doing screws_tilt_calculate will make your stored bed mesh useless anyways, no matter if its the original code or your suggested changes.

Its just bad practise doint it the way you describe it.
Maybe the documentation needs to be adjusted to make it clear that homing is required and stored meshs are useless after screws_tilt_calculate?

Edit: It even changes the probes z_offset if the bed was tilted and is now parallel to the gantry. So everything else should be calibrated afterwards anyways. The example in the title post is just assuming a best case scenario.