Delta : Per tower rod trim

[BuzzBumbleBee]

Hello all,

I have implemented some trim process for each tower in regards to diagonal rod lengths locally, and i have a few questions.

A) Was i blind and there is already a function for this in the development branch ?

B) Would a feature like this be wanted in the main firmware ?

C) If so would a M command be needed for this or would configuration based be ok ?

The reason I decided to try and trim my diagonal rod lengths in FW was even tho I created the rods on a JIG there was still slight oval to the prints (between 0.4 and 0.8mm error over 50mm on all towers). With the trim process I have added i am now less than 0.2mm error on all towers (the rest i can put down to how the filament settles)

Cheers

[BuzzBumbleBee]

@boelle / @jbrazio (not much of a reason) but when I first made these patches there was no where stable or open to document the use of this. And i was told it wasnt a key feature as a totaly new layout to marlin was on its way (split into a library) and it would have needed re implementation :\

[tkurbad]

@BuzzBumbleBee

Are you sure it works the way you propose:

120 * (60/62) = 116.13

New rod length = 116.13 (120-3.87)

DELTA_DIAGONAL_ROD_TRIM_TOWER_1 = -3.87

For my printer, I had to use a positive value to make the print smaller and a negative to get a larger print. Or, to put it in other words: The smaller the real DELTA_DIAGONAL_ROD_LENGTH compared to the value in the firmware, the larger the print and vice versa.

Or am I completely wrong here?

[superlou]

@tkurbad I also ran into this, but I'm not sure if it was an issue of sign or inverted ratios per my comment here.

[tkurbad]

@superlou I think, the ratio is right. It would be sth. like:

configured rod length / printed size = real rod length / targeted size

Thus,

real rod length = configured rod length * targeted size / printed size

I rather think, the conclusion on what sign the trim gets is wrong. To get the trim, you'd have to solve the formula:

trim = configured rod length - real rod length
trim = configured rod length - (configured rod length * targeted size / printed size)

For the example @BuzzBumbleBee was giving, this would be:

trim = 120 - (120 * 60 / 62)
trim = 3.87

It's also easy to see that trim would be negative as soon as the printed size becomes smaller than the targeted size.

Best, Torsten

[superlou]

@tkurbad That makes sense to me. I didn't know if the kinematics held that proportionality or if the diagonal measurement itself couldn't be used as a correction factor that directly and it was more of an iterative process. At the time I was hoping to get the author to weight in so we could have something concrete enough to make some documentation for it.

Edit: confusing myself, but it wouldn't be configured_rod_length / targeted_size = real_rod_length / printed_size to get [configured length / configured size] = [real length / real size]?

[tkurbad]

@superlou

[configured length / configured size] = [real length / real size]

Yes, you are right!

[tkurbad]

So, for @BuzzBumbleBee's example, I think it would be;

trim = (120 * 62 / 60) - 120 = 4

[ajvdw]

Maybe a bit off topic: I've been playing around with manual calibration to overcome inaccuracies of a Delta setup in a fork (github.com/ajvdw/Marlin). I've divided the circular bed in 6 segments, each 60 degrees. If you do a manual calibration (current software) you can probe 3 points+center. I've extended that to 6. The probed offsets are entered in the configuation.h. These 7 points define 6 planes. While printing I calculate which plane to use. The x,y are used to calculate the offset of z (it's very efficient compared to mesh_bed_leveling).

I'm very happy with the results so far.... May you use this idea. I call it DELTA_PLANE_LEVELING

[jbrazio]

@BuzzBumbleBee Do you mind building a small documentation block and adding those features commented into Configuration.h for all the delta's example file ?

We have this bad thing that delta specific defines are not present in our main default config, let's keep the bad habit for now until the folder "refactorization" happens.

[robustini]

Imho this method doesn't work well, doesn't consider important factors in a cartesian system. When measuring for example the diameter of a circle in the directions of the three towers and you go to apply the formula to find the trim is not considered that when applying a correction has gone out to also affect the other two towers. Try to print a fairly large square and enter a trim "10" in one of the towers, you will see the result of the distortion. The measures they would like made from the center, then measure the radius, and even considering the differences of the two radius that make up the same diameter. I made repeated calibration tests for trim my rod on a Delta that has "perfect mechanical" and have never managed to get decent results. For example i print a 120mm circle, the diameter is perfect measured in the X / Y / Z, then i print a square and i've strange result in all the side, like a distorted trapezoid. i speak of differences of less than 1 mm. Most of users don't look at these things because they haven't produced object in perfect size.

[Roxy-3D]

For example i print a 120mm circle, the diameter is perfect measured in the X / Y / Z, then i print a square and i've strange result in all the side, like a distorted trapezoid. i speak of differences of less than 1 mm. Most of users don't look at these things because they haven't produced object in perfect size.

In the devel-UBL branch there is a Delta Physical Bed Calibration tool. (G25) I'm not sure if it still works on Delta's because it was written and debugged before all of the probe changes. I'll get it checked out and going again as soon as I get my Delta back together. In that branch, the M665 has been extended to allow Delta Radius Trim for each tower. IMHO it is necessary to be able to trim both radius and rod numbers on each tower.

[robustini]

@Roxy-3D, interesting, but where i can found a minimum of documentation about "G25"? I can do a tester of this branch ...

[Roxy-3D]

@Roxy-3D, interesting, but where i can found a minimum of documentation about "G25"? I can do a tester of this branch ...

Look at the front end of the code. The options are clearly documented. Eventually, the Documentation Team will have stand alone documents for all of our stuff. But for right now, the code is the ultimate documentation.

// G25 3-Point Supported Bed Adjustment
//
// This function greatly helps in physically leveling a bed supported at its perimeter by 3 points.
// There are several modes of operation.  The function defaults to C-ircular if no other probing option
// is specified.  Suggested usage is to use the C option ignoring the outer circle numbers.  Then use
// the L option to get the DELTA_RADIUS closer and then fine tune the C option's outer circle numbers.
//
// C -  Circular Probing Operation.  This is primarily useful for measuring the height at the 3 bed support
//  points at uniform distances from the center of the bed.  It will probe 3 points
//  along the perimeter of a circle.  The operation will default to 3 circles with the outer most circle at
//  DELTA_PROBEABLE_RADIUS if no radius is specified.   The positioning of the 3 bed support points is
//  assumed to be halfway between each tower unless an angular offset is given using the T option.  A number
//  can follow the C command and will specify the number of circles to probe.  If no number is provided the
//  command will default to 3 circles with the outer most circle at the defaulted or specified radius.
//
//  The outer circle numbers are useful because they most closely measure the height of the bed
//  at the mounting points.  However, those numbers should not be as trusted as the inner numbers because
//  Delta printers have positioning inaccuracies that compound as they move further from center.   The
//  inner circles are more useful for accurate leveling.
//
// L -  Radial lines from the far side of the bed through the origin to the Towers.  This is useful to see the
//  slope of the bed straight away from the towers.  But it is especially valuable when trying to get the
//  DELTA_RADIUS number set accurately.  The command assumes the back tower is straight back.
//
// D -  Displace Probe.  Aligns lines of sampled points to the 1st nozzle instead of to the probe offset.
//  This will displace the Z-Probe from the radial lines such that the nozzle tracks the radial line.  This
//  will result in the diagonal rods being straight out from the tower that is having a radial line probed to
//  it.
//
// O -  Set the origin on the bed if not at the bed's center. [CURRENTLY NOT IMPLEMENTED.  WAITING FOR FEEDBACK]
//
// T -  Set the angular offset for bed mount points and radial lines to the towers.  If the bed support points
//  are not positioned halfway between the towers you will need to consider running the C and L commands
//  seperately with different offsets to get the desired numbers.  T represents the Theta of the back tower.
//  Theta defaults to 90 degrees using an X / Y grid on the printer's bed.
//
// R -  Set the radius for the probing operations.  DELTA_PROBEABLE_RADIUS is used as the maximum radius if
//  no radius is specified.
//
// Example commands:    G25 C           Probe 3 bed mounting points at DELTA_PROBEABLE_RADIUS
//          G25 C 4 T 30 R 80   Probe 3 bed mounting points at a radius of 80mm and
//                      angular displacement of 30 degrees with 4 circles
//          G26 C 2  R 65       Probe 3 bed mounting points at a radius of 65mm with 2 circles
//          G25 L           Probe 3 radial lines going to each tower using a radius of
//                      DELTA_PROBEABLE_RADIUS with 5 points per line
//          G25 L 7         Probe 3 radial lines going to each tower using a radius of
//                      DELTA_PROBEABLE_RADIUS with 7 points per line
//          G25 L 7  R 65       Probe 3 radial lines going to each tower using a radius of
//                      65mm and 7 points per line
//
//
//
//

[robustini]

Adapted for my delta and compiled now, i've this error:

Marlin_main.cpp: In function 'void process_next_command()': Marlin_main.cpp:6414:21: error: 'gcode_G25' was not declared in this scope gcode_G25();

[Roxy-3D]

Did you pull down the entire devel-ubl branch and try to compile it? That branch has not been debugged on Delta's yet. If you want to try to get the G25 code going, you might want to just paste that code into Marlin_main.cpp in RC7 and have the switch() statement call it. It should be close to working, but Delta's are so difficult and temperamental, I'm pretty sure it is going to need some code changes.

I'm working on an issue with mesh_buffer_line() right now for the Cartesian side of UBL. When I get that running the way I want it to behave, I'll probably start getting UBL to work on Delta's. Probably the first thing I'll do is get the G25 code running again. There are two reasons for this. First, I need to re-learn how to make Delta's move in the new system. Especially the probing. G25 will be a nice, isolated environment to do that.

The second reason is I expect UBL to offer a lot of value to Delta platforms. And the better calibrated the Delta is, the easier it will be for UBL to do it's work. So I want to use G25 to help me get my development platform ready for the UBL work.

[robustini]

Ok @Roxy-3D, i wait your fix and then i can test it...

[Roxy-3D]

I'm guessing it will be 2 or 3 weeks until I'm comfortable the Delta version of UBL is ready for Prime Time. But the G25 portion of it will happen first and could be up and running in a week. And the Delta Radius Trim is already in place for the M665 command in that branch. Check back in a week.

[robustini]

To give you an example this is my calibration attempt, i print a circle with 120mm diameter, the measurements:

A 121.0mm B 120.5mm C 120.3mm

The correction:

M665 A1.65 B0.82 C0.49

The result after the trim:

A 120.0mm B 120.0mm C 120.0mm

In this condition i print a square with side "100mm", the result:

Upper side: 100.0mm Lower side: 99.8mm Righ side: 99.9mm Left side: 100.4mm

As you can see there's something wrong.

[Roxy-3D]

Those are fairly large 'Trim' numbers. Are your rods really that different from each other? Regardless of your answer, being able to 'Trim' the Delta Radius numbers is going to help you.

[robustini]

I measured my rod with a professional caliber, all are 198mm, perfect.

[Roxy-3D]

OK, so are the pivot points for the rods all symmetrical? It kind of feels to me like you are mis-using the Delta Rod Trim numbers.

So, I'm not an expert on the geometry of Delta's. I understand why you are looking at the symmetry of a square being printed. I have two comments:

First, I'm thinking of 'stealing' your idea of checking the symmetry of a square. Except, I think it is possible we get better results with two triangles super imposed on each other. In one triangle, the points would aim directly at the towers. In the other triangle, the the middle of each line would be as close to a tower as possible. (Both triangles would be as large as practical so the deformations are larger and easier to see.)

The second comment is about G25. It is looking at Z-Height at different locations. Your 'Square' idea is looking at X&Y deformation. I think both are important. I don't know this is true, but I suspect that if you can get the Z-Height deformation very small, the X&Y deformation becomes very small also. G25 is aimed at helping you get the nozzle to travel in a flat line across the bed. But I want to add your X&Y deformation idea to it to make it more complete.

[robustini]

I checked the mechanics several times and it's balanced, I've yet to understand why there's this bias. As I've written above in a Cartesian system if we change one parameter will automatically change the other. Example: if you have a tuned Delta (which no requires trim) and print a circle 120mm diameter with this trim in tower A (X):

M665 A10 B0 C0

The result is:

A - 125mm B - 128mm C - 128mm

Of course the result may vary depending on the configuration of the Delta. We try to increase A but B and C are now even higher compared to A. So to center good calibration trim it must proceed very empirically, because changing a trim in a tower actually going to "virtual change" the trim of the other two towers. This could be a good starting point, that is, change the code to automatically apply this fix, both the compensation ratio should be a constant, it takes someone very grabbed at math but I can confirm.

[Roxy-3D]

This is the code that dials in the Delta calibration numbers. Those numbers are not surprising. You are shifting A by 10.0mm That number is used here:

    delta_diagonal_rod_2_tower_1 = sq(diagonal_rod + delta_diagonal_rod_trim_tower_1);

That number is inside a sqrt() function. So it seems reasonable that shifting the number inside the sqrt() function by 10mm results in a 3mm difference:

  void recalc_delta_settings(float radius, float diagonal_rod) {
    delta_tower1_x = -SIN_60 * (radius + delta_radius_trim_tower_1);  // front left tower
    delta_tower1_y = -COS_60 * (radius + delta_radius_trim_tower_1);
    delta_tower2_x =  SIN_60 * (radius + delta_radius_trim_tower_2);  // front right tower
    delta_tower2_y = -COS_60 * (radius + delta_radius_trim_tower_2);
    delta_tower3_x = 0.0;                                             // back middle tower
    delta_tower3_y = (radius + DELTA_RADIUS_TRIM_TOWER_3);
    delta_diagonal_rod_2_tower_1 = sq(diagonal_rod + delta_diagonal_rod_trim_tower_1);
    delta_diagonal_rod_2_tower_2 = sq(diagonal_rod + delta_diagonal_rod_trim_tower_2);
    delta_diagonal_rod_2_tower_3 = sq(diagonal_rod + delta_diagonal_rod_trim_tower_3);
  }

  void calculate_delta(float cartesian[3]) {

    delta[TOWER_1] = sqrt(delta_diagonal_rod_2_tower_1
                          - sq(delta_tower1_x - cartesian[X_AXIS])
                          - sq(delta_tower1_y - cartesian[Y_AXIS])
                         ) + cartesian[Z_AXIS];
    delta[TOWER_2] = sqrt(delta_diagonal_rod_2_tower_2
                          - sq(delta_tower2_x - cartesian[X_AXIS])
                          - sq(delta_tower2_y - cartesian[Y_AXIS])
                         ) + cartesian[Z_AXIS];
    delta[TOWER_3] = sqrt(delta_diagonal_rod_2_tower_3
                          - sq(delta_tower3_x - cartesian[X_AXIS])
                          - sq(delta_tower3_y - cartesian[Y_AXIS])
                         ) + cartesian[Z_AXIS];
  }

[robustini]

Yeah, i know, but why not create a correction coefficient that takes account of the variation of the other trim? Even when you do contemporary variations of the three trim it should not be impossible for the code to calculate the coefficient of variation also linked to the other. I don't think it's impossible... or not? :D If the code already does in fact wrong imho... :P Correct me if i'm wrong.

[Roxy-3D]

I'm just guessing... But the calculations were setup with towers at a fixed (and even) spacing around the unit circle. And the calculations were also setup with all of the diagonal rods being equal with a symmetrical effector of some constant size at the center.

Allowing someone to trim the radius or rod number for a given tower seems natural. But also remember, these corrections don't address what caused the need for the correction. In the case of diagonal rods, are the rods a different length? Are they connected further in or out on the effector. Is the tower they go to slightly further in or out on the unit circle compared to the other towers. Is one of the towers offset +/- from the 120 degree spacing?

The work was done to let somebody adjust the numbers. But without good answers and rigorous math to guide us, what happens on each of those possibilities I just mentioned above? I don't know. I haven't seen a full report with a suggested course of action.

[boelle]

@jbrazio are you still with us? I wondered if it would be worth the effort of going through the issue list to see what to keep and what to close?

[thinkyhead]

@boelle In the venerable tradition of well-intentioned souls who set up a website for us where they are the only key-holders, then disappear without a trace, I fear that @jbrazio has fallen into the same wormhole as @scotty1024.

Or maybe he's just very busy…?

[boelle]

@thinkyhead it was at some point mentioned that this one was in fact implemented but lacking documentation.

i would argue that it should be closed since its here. documentation can be added when time allows it. if there is time just add a short note in config on how to use it

[superlou]

A short note would be perfect, just so people know the option's there without having to guess and check the source.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.