G30, bed probe repeatability, and bed tilt #59
Replies: 42 comments 1 reply
-
|
Hmm, I was going ask if you'd disabled my dubious probe compensation for your tests, but I see in The culprit could very well be Over the weekend I'll try to get a better understanding of what and why the code does what it does. I was trying to clean up Marlin's probing (and auto-calibration) code but there are many side-effects -- it's quite possible I broke something (or exposed a bug). Hopefully, we'll track it down without too much trouble. In any event, I do want to improve the machine's auto-calibration -- I think it should be able to do a better job. Addressing this issue seems to be good for my cause. |
Beta Was this translation helpful? Give feedback.
-
|
@mulcmu , I think you found the trouble spot. It looks like the Marlin folks did consider the "delta printer" case with My current thinking: With a delta printer though, errors in the conversion from delta to cartesian coordinates in the If this is the case, using I'll do a little more digging and work to make a test build for you. |
Beta Was this translation helpful? Give feedback.
-
Thank you, I appreciate the help. I've attached the test build to this message. Hopefully, it's a good fix. I've not tried this build, so if you encounter any problems, suspect early that I did something wrong. |
Beta Was this translation helpful? Give feedback.
-
|
No issues installing or running the test build. Unfortunately initial results still shows some drift in Z height. Drift was reduced but I also made mechanical and calibration changes after the prior testing was completed to confound results. Second chart shows same sequence of
|
Beta Was this translation helpful? Give feedback.
-
|
Here was the data for
|
Beta Was this translation helpful? Give feedback.
-
|
Here was data for the
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for testing. It is very helpful. There are four other places where the Marlin firmware mucks around with the leveling. One occurs when Marlin is creating a path, directly adjusting the stepper positions -- it looks ok to me. Two others are built into the planner -- adjusting Z in the cartesian coordinates and the code seems to match up with Marlin 2.0. The fourth occurs when enabling and disabling the leveling -- when disabling specifically, there is a similar shortcoming like what was patched previously. I've fixed this probelm in the same way, and attached another test build: mpmd_marlin_1.1.x-2012180644-NOT_FOR_DISTRIBUTION.zip I'm thinking too that the fact that the issue showed up is my doing. Leveling was always turned off for the |
Beta Was this translation helpful? Give feedback.
-
|
The
|
Beta Was this translation helpful? Give feedback.
-
|
Progress, good. Good report, too. Thanks for ruling out the software endstop as a possible suspect. And from your description of the fault, I think we're dealing with the same "safety" feature as in issue #43 that prevents the probe from traveling too far below the bed. The limit is controlled (most of the time) with I suppose, too, that the bilinear mesh correction could be returning bogus or extreme values at the edge or beyond the area of the mesh which would likewise trip the same limit. If this were the case though, I believe we would have seen the issue before these recent changes. Still, I'll look into this possibility. Attached is a test build with mpmd_marlin_1.1.x-2012191649-NOT_FOR_DISTRIBUTION.zip Thanks for testing. It is very helpful. |
Beta Was this translation helpful? Give feedback.
-
|
I still encountered the Error:Probing failed with the latest test build. I made a test file to probe at 54.95, 54.99, 54.999, and 55.0 radius every 15° with output to a text file. No failures at 54.95 but starting at 54.99 they started to occur. There are a few
119r08 was the first revision I installed. I recall encountering the Probe failed error 4 or 5 times in the past several months but wrote that off to random glitch/noise. It never persisted or was routinely encountered. I don't recall if it was at the outer limit or not. I've probably run |
Beta Was this translation helpful? Give feedback.
-
|
I was really hoping, but wishful thinking on my part. Sorry to have wasted your time. I'm back to your original thought that tiny changes to x and y when adjusting z are placing the nozzle position outside of the machine's printable area (as far as Marlin is concerned). It really is the most plausible explanation, and I noticed that the code for cartesian machines includes a little "forgiveness" at the print area limits whereas the delta machine code does not. So I've added a little "wiggle" room in the Marlin functions, I think that this simple patch will do the trick, but it affects some twenty places in the code. Unintended consequences, behavior, and side-effects could be the result. I've attached another test build of the firmware: mpmd_marlin_1.1.x-2012210916-NOT_FOR_DISTRIBUTION.zip Thank you for the help. I really appreciate your testing, keen observations, and assessments. |
Beta Was this translation helpful? Give feedback.
-
|
Latest build resolved the failed |
Beta Was this translation helpful? Give feedback.
-
|
Ah good news. Thank you for seeing this issue through to its resolution. The firmware is genuinely improved as a result. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't printed anything yet but no issues yet with |
Beta Was this translation helpful? Give feedback.
-
|
What, there's hope for the probe compensation? It's a Christmas miracle! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Here is something I put together a few years ago that I used for probe compensation. One factor is that the center point has 3 springs to overcome. Other positions have one or two switch springs, and there is different mechanical advantages where the head probes. Those different forces will bias the mechanics differently. It will show up as a different bed height, even though the bias will be gone during printing. This is one of the reasons I inverted the switch arrangement on my MPMD to remove the bed tilt as a factor and make any motion of the bed break a switch contact. it is not perfect, but 10X better.
|
Beta Was this translation helpful? Give feedback.
-
|
I'll dive into it over the weekend. Sounds very interesting. |
Beta Was this translation helpful? Give feedback.
-
|
I think my assumption that the bed switch and clip forces could be located at the same location is a bit to unrealistic. Looking at @see3d diagrams the BCZ and BSZ reaction will create a moment that doesn't get included. Using F(x):=1/(x-1/8)+8; as the switch/clip force seems to breaks down other assumptions about the bed pivot and the final solution looks way to flat. Green dots are location where displacement is expected to be equal to switch travel.
@see3d also brings up a very problematic point about the platform rigidity and variable amount of force needed to actuate the bed switches causing the mechanism to get biased in different directions. Modeling the nozzle force as a spring could approximate some of this difference. |
Beta Was this translation helpful? Give feedback.
-
|
@mulcmu, I think you're on to something. The pivot point in your "probe axis case" is a neat way to allow for switch positions that are somewhere in between zero and the switch travel distance -- a far better approximation than the switch is at zero or it is a the switch travel distance of the current probe compensation. But as you and @see3d point out above, there's more to the story; that things get complicated as the example expands beyond looking along the tower axis line. [ Please be patient with my trivial grasp of mechanical systems ] I'm thinking that rather than simplify by looking at the tower axis, maybe we just start with a rigid plate, supported at three locations (the bed switches) and "supported" at three other locations (the bed clips) and carrying one load (the nozzle). To simplify things, we pretend that the plate doesn't move to calculate how the load force is distributed to the supports. When the nozzle applies a load force, Fz(x,y), to the plate there is a related, balancing set of forces at the bed switch and bed clip locations. For our purposes, Fz(x,y) will be sufficient to compress at least one of the bed switch springs by the switch travel distance. The set of forces at the supports, then, can be translated to a point [x,y,z] for each support. And the final constraint is that the nozzle position [x,y,z] lies on the same plane as the bed switch at the travel distance and two other support points (bed switch or bed clip). From the plane formed by the three support points, we can determine the nozzle's z coordinate. When the nozzle is positioned inside of all three bed switches, I think the three bed switch positions will form the plane. When the nozzle is outside of the bed switches, I think the positions of two bed switches and one bed clip, or one bed switch and two bed clips will determine the plane. I think the direction of the force at the support signals whether or not it is a candidate point for determining the bed plane. I think this is pretty much your work. I've replaced the "pivot point and similar triangles" constraint with a "points are co-planar" constraint and moved your "forces balance" idea front and center. When calculating how the load (of the nozzle) distributes to the switches and clips, we can state that the forces are all in the z direction by pretending that the bed doesn't tilt. @mulcmu, @see3d, does any of it make sense? @mulcmu, in your original method, was the bed tilt along the tower axis close to what your model predicts? Do you think it could be used to find the true center of the bed? If so, and if the center of the bed is also the center of the towers, then I think it can be exploited to improve the autocalibration. |
Beta Was this translation helpful? Give feedback.
-
|
@aegean-odyssey Looking at the tower axis first was intended as a stepping stone to gain some insight in how the system responds and test out assumptions before generalizing to the rest of the bed. The plane equations are one way to get the bed switch points constrained. I also thought that considering the nozzle location in polar co-ordinates would allow a similar slice to be taken to keep the problem in 2D. The work for the tower axis case could just then be modified to account for the switch distances shifting. I don't think the bed always tilts perpendicular to the nozzle so would also need some equilibrium equations perpendicular to the nozzle radius. (This is implicit in the tower axis case to get F_a = F=b) I think the plane approach is more straight forward. The generalize solution for the whole bed should also give the same solution as the tower axis to increase confidence in the results. I'm not grasping or understating the rationale for keeping bed level. The magnitude of the bed switch forces is proportional to the bed displacement (Hooke's law). So the equation for the bed plane (switch displacements) and the force equilibrium equations are intertwined. In my post above, I left out the spring rate because we don't care about the units of the force and treat all the forces relative to each other. This was rational behind assuming the bed clips are much much stiffer (100x) the bed switch. This was attempting to impose a force representative of the bed clip constraint that would keep the bed from lifting off one of the switches. [Not a great explanation, let me know what doesn't make sense and I can try to clarify.]
[Edit to add intended image.] Thinking some more on the generalize problem.... I think we can assume which switch is the one that gets fully depressed by splitting the bed into six regions defined by the tower axis. The bed switch for each axis should be the one fully depressed for the two adjacent 60° sections. As you stated above at some point in this region there will be a transition between supported by bed switches and constrained by the bed clips. The solution for these two adjacent sections should be symmetric as well. |
Beta Was this translation helpful? Give feedback.
-
|
It looks great. I agree: polar (cylindrical) coordinates, a natural, given the symmetry in our problem; general and tower axis models should more or less agree; bed clips modeled as very stiff springs; -- it makes sense. My comment about the bed doesn't tilt was an attempt at a simplifying assumption -- basically so we can consider all of the forces in your drawing, FA...FF, FN as in the Z direction only (i.e. no FxN, FyN, FzN because of the bed tilt) before applying Hook's law. In essence, that the relative distribution of the force of the nozzle to the switches and clips is the same whether the bed tilts or not. I could be way off base here as well. And I suspect that the transition from being supported by a bed switch or constrained by bed clip will show up pretty readily in the math -- I think the direction (sign) of the forces at the switches and clips will be an indication that can dictate which of solutions in the set to apply. |
Beta Was this translation helpful? Give feedback.
-
|
The original issue is resolved, so I'll close the issue here. I'll also move it into the Discussions area so that we can continue with topic. |
Beta Was this translation helpful? Give feedback.
-
|
I refined the 2d tower axis to account for bed switch and bed clip forces separately. The transition between the bed switch and bed clip constraints did work out in the math. Physically it represents that the bed clips prevent the pivot point from being located between them. The transition points are marked with red boxes. The bed neutral points are marked with green dots. General shape is pretty close to original in the center, edges become almost linear after the transition.
Still need to get around to looking at axis data without probe compensation and comparing it with the model. The true bed center idea sounds interesting. In addition to the 7 neutral bed probe locations, there should be some closed shape on the bed where the probe result is equal to the switch travel. This could be used to map out the center or potentially a custom G33 pattern. |
Beta Was this translation helpful? Give feedback.
-
|
This really looks like progress! For me, one of the difficulties with the auto-calibration process is that there is no standard, no measurement that can be taken as true. Plus there's the assumption that the rod length (and radius) are identical for the three axes. I think having the actual center point may lead to a way to programmatically "measure" the machine's geometry parameters. I can picture how this would allow the endstops to be set accurately. I'm not sure what it means, though, concerning the relative rod and radius lengths to say "the actual center is at (x,y)". Coupled with understanding how @see3d's rod and radius relationship (from the discussion in #58) comes to be in the math, maybe there is a way to determine the machine's actual geometry parameters. |
Beta Was this translation helpful? Give feedback.
-
|
I have an MP Delta Pro with a Lerdge control board. The mechanics are robust and the rods are magnetic, so it is easy to pull them off and measure them to get an accurate "L" parameter. Much like MPMD Marlin, I was able to match lengths (though not adjustable like the MPMD), and then input the difference for the L in each tower. After that, the FW takes 3 points along the C axis (Z on MPMD), inside, center, and outside. It also takes 3 points halfway between the C and A axis. It uses these to determine the "R" value. I am sure it is just calculating the value to flatten the bowl/cup. I do not know the details of the algorithm (closed source), but the XY accuracy of the printer is very good after that. With the MPMD mechanics, the measured arm lengths never worked out to give an accurate XY accuracy. I never understood why, but by using my alignment method, I could find some combination of LR that gave the best XY accuracy and then adjusting both LR in ratio to each other to flatten the bowl/cup. There has to be something odd about the MPMD mechanics that make the arm measurements not an accurate way of finding the actual L value. Now I am wondering if there is some constant offset between the MPMD measured arm length and the ideal L that is calculated for the best LR alignment values. That would take some of the mystery out of the process. |
Beta Was this translation helpful? Give feedback.
-
|
I've been looking at @dc42's work in the delta calibration in the /Duet3D/RepRapFirmware repository -- a very well-organized project and beautiful, well-written code. I suspect the Lerge board uses a method similar to @dc42's work. I thought about replacing Marlin's My quick tests left me bothered by the same discrepancy you mention:
I wonder if the automatic endstop corrections are truly "correct"? That maybe the offset you mention is related to the fact the computed endstop locations are not the "real" endstop locations. You've eliminated most other variations in the printer geometry, there's not much left to suspect. |
Beta Was this translation helpful? Give feedback.
-
|
A while ago I had adjusted the factory end stop location based to try to zero the computed endstop locations. This entailed using magnets to hold an allen wrench in place to mark the current end stop location and using shims to get the desired adjustment. I only changed X & Z. The Y tower has the cables tucked away making any controlled adjustment difficult. After a few iterations of this, new computed endstop values were better but not great. A few post back I posted a graph showing computed endstop values from the auto calibration for different values of L. Values were consistent withing the range tested, which was centered about measured rod L value. Recently I set out to undue this prior tinkering. Two machinist 1x2x3 blocks were stacked up with a 100x70mm square and a magnet to hold it cantilevered in place. This allowed setting all the endstop PCBs to the same height off of the bed. Y was still hard to measure/adjust with the cable cover in the way. After the adjustment, the computed endstop values have equalized and been pretty consistent (-.1, 0, 0). |
Beta Was this translation helpful? Give feedback.
-
|
I had started down the path of revising the axis analysis to include some amount of preload from the bed clips pushing down the switches. The math got messy kind of quick, so I switched to numerical analysis. First 3 figures show nozzle displacement to activate switch without any preload, second 3 show with arbitrary preload of 2 units. The deep ridges on far side of the towers could be contributing to the automatic calibration issues, huge change in measured Z value for small X, Y deviations. Next step was to empirically set value for preload based on some data. Should be able to see when the transition near center when bed clips start to remain in contact.... Without Preload With Preload |
Beta Was this translation helpful? Give feedback.
-
|
This is really interesting. On the machine here, the first layer seems to reflect your "without preload" analysis only a bit skewed. I've been thinking that this was due to errors in the calibrated geometry of the machine (arm lengths, endstops, etc.), but maybe it's an artifact from bed switch all along. Hmm |
Beta Was this translation helpful? Give feedback.
-
|
Finished testing to determine a rough value for the preload ratio (.275). Using a test indicator setup on a bed clip and probing the opposite tower axis from the center outward shows radial distance from center where bed transitions from depressing all 3 switches to being restrained by the clip. 2nd plot shows the relative nozzle force. The opposite tower axis have the highest forces which would result in extra measured travel when probed. I haven't observed this opposite tower crevice in any of my bed level probes.
|
Beta Was this translation helpful? Give feedback.
-
|
Interesting, interesting! This looks like something to work into the probe compensation -- your model is much more "evolved" than the current model. |
Beta Was this translation helpful? Give feedback.
-
Currently running
mpmd_marlin_1.1.x-119r14-SM0001-ACfan-10AlimitI was testing repeatability of bed probing by running a gcode file that probes center, tower points and opposite tower points at 50 and 25 mm radius (13 points total). This cycle of 13 points repeated 10 times. Plotting the resulting data reveled the Z height drifting downwards:I checked belt tension and bed clips adjustment, lubricated everything, bed heated and unheated. Same trend was observed, downward drift was very consistent between trials. More testing was completed to rule out stepper motor skipping steps such as changing speed (same drift), running the same pattern but only probing the center point, (In this case center point returned consistent probe value), repeated probing same points, and tested other patterns.
I found probing of repeating patterns that caused reported Z height to both drift downward and drift upward G30_TEST.TXT
do_probe_moveinMarlin_main.cppcallsset_current_from_steppers_for_axis(Z_AXIS);I didn't dig any deeper but, this looks suspiciously like Cartesian printer specific and would cause shift in Z height.Beta Was this translation helpful? Give feedback.
All reactions