How to find source(s) of 1.1mm slope to left?

So just to see if I have this straight

  1. the actual platform has a .6mm tilt, low on left
  2. the calibration generated a mesh with a 1.1mm tilt, low on left
  3. the resulting “corrected” movement has a ~.6mm tilt, low on right

I think that checks out, the mesh is overcompensating.

We just need to figure out why it’s measuring wrong so it will correct itself, or worst case manually apply a correction using M421.

It would be trivial to use Excel to generate a script that proportionally scales the slope down by a factor of two to correct that in the short term, if you want to post your M420 output here I can do that tomorrow. It would at least serve as a proof of concept for verifying flatness.

I’m not saying you should (I think mesh compensation should be able to handle the tilt), but you could try checking that the x rail is square to the 2 y mounting points, and if each z rail is square to the base.

I expect that the x rail should not be square to the y rail mount points (since that’s what causes the dial gauge video evidence)

If the x rail<>y rails is not square (I would expect this), and the z rails are square to the base, then you could try shimming up the right y rail by .6 mm.

If the z rails are not square to the base, maybe check their attachment. The z rails not being square would also explain your .6 slope left at the mount points and 1.1 slope left at the bed, followed by weirdness looking right in print, since a skew would show as different slopes at different heights in the skew (especially if the skew is enough to be causing actual movement because the two z rails are mounted to each other)

1 Like

@scyto ok, with the z brackets travel now being measured and near identical, the fixed mesh leveling should compensate for the shift if it were as simple as an uneven bed. I hope that it is the bed but my thoughts are it’s not. I just hope I’m wrong and one indent isn’t shallower/deeper than it’s parallel. I assume you’re going to continue the investigation tomorrow, so when you check the base plate, make sure the cap screws on the z rails that touch the plate are all the way screwed in (I highly doubt this is the problem, but anything is possible), my biggest fear is bad casting of the base and something is making either a y or z rail not perfectly parallel with its opposite. I pray I’m wrong.

sorry only just realized you said to do this.
I can post but the machine is in pieces, so i guess i should post the M420 V once it is back together as i suspect i just invalidated the current mesh :slight_smile: do you have preference on grid size?

Kinda late to the discussion. I was about to tear my A350 apart out of a similar sense of frustration, but after some careful measuring with the dial indicator I was able to make a grid of linear-module-induced differences (travel differing in the two Z axis modules) and, when that was addressed, a grid of local differences (the actual headed bed and/or print sheet).

When I was reasoning through this, the following possible sources of error occured to me:

  • Z axes not parallel
  • Z axes backlash not synchronized (the reason for the run-to-the-top step in setup)
  • Z axes differing in travel (there was some thread talking about one module not reaching the end stop)
  • Z axes not square to the X axis (slope is in the X-travel)
  • Z axes not square to the bed (slope is in the bed)

I may have missed something in the above discussion, but if I haven’t, it sounds like it hasn’t been verified that Z axes are parallel and are square to the X axis. If the X axis has been removed, a straight edge (or even a length of 3/8" or greater drill rod, if you are cautious with the measurement) can be set on the carriages and a square or the digital angle meter (zeroed on each Z axis in turn) used to determine squareness at the low, middle, and high extremes of travel on the Z axis. The same can be performed with the bed removed, with the Y axis carriages advanced to the base of the Z axis modules, to determine whether the Z axes are square to the Y axes independent of anything involving the bed.

Those are some simple tests that you have the equipment for and that I would perform if I had the A350 all taken apart. You shouldn’t uncover and significant error, but if you do, hoo boy it’s boat-anchor time for the A350 :wink:

1 Like

There were issues with linear modules have different lead screw pitches. Maybe worth investigating this:

1 Like

Thanks, that is worth checking out.

I actually got past the travel and levelling problems (I think - those seem to keep coming back like zombies) and am debugging the print head. The extrusion failures that at first seemed to be an e-steps issue and then seemed to be a z-offset issue and then seemed to be a humidity issue and then seemed like a nozzle/hot-end issue and then had to be a filament issue … now seem to be a temperature issue (as in, print head happily extrudes PLA at 240 but not at 230 or lower). We’ll see. I’m not going to derail this topic discussing it; when I eventually figure it out I’ll post a thread somewhere.

1 Like

Thanks everyone for all the help and insight, it really helped me think about the system as a whole and question almost all my assumptions.

Supports thesis was 1) warped plate and 2) linear motor differences on the z rails.

  1. we ‘proved’ this was unlikely by rotating the platform, heated bed, build plate 180 degrees - if it had been one of those then the slope would have shifted from slope to left to a slope to right.

  2. z linear motor differences - i was asked to measure heights. I did this and it can be seen in the early tests in this doc - but finding a speed difference that results in 1.1 mm diff is hard with a rule. so i came up with my own test using a straight edge and digital level (also in the doc). This ruled out any difference between z linear motors.

In addition to the previous dial meter tests that showed height tests i proved that the y bars themselves are level with respect to each other and the x bar - the top of the y units platform mount plates are not level with respect to each other. This can be seen in the doc.

Math validations:
I measured a 0.2 deg slope to the left with my straight edge place over both y rail platform mounts (see doc).

Over the entire slope (320mm) of the bed this 0.2 slope would cause a 1.1mm drop
(note the drop between the top of each mount place would be much less)

Calculation of the right scalene triangle from general data - side c, angle α, and angle β: triangle α=90 β=0.2 c=320 (triangle-calculator.com)

if alpha is 90 degrees (it can only be 90 as we are measuring a vertical drop)
and beta is 0.2 (the slope)
and c is 320 mm (the size of the bed)

then b - the size of the drop is 1.117 mm

tl;dr - support is sending me new y linear units; we will see then if i did my measuring and calculations correctly or I am an idiot and its something else like warped bed :slight_smile: i do think simple tests with a cheap stiff metal bar (doesn’t need to be a $60 straight edge like i used, just must have no flex) and digital level - both placed across the y units and the z rail mount points is a very simple way to show if the system is square/level with respect to itself. Once i get and fit the units i will let y’all know if it made a difference.

1 Like

lol, yup i ‘invented’ the use of the angle meter from first principles at the weekend, lol - where were you a week ago :slight_smile: (i am not a mechanical or handy person, this is all new to me and i am shooting blind!)

but seriously, glad to have someone validate the approach, and yes my $60 straight edge has been a boon - something that doesn’t flex. (and thanks to @Artezio for his significant offline help).

I still have one outstanding question on why the mesh levelling didn’t seem to account for this 1.1 mm drop and have some thesis that will need testing once i get machine back. They are:

  1. the billinear / catmull mesh don’t account for variances outside the slope of the mesh (i note that where i have issues are on the very edge of, or outside the probed area)

hmm now i write that, that’s the only thesis i have to test… question is is this a math problem in the mesh calculation, is it a measurement issue - i note the probe is done quite far from the edges (why?!) etc

1 Like

A week ago I was cursing at the A350 and vowing to make an example of it to keep all of my other electronics in line :wink:

This past weekend I wasn’t able to put in any real shop time for various reasons so I started to poke at it again.

2 Likes

@scyto i wonder if there’s a limit to what it will compensate for to prevent anything from hitting the project, or to possibly protect the probe on the head as it is only 1mm higher than the nozzle. A 1.1mm slope may not sound like much on paper but in reality it is a significant difference, I could also be entirely wrong about why it didn’t compensate though. Besides, with that big of a variation, if it were me I wouldn’t want it to be compensated for, I would want it to be addressed the right way just as you have done, as it could cause other issues later on like uneven wear, especially if the cause is mechanical maladjustment inside the rails.

1 Like

The bed levelling code continues the slope outside the outer probe points at a continuous rate to the edge of the bed.
This is a Marlin option, the other is to stay level with the outer probe points.
If your bed is flat (say a piece of glass) and the levelling is adjusting for slope, the chosen option is the best one, if it’s not then you could well have slope outside the outer probe points that is counter to what the bed actually does though your nice new straight edge may show whether it’s material.

2 Likes

Thanks for the clarification. Has snapmaker ever said if they will support UBL. Once the new X rails arrive I was hoping to dial in any further needed changes using the UBL UI in octoprint…

What specific features from UBL are you looking for that ABL can’t replicate?

The ability to use the UBL editor plugin in octoprint (and i guess the G29 Q test pattern, but that’s of only casual interest).

I have no idea how to edit the mesh otherwise? is there another easy way?

When used with the Q argument you can add or subtract a constant to a mesh value.

The bottom example is the most relevant:

Adjust the mesh point by -0.01

M421 I2 J2 Q-0.01

If you need to adjust large numbers of points I’d suggest using Excel and generating a gcode script that you can copy/paste and run from a macro.

Thanks for the link and info sorry for being dumb i have only looked at M420 V, so want to validate a few things before i go editing stuff by hand. M420 V output is what i have been plotting in excel:

image

  1. I assume i am editing the billinear mesh (as catmull is calculated)
  2. The first column in the output is the left edge
  3. The last column in the output is the right edge
  4. The first row is the front of the bed
  5. The last row is the back of the bed

Does the M421 command use the same coordinate system?
Aka the highlighted cell is I1,J3?

Or do i have myself completely confused?

No, you are editing the 5x5 non-subdivided grid. Everytime you make an edit the bilinear subdivisions (splines) are recalculated automatically.

I’m not positive on X and Y, it’s been awhile. You can add like 2mm to something like 0,1 and zip around using G42 to verify.

M421, G42, M420, anything mesh related uses the same coordinates in I, J. Which one is which is what I can’t recall of the top of my head. I prove it to myself every time though with G42 I0 J1 for instance.

1 Like

Man, I really need to stop using the touchscreen for calibration. There’s a lot of neat stuff in Marlin.

4 Likes

Just verified yes this is correct using M503 (which prints out mesh in G29 format - i always wondered what that was in 503 output).