Marlin: 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

[Wackerbarth]

@BuzzBumbleBee --
A) There is some code. But it was developed against an ancient version of Marlin. I've been tackling other issues, like getting the development branch to work in my environment., before I work on this issue.
One thing that bothers me is that it seems that each developer has been tacking on his own way to address the problems. IMHO, we need to set up a design methodology for the parameterization of the printer rather than having multiple parameters which act at cross purposes.

B) I assume that we need it to handle deltabots. If it doesn't fit in the main firmware, then Marlin is abandoning a significant market segment. I don't want to see that happen.

C) ALL of the parameters that are likely to need adjusting SHOULD be settable by some M-code and also stored in Eprom.

[BuzzBumbleBee]

@Wackerbarth

Fwiw my method is to calculate a delta_diagonal_rod_2 value for each tower (eg delta_diagonal_rod_2_z) using the value from DELTA_DIAGONAL_ROD (or its eeprom value) plus a small trim. This value is then used in calculate_delta for each tower.

For me this allowed me to use DELTA_DIAGONAL_ROD as the JIG length (in my case 162.0) and the trims varied +/- 0.6mm to get the delta calibrated. At the moment my code lacks the m command to read over serial, but the movement of the printer is fine as far as I can tell

Regards

[Wackerbarth]

Yes, I understand what you have done. And I agree that a computation of that nature needs to be performed.

I see two issues:
1) The rod lengths are just part of the parameter space describing a deltabot.
Assuming that the towers are exactly perpendicular to the bed, in addition to the rod lengths, there is the issue of the tower placement, and there is the issue of the placement of the homing switch on each tower. In all, that creates a 9 dimensional space. I suggest that we have compile time constants for the nominal value of each of them and then a "trim" amount that can be set by Mcode (and stored in Eprom)

2) There are multiple coordinate systems which are candidates for the calculations. I'm not sure that the cartesian system is necessarily the fastest. I can think of 3 cylindrical systems that might also work.

[BuzzBumbleBee]

There is already a trim option for the end-stops, you are suggesting the fw need the ability to fine trim delta radius and placement of the towers around that circle (per tower) ?

In any case ill push my changes to my github and send a PR (cant hurt) the code seems to work well and works cleanly with the dev branch

[Wackerbarth]

Yes, I am aware that there are some "trim options" for the end stops. What I am suggesting is that, rather than having different, ad hoc, mechanisms, we need to specify all 9 of these dimensions (and their adjustments) in a unified manner.

[BuzzBumbleBee]

Ah yeah, that would be handy. However the M/G codes used have to follow the structure that set out by machines predating marlin. As far as i know there is no command that allows setting delta machine trims at this complexity

[Wackerbarth]

... there is no command ... -- that means that we can write (or preferably just extend) one.
I suggest that we try to extend the 3-axis model to have 9 axes. the "normal" 3 for the positioners, and 6 trim-able "constants" to describe the tower placement and arm lengths.

"Tower placement" is an interesting domain. Nominally, we have a fixed radius for a circle and the towers are 120 degrees apart. But, if you move one of the towers inward (for example if there is a variance in the carriage depth or rail placement), the three points still lie on a circle, but it has a larger radius, its center moves, and the angles change.

An alternate way to look at the tower placement (which I think makes more sense) is to consider instead a polar coordinate system on which the three towers are exactly 120 degrees apart. In this case, moving one of the towers changes the center and radii of each tower. However, I think that the effect is less severe.

This has the advantage that we are describing all 9 parameters as distances.

No matter how we do it, we will want to pre-compute values that feed the distance calculation and have them available in RAM. They change only when we adjust the calibration.

[BuzzBumbleBee]

So just to confirm im on the right track the 9 "axis" are :-

X Y Z endstops
X Y Z delta rod length trim
X Y Z delta radius trim

Or was the last one trim from the 120 degree layout ?

[Wackerbarth]

To avoid confusion, for the purpose of discussion (only), let's use X,Y,Z to describe the position of the extruder nozzle in a cartesian system. The dimensions related to each of the towers will be designates by a numerical index [1,2,3]

Now, I assume that you are familiar with the transform of the kinematics which has the three arms meeting at the point of the nozzle (We subtract the radial components of the effector and the vertical offset of the nozzle) rather than the physical distances. I refer to dimensions related to that space.

We choose a cylindrical coordinate system such that, if every thing was exactly to "factory design", The towers would be located at some radius "R", and the top of the arms would be at height "H". The nozzle would then be at a height "Z" determined by (H-Z)^2 + R^2 = L^2 where L is the length of the arm.

But, from the nominal values, we will "trim" each, replacing H with (H+h1), R with (R+r1), and L with (L+l1), and similarly for towers 2 and 3.

Note that the coordinate system is chosen such that the towers remain at EXACTLY 120 degree placements and in the "neutral" position, the nozzle is EXACTLY centered (R=0). The "trim" values for the three carriages (h1, h2, h3) are chosen to then reflect the distance from that point to the contact point of the corresponding end stop. This value depends on both the location of the switch and the variations in the other dimensions.

[clefranc]

@Wackerbarth Did you have time to take a look at this: https://github.com/clefranc/Marlin/commit/122c608f83d7870d14ff45ae0df75f1f88d065ee

Somewhat related to this issue.

[Wackerbarth]

@clefranc -- Yes, that is a small part of the code. It fails to address trimming each of the 9 variables and I don't like the implied "angularly adjusted" coordinate space.

[BuzzBumbleBee]

@clefranc that code will also not use the eeprom value afaik (at the very least the delta_diagonal_rod set on the fly would have no effect). Its probably cleaner (code / commit wise) to split each set of values (diagonal rod trim / delta radius trim / angular trim) into separate commits

@Wackerbarth i understand the theory of the delta printers enough, however I was unsure if you were talking about trimming the delta radius per tower AND / OR any angular trims for units that don't a perfect 120 / 120 / 120 layout. Bear in mind i am referring to current variables and config settings within marlin for ease

[Wackerbarth]

I am suggesting that we need only handle the model that assumes perfect 120/120/120 spacing with variable radius.

[BuzzBumbleBee]

OK I'm going to refactor my changes to allow changing both diagonal rod trim and delta radius per tower. Via config and M command

[BuzzBumbleBee]

@Wackerbarth here is my initial change

https://github.com/BuzzBumbleBee/Marlin/commit/4724995d965f8b902b7ac132f437ad8b5741861b

I haven't looked at EEPROM yet as that involved changing the layout and breaking compatibility with mainline Marlin

[BuzzBumbleBee]

If anyone in interested in this feature / has feedback I am implementing this here

https://github.com/BuzzBumbleBee/Marlin/tree/Delta-Trim

[clefranc]

@Wackerbarth

I am suggesting that we need only handle the model that assumes perfect 120/120/120 spacing with variable radius.

My tower spacing is not perfect, one of my tower is 1° off. My rod length are not perfect too, there is millimeters variance. I can't adjust the towers placement, nor the arms length and I'm not going to disassemble the printer to fix these. The only adjustment I have is the endstops height (I'm lucky).

Since there is already calculations in Marlin for tower angles, why not include them in the EEPROM?

Code from actual development branch:

#ifdef DELTA
  float delta[3] = { 0 };
  #define SIN_60 0.8660254037844386
  #define COS_60 0.5
  float endstop_adj[3] = { 0 };
  // these are the default values, can be overriden with M665
  float delta_radius = DELTA_RADIUS;
  float delta_tower1_x = -SIN_60 * delta_radius; // front left tower
  float delta_tower1_y = -COS_60 * delta_radius;     
  float delta_tower2_x =  SIN_60 * delta_radius; // front right tower
  float delta_tower2_y = -COS_60 * delta_radius;     
  float delta_tower3_x = 0;                      // back middle tower
  float delta_tower3_y = delta_radius;
  float delta_diagonal_rod = DELTA_DIAGONAL_ROD;
  float delta_diagonal_rod_2 = sq(delta_diagonal_rod);
  float delta_segments_per_second = DELTA_SEGMENTS_PER_SECOND;
  #ifdef ENABLE_AUTO_BED_LEVELING
    int delta_grid_spacing[2] = { 0, 0 };
    float bed_level[AUTO_BED_LEVELING_GRID_POINTS][AUTO_BED_LEVELING_GRID_POINTS];
  #endif
#else
  static bool home_all_axis = true;
#endif

Perhaps expand M665 or create a new command for all adjustment:

M664 T A L R E S

[Wackerbarth]

You should not provide two sets of parameters which define the same points. Although you can define a coordinate system based on a given radius and variable angles, I believe that the alternate system based on constant angles and variable radii is simpler to handle and likely to give better results. (For example, we know, to any desired precision, the exact sin and cos for 120 degrees. However, we can only approximate it for other nearby angles.

And there is absolutely nothing to be gained by allowing both the angle and the radius to be varied. To do so requires 6 parameters and 3 are sufficient to define the relative tower positions.

Just because someone, at some time, added a particular parameter is not a good reason to perpetuate it.
If existing users need to convert, a simple routine can be built to do the transformations.

[Wackerbarth]

On May 28, 2015, at 1:12 PM, Christian Lefrançois [email protected] wrote:

@Wackerbarth https://github.com/Wackerbarth
I am suggesting that we need only handle the model that assumes perfect 120/120/120 spacing with variable radius.

My tower spacing is not perfect, one of my tower is 1° off. My rod length are not perfect too, there is millimeters variance. I can't adjust the towers placement, nor the arms length and I'm not going to disasemble the printer to fix these. The only adjustment I have is the endstops height (I'm lucky).

I’m not suggesting that you make physical adjustments to the towers. I only assert that you can provide an alternate description of the positions which requires fewer parameters and does not involve angles.

[boelle]

has anyone looked at the link @BuzzBumbleBee posted? could that be used to solve this one?

[BuzzBumbleBee]

@boelle

My branch can currently "trim" the diagonal rod lengths to allow greater accuracy on X/Y dimensions on deltas. I will add in (when i get a free moment this week) the ability to shim the delta radius of each tower.

@Wackerbarth
for angular trimming it would easy to overload the SIN_60 / COS_60 in configuration for wherever needs it.

[Wackerbarth]

I don't think you can simply overload the trig because that would imply a symmetry in the placement of the towers. But, if you are going to choose a placement to that keeps that symmetry, you might as well choose a placement that keeps all of the towers positioned at the proper angle.

[BuzzBumbleBee]

@Wackerbarth fair point ..... the more i think about it the less i like modifying those values.

[BuzzBumbleBee]

Rebased on current Development branch and added per tower radius trim
https://github.com/BuzzBumbleBee/Marlin/tree/Delta-Trim

[boelle]

can you submit a PR also? it will prob last a while before we merge though

Den onsdag den 3. juni 2015 skrev BuzzBumbleBee [email protected]:

Rebased on current Development branch and added per tower radius trim
https://github.com/BuzzBumbleBee/Marlin/tree/Delta-Trim

—
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/2159#issuecomment-108265497
.

[Wackerbarth]

@BuzzBumbleBee -- Please post this as a pull request against the BuzzBase Branch of my repository.
We can work on it there since this repository is slow to incorporate changes of this nature.

[BuzzBumbleBee]

pull request sent to both :+1:

[superlou]

Is anyone still working towards this?

[thinkyhead]

@superlou Currently we have…

/**
 * M665: Set delta configurations
 *
 *    L = diagonal rod
 *    R = delta radius
 *    S = segments per second
 *    A = Alpha (Tower 1) diagonal rod trim
 *    B = Beta (Tower 2) diagonal rod trim
 *    C = Gamma (Tower 3) diagonal rod trim
 */
inline void gcode_M665() {
  if (code_seen('L')) delta_diagonal_rod = code_value();
  if (code_seen('R')) delta_radius = code_value();
  if (code_seen('S')) delta_segments_per_second = code_value();
  if (code_seen('A')) delta_diagonal_rod_trim_tower_1 = code_value();
  if (code_seen('B')) delta_diagonal_rod_trim_tower_2 = code_value();
  if (code_seen('C')) delta_diagonal_rod_trim_tower_3 = code_value();
  recalc_delta_settings(delta_radius, delta_diagonal_rod);
}

[superlou]

@thinkyhead That looks really helpful, but I'm not sure how to set those? The code is in Marlin/Marlin_main.cpp, but is there a way to configure those values in configuration.h? Are they only settable by sending the M665 code?

[Roxy-3D]

In Marlin_Main.cpp, the following delta configuration numbers are used:

  float delta_radius = DELTA_RADIUS;
  float delta_tower1_x = -SIN_60 * (delta_radius + DELTA_RADIUS_TRIM_TOWER_1); // front left tower
  float delta_tower1_y = -COS_60 * (delta_radius + DELTA_RADIUS_TRIM_TOWER_1);
  float delta_tower2_x =  SIN_60 * (delta_radius + DELTA_RADIUS_TRIM_TOWER_2); // front right tower
  float delta_tower2_y = -COS_60 * (delta_radius + DELTA_RADIUS_TRIM_TOWER_2);
  float delta_tower3_x = 0;                                                    // back middle tower
  float delta_tower3_y = (delta_radius + DELTA_RADIUS_TRIM_TOWER_3);
  float delta_diagonal_rod = DELTA_DIAGONAL_ROD;
  float delta_diagonal_rod_trim_tower_1 = DELTA_DIAGONAL_ROD_TRIM_TOWER_1;
  float delta_diagonal_rod_trim_tower_2 = DELTA_DIAGONAL_ROD_TRIM_TOWER_2;
  float delta_diagonal_rod_trim_tower_3 = DELTA_DIAGONAL_ROD_TRIM_TOWER_3;

You can set these in your source code and then you don't need to set them in M665. And in fact, by setting them in the source code, you get extra control that is not in M665 yet. You get the ability to control the DELTA_RADIUS_TRIM for each tower.

For some (bad) reason, these values are currently found in Marlin.h and not in Configuration.h

[BuzzBumbleBee]

Sorry for the slow response (have been away from 3D printing a while)

If you look at

https://github.com/MarlinFirmware/Marlin/blob/e8f8a46ef51dcf3045c7270f29868a6174186d18/Marlin/Marlin.h#L279

The DELTA_DIAGONAL_ROD_TRIM_TOWER_* definitions are defaulted there so as not to cause issues with devices that do not define them in their configuration. You can set them in your configuration file (and as long as you have no values stored on eeprom) they should work fine

#define DELTA_DIAGONAL_ROD_TRIM_TOWER_1 1.0
#define DELTA_DIAGONAL_ROD_TRIM_TOWER_2 1.0
#define DELTA_DIAGONAL_ROD_TRIM_TOWER_3 1.0

[superlou]

Thanks for the quick responses! I'm going to try these this evening. I'm assuming the diagonal rod trims assume that each pair of rods is at least matched? I'm going to take apart the system tonight to more accurately measure the rods and hopefully pair them up more closely.

[BuzzBumbleBee]

@superlou

The way i calibrated my printer was to print a 60mm circle 5mm high. Measure the actual dimension (in line with the tower) and calculate the new lengths.

For example across DELTA_DIAGONAL_ROD_TRIM_TOWER_1

Target size = 60mm
Real size = 62mm
Current rod length = 120mm

120 * (60/62) = 116.13

New rod length = 116.13 (120-3.87)

DELTA_DIAGONAL_ROD_TRIM_TOWER_1 = -3.87

Repeat for all towers, you should have pretty much all errors due to rod lengths fixed :)

[superlou]

That sounds like a cool trick. Will give it a shot tonight. My initial problem was leveling the bed by 3 points on a circle (one in line with each tower) and a middle point. I can get all 3 radial points equal, but when I try to correct for bowling/doming differences between the middle and the radial points, the radials would no longer match each other. I had (maybe incorrectly) assumed this had something to do with my rod inaccuracies preventing the corrections from being independent. However, I'm getting a bit off topic from the issue topic. :)

[superlou]

After a bit of futile attempts, I just realized, is this trim functionality only available in the RC and not the latest stable?

[thinkyhead]

Correct. Version 1.0.2-1 doesn't have the complete feature.
We only added the ABC parameters to M665 recently.

[superlou]

Would it be testable using the recent RC5, or should I wait until RC6 lands to make sure I'm giving it a fair shot?

Edit: so I tried the rod trim corrections in RC5. @BuzzBumbleBee, is there any chance either the target-to-real ratio is inverted or the sign is inverted on the trim? My measurements got worse following the given equations, but better (I think, print bottom layer wasn't great) when I inverted the ratio.

[superlou]

@jbrazio Are you planning to remove this feature in future versions, or holding off on further development?

[jbrazio]

I'm not sure if I understood your question fully.. Features present in RCx/RCBugfix will be part of the next stable release (1.1.0), we have no plans to back port features into 1.0.x for instance.

[Roxy-3D]

And there has been talk about people needing Delta Tower Angle Trim. Some people have towers that are positioned a few degrees off of the 120 degree spacing. That would show up first on the MarlinDev side. And almost for sure it would be an addition to the M665's A,B,C and I,J,K (Delta Rod Trim and Delta Radius Trim).

[superlou]

@jbrazio Sounds good. I think I misinterpreted that Feature Requests milestone. Having that in the 1.1.0 release is fine.

@Roxy-3DPrintBoard I wouldn't be opposed to the trim angle, as my towers are a little sloppy. Some of the calibration wizards give corrections for tower angle, so it would be nice to be able to use those easily.

[boelle]

should this not be closed with remark that the feature should be submitted as a PR from the OP ?

[jbrazio]

Submitted as a Pull Request ? PR is for merging code.

[superlou]

I believe the feature's already in and working, though a comment on how to use it with respect to +/- would be helpful.

[boelle]

yep OP should submit a PR with the code needed for the feature

but if its allreadt implemented we can close this one and write some documentation on it instead

[jbrazio]

I believe it's documented on the delta example files if memory is not playing a trick on me.

[boelle]

great we can close this one then

[jbrazio]

No I was wrong, there is absolutely no documentation about this anywhere, @BuzzBumbleBee did the implementation but no documentation.

[boelle]

heheh then we have a new requirement for PR's... features also need to be documented :-P

[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.