Successive G30 probes shift Z height

[mulcmu]

Currently running mpmd_marlin_1.1.x-119r14-SM0001-ACfan-10Alimit I 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_move in Marlin_main.cpp calls set_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.

[aegean-odyssey]

Hmm, I was going ask if you'd disabled my dubious probe compensation for your tests, but I see in G30_TEST.TXT that indeed you had. So at the moment I am clueless.

The culprit could very well be set_current_from_steppers_for_axis(Z_AXIS); even if not Cartesian printer specific, it does seem that an incremental (or relative) adjustment would compound any existing error in the kinematics.

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.

[aegean-odyssey]

@mulcmu , I think you found the trouble spot. It looks like the Marlin folks did consider the "delta printer" case with set_current_from_steppers_for_axis(Z_AXIS), AND in a perfect world I think the (their) code should work. The next line in the code synchronizes the planner's stepper motor positions from the newly established current cartesian position. All should be good.

My current thinking:

With a delta printer though, errors in the conversion from delta to cartesian coordinates in theset_current_from_steppers_for_axis() function could slightly change the X and Y coordinates as well as the Z coordinate (in theory, X and Y does not change during the probing process). The set_current_from_steppers_for_axis(Z_AXIS) would then loose track of any errors in the X and Y coordinates. Synchronizing the slightly off current position with the planner's position could then alter Z.

If this is the case, using set_current_from_steppers_for_axis(ALL_AXES) should eliminate the slight error. BUT, there seems to be another side-effect related to whether the planner is applying leveling or not, so I'm not entirely convinced of this solution.

I'll do a little more digging and work to make a test build for you.
Thanks for the high quality testing and reporting.

[aegean-odyssey]

mulcmu commented on eb90b41 14 hours ago
I can test this out if you post binary for SM0001-ACfan-10Alimit.

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.

mpmd_marlin_1.1.x-2012170257-NOT_FOR_DISTRIBUTION.zip

[mulcmu]

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 G30 commands but with G28 issued between each probe. Table shows these probes are quite consistent. Gcode and data attached for reference (12-17 cal.zip). I was going to repeat same test with bed leveling cleared and then repeat with mpmd_marlin_1.1.x-119r14-SM0001-ACfan-10Alimit reinstalled. Let me know if you have any other suggestions, I'm happy to help out.

Row Labels	(X)	(Y)	Average of z	StdDev of z
0	0	0	-0.06500	0.00000
1	0	50	0.03500	0.01603
2	-43.301	25	-0.12082	0.00858
3	-43.301	-25	-0.00500	0.00000
4	0	-50	-0.17909	0.01215
5	43.301	-25	-0.04491	0.00841
6	43.301	25	-0.18336	0.00794
7	0	25	0.03000	-
8	-21.651	12.5	-0.03509	0.00841
9	-21.651	-12.5	-0.02200	0.00000
10	0	-25	-0.11045	0.01369
11	21.651	-12.5	-0.07945	0.01320
12	21.651	12.5	-0.05227	0.00888

[mulcmu]

Here was the data for (Dec 17 2020) firmware without any bed leveling data. No drift! Looks like the bed leveling data might be the culprit.

(X)	(Y)	Average of z (No Mesh)	StdDev of z (No Mesh)2
0	0	-0.05364	0.00543
0	50	-0.00409	0.00841
-43.301	25	-0.11336	0.00543
-43.301	-25	0.00645	0.00513
0	-50	-0.09855	0.00513
43.301	-25	0.02600	0.00805
43.301	25	-0.15982	0.00858
0	25	0.01818	0.00940
-21.651	12.5	-0.02864	0.00543
-21.651	-12.5	-0.04500	0.00000
0	-25	-0.08055	0.01119
21.651	-12.5	-0.02918	0.01055
21.651	12.5	-0.03900	0.00000

5025_10X.TXT

5025_10x.csv.txt

[mulcmu]

Here was data for the mpmd_marlin_1.1.x-119r14-SM0001-ACfan-10Alimit with no mesh data. This still had the drift so it looks like the set_current_from_steppers_for_axis(ALL_AXES) is needed as well.

5025_10x r14.txt.csv.txt
5025_10X r14.TXT

[aegean-odyssey]

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 G30 command. Leveling can now be enabled during the command to make it a little more versatile, and in doing so, I exposed (created) some bugs, I think.

[mulcmu]

The (Dec 18 2020) build eliminated the drift with G30 probing with the leveling mesh enabled. This wasn't exactly the same configuration as above testing but pretty close. My data from G30 probes and G33 auto calibrate have been way more consistent with these two fixes in place. I did run into issues with G29 on this build. The probing failed error was consistently encountered for point (-55,0) or point (0, +55) and sometimes at (0,-55) keeping it from getting through /setup_gcode/AUTO_CALIBRATE.gcode. Sending G30 at (±55,0) and (0,±55) manually resulted in intermittent probing failed errors as well. The nozzle lowers, makes contact for the first tap, activates bed switch, and then stops with switch LED still blue. One cause could be the updated planner location ends up being greater than 55.0 and activating the software end stop, but it still happens after M211 S0 to disable software end stops. No probe failure errors were encountered with G30 at (±54.95,0) and (0,±54.95).

Pt	(X)	(Y)	Average of z	StdDev of z	StdDev of q
0	0	0	0.0175	0.0119	0.0119
1	0	50	0.1674	0.0054	0.0054
2	-43.301	25	-0.1371	0.0069	0.0073
3	-43.301	-25	0.1325	0.0051	0.0051
4	0	-50	-0.0291	0.0132	0.0132
5	43.301	-25	0.2024	0.0054	0.0054
6	43.301	25	-0.0541	0.0084	0.0079
7	0	25	0.1176	0.0054	0.0051
8	-21.651	12.5	0.0239	0.0078	0.0078
9	-21.651	-12.5	0.0640	0.0000	0.0000
10	0	-25	0.0200	0.0000	0.0000
11	21.651	-12.5	0.0965	0.0051	0.0051
12	21.651	12.5	0.0771	0.0069	0.0073

[aegean-odyssey]

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 Z_PROBE_LOW_POINT in the Configuration.h file. When Z is unknown (which I don't think happens with this printer), the value is hard-coded at -10mm. I think Z_PROBE_LOW_POINT's -3mm value is right at the cusp and the more accurate Z corrections put the probe past the limit when it tilts the bed at the 55mm radius.

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 Z_PROBE_LOW_POINT set to -5mm:

mpmd_marlin_1.1.x-2012191649-NOT_FOR_DISTRIBUTION.zip

Thanks for testing. It is very helpful.

[mulcmu]

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 echo:endstops hit: messages mixed in as well. The 55.0 radius skipped a bunch of points, they must have been computed outside travel range. M665 ABCDEFXYZ were all set to zero to eliminate any unnecessary calibration trim interference.

G29 L-54 R54 B54 F54 command completed okay with the reduced limits.

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 G29 hundreds of other times previously without issue.

G30 FullTest.gcode.txt
G30_FULL.TXT
SETTINGS.TXT

[aegean-odyssey]

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, position_is_reachable() and position_is_reachable_by_probe(). Now, positions within a radius of 55mm plus and additional 0.3mm will be considered reachable positions.

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.

[mulcmu]

Latest build resolved the failed G30 probes at 55mm radius and G29 completes consistently. I'll give it some runtime and keep an eye out for any side-effects.

[aegean-odyssey]

Ah good news. Thank you for seeing this issue through to its resolution. The firmware is genuinely improved as a result.

[mulcmu]

I haven't printed anything yet but no issues yet with G29 G30 or G33. A few manual G0 commands outside the reachable area have stopped without any crashes. The one side effect I've observed was that my data seems a bit more consistent with the probe compensation enabled. This might be the release that vindicates your probe compensation logic!

[aegean-odyssey]

What, there's hope for the probe compensation? It's a Christmas miracle! 😄

[mulcmu]

Looks to me like there is hope. I've been working to improve dimensional accuracy of my machine; lots of little tweeks and carbon paper tests recently.

With the probe compensation disabled, G33 reported std dev is in .040 to .045 range. With it enabled it gets down to .015 to .010 range consistently.

L CAL.gcode.txt
L_CAL.TXT
L_CAL S128.TXT

Here was some processed data from 10 repeated G29 with and without probe compensation:

(X)	(Y)	Average Z Enabled	StdDev Z Enabled	Average Z Disabled	StdDev Disabled	StdDev Difference
0.0	-55.0	-0.033	0.020	-0.173	0.008	0.012
37.0	-37.0	0.166	0.017	0.213	0.022	-0.005
18.0	-37.0	-0.092	0.009	0.035	0.021	-0.012
0.0	-37.0	-0.050	0.010	-0.087	0.019	-0.009
-18.0	-37.0	-0.085	0.005	0.035	0.009	-0.003
-37.0	-37.0	0.080	0.008	0.110	0.008	0.000
-37.0	-18.0	-0.015	0.000	0.062	0.005	-0.005
-18.0	-18.0	-0.194	0.006	-0.022	0.008	-0.003
0.0	-18.0	-0.169	0.005	-0.107	0.012	-0.007
18.0	-18.0	-0.154	0.012	0.036	0.018	-0.006
37.0	-18.0	-0.027	0.008	0.074	0.022	-0.013
55.0	0.0	-0.092	0.011	-0.052	0.023	-0.012
37.0	0.0	-0.254	0.016	-0.103	0.018	-0.002
18.0	0.0	-0.278	0.014	-0.037	0.021	-0.006
0.0	0.0	-0.053	0.009	-0.044	0.014	-0.005
-18.0	0.0	-0.278	0.000	-0.054	0.014	-0.014
-37.0	0.0	-0.128	0.000	-0.001	0.000	0.000
-55.0	0.0	0.071	0.009	0.103	0.008	0.000
-37.0	18.0	-0.037	0.000	-0.110	0.007	-0.007
-18.0	18.0	-0.272	0.008	-0.061	0.007	0.001
0.0	18.0	-0.192	0.000	0.025	0.012	-0.012
18.0	18.0	-0.184	0.007	0.036	0.017	-0.010
37.0	18.0	0.031	0.010	-0.033	0.017	-0.007
37.0	37.0	-0.029	0.009	0.078	0.018	-0.009
18.0	37.0	-0.075	0.010	0.028	0.017	-0.007
0.0	37.0	-0.112	0.018	-0.008	0.017	0.002
-18.0	37.0	-0.173	0.008	-0.069	0.008	0.000
-37.0	37.0	-0.199	0.000	-0.103	0.010	-0.010
0.0	55.0	0.049	0.015	0.052	0.006	0.009

[mulcmu]

The changes incorporated into release 119r15 have resolved the issue with shifting Z height after probing.

[aegean-odyssey]

Looking over the calibration results in your data -- it looks like you're systematically stepping through diagonal arm length values (M665 L) to find the best fit. Have you made changes to the printer itself to achieve such great (IMO) calibration results?

[mulcmu]

I had been struggling to eliminate some skew with my printer. Measuring across flats of a 20mm calibration hexagon would yield 19.9 to 20.0 for two sets and the last would be 19.5 to 19.6. All of the mechanical tweaks from @PurpleHullPeas calibration guide were completed and lots of carbon paper testing to try to tweak calibration to get rid of the skew. This resulted in a lot of bed probing and ultimately stumbling into the issue with the z height shifting after multiple probes.

With the patched code, my testing was looking at how consistent the G33 auto calibrate end stop offsets and tower angle corrections were for different values of L. The final calibration results are very consistent for M665 X Y Z and M666 X Y Z.

These corrections for the tower angles have eliminated the skew! (I still can't figure out the logic behind bed probing data being able to correct the tower angles.) I measure 119.90 mm for the physical arm length. Interestingly the best reported Std Dev from G33 are right in this range. The bed still has a dome/bowl so looking back at discussion in #25 to try to get that flattened next.

Current machine upgrades:
-Glass with PEI for the bed
-Bed clips adjusted to 0.3mm travel
-Arms all adjusted to same length
-Arms adjusted parallel (see #10) using washers as shims
-Bed shimmed level to rails with bed heated
-Coil spring around bed posts for extra upward force
-Capricorn tubing
-Dual geared extruder

The bed clips were remixed to use threaded inserts for adjustment screw. The clips are held in place with M2.5 screws and threaded inserts to a second piece that installes below bed.

The coil spring is the other non-standard upgrade. Basically an extension spring from assorted kit that fit around the post was cut so it was only one turn long. This provides more holding power to keep bed from shifting when printing but also requires nozzle to press slightly harder into the bed. The cut spring seems to work pretty well but a pain to install. Finding a Belleville spring washer the right size might be an option.

[aegean-odyssey]

You, @PurpleHullPeas, and @see3d have shared great information in this little project. And the work and insights are too good to be buried in closed issues. I hope to start-up a few more on-going topics under the Discussions tab (calibration being one of them) and seed the topics with information that's been collecting in the Issues. I need to get a better handle on how this process can work on Github before "diving in", though.

[see3d]

Great thread guys. For some reason, my notifications got turned off and I am just now seeing this. This G30 probe drift was first noted by me with Marlin4MPMD. We could not figure out where it was coming from. It really limited what I could do for automated calibrations. But congratulations are in order for the two of you for figuring it out and correcting it. Many thanks!

[mulcmu]

What, there's hope for the probe compensation? It's a Christmas miracle! 😄

I ran some more testing today probing along the tower directions at 5mm intervals. There seems to be a discontinuity in the data between the center region (CENTER_RADIUS 10.0) and the rest of the bed. So still some quirks to figure out with the probe patch logic. Hope this data is helpful:

Average Z probe height, bed at 60°C, bed clips set at 0.25mm. (+50 is near the tower in the 2nd chart)

After this testing, I found definition of SWITCH_TRAVEL -0.5 so adjusted bed clips to 0.50mm travel.


Average Z probe height, bed at 60°C, bed clips set at 0.50mm.

Rerunning G33 with the bed clips at 0.50mm seemed to change the resulting calibration, particularly the end stops. This was a bit disheartening.

Finally SWITCH_TRAVEL was defined negative so could there be a sign error in ao_plane_coefficients?

constexpr plane_t ao_plane_coefficients[] =
    {{ MX(A1,B1,C1), MY(A1,B1,C1), ZO(A1,B1,C1) - SWITCH_TRAVEL },
     { MX(A1,B0,C0), MY(A1,B0,C0), ZO(A1,B0,C0) - SWITCH_TRAVEL },
     { MX(A1,B1,C0), MY(A1,B1,C0), ZO(A1,B1,C0) - SWITCH_TRAVEL },
     { MX(A0,B1,C0), MY(A0,B1,C0), ZO(A0,B1,C0) - SWITCH_TRAVEL },
     { MX(A0,B1,C1), MY(A0,B1,C1), ZO(A0,B1,C1) - SWITCH_TRAVEL },
     { MX(A0,B0,C1), MY(A0,B0,C1), ZO(A0,B0,C1) - SWITCH_TRAVEL },
     { MX(A1,B0,C1), MY(A1,B0,C1), ZO(A1,B0,C1) - SWITCH_TRAVEL }};

[aegean-odyssey]

Thanks for supplying the data. I'll take a look at it.

The SWITCH_TRAVEL "hack" in the probe compensation is to shift the z-offset to 0 at the x,y origin (0,0). Z(0,0) would otherwise compute to SWITCH_TRAVEL, so subtracting it puts it back at zero. I did this so that the G29 P0 command would produce the same result whether or not probe compensation is enabled, and thus not effect a normal print job.

The discontinuity is a dubious "feature" of the probe compensation model -- an aspect of the model that exposes just how unfaithful the model is to the real world. I'll need to spend some time looking at the data. Inside the 10mm radius, I would expect the data to show the bed tilt, and the data kind of look like they do. Outside of the 10mm radius, I would expect the data to show little to no tilt IF the model really did capture the bed tilt. It looks like it has a way to go.

There are some other discontinuities in the model along the radii at and opposite the tower angles. Though these imply that the model cannot possibly be correct, I think we may be able to probe around these "problem" areas and still derive some beneficial use out of the probe compensation.

[aegean-odyssey]

Do you have an "Average Z probe vs Radius" graph when the probe compensation is DISABLED? It might shed some light on just what the probe compensation is trying to fix. My "model" of the tilting print bed may be entirely off-base. Perhaps the graph without probe compensation can suggest an alternate strategy or two to compensate for the bed tilt.

Also, waiting on a bug fix from Github for converting issues into discussions -- there is valuable information here and in other issues that I think will benefit the project with ongoing discussion.

[mulcmu]

I can go back and check my notes. I was working on a model that accounts for bed switches partially depressed. Looks promising so far:

This is a plot of nozzle travel below bed surface along a tower axis. Positive 60 is tower side.

[aegean-odyssey]

Interesting, interesting. I think the measurement at zero is an indication of the switch travel, or at least the switch with the least travel (somewhere between -0.5mm and -0.6mm). I think, too, that the asymmetry, that is, the positive and negative x-axis do not mirror each other, is what my flawed model would ascribe to one switch versus two switches being depressed. The same feature is visible in the plots with the probe compensation enabled, so clearly missing the mark.

A model where the switches may be partially depressed is interesting. In such a model, the first switch to reach its switch travel determines the "tilt" of the bed -- a much more realistic premise.

I'm wondering... maybe there is some way to use the bed tilt to find the true center of the bed. Knowing the true center of the bed could make it easier to calculate errors in the kinematic parameters (rod length, radius, endstop, tower angle). Hmm...

[mulcmu]

I cleaned up the model to make it a bit more presentable to share but still a work in progress. Comments welcome for improvements or to fix errors.
probe axis case.pdf
probe axis.wxmx.zip

The switch travel actually factors out of the final equation for Nozzle Z vs Nozzle Y location. This would be expected as the results should be dependent upon the switch adjustment. The derivation uses the logic that first switch to reach its travel determines the tilt. In the tower axis case, the assumption is made that the bed switch near the tower is the one that activates with nozzle on the tower side of center. On the opposite tower side, the other two bed switches are assumed to activate at the same time (due to symmetry).

[see3d]

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.

[aegean-odyssey]

I'll dive into it over the weekend. Sounds very interesting.

[mulcmu]

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.

[aegean-odyssey]

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

[mulcmu]

@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.]

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.

[aegean-odyssey]

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, F_A...F_F, F_N as in the Z direction only (i.e. no Fx_N, Fy_N, Fz_N 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.

[aegean-odyssey]

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.