the calibration generated a mesh with a 1.1mm tilt, low on left
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)
@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 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
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.
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.
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.
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)
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 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.
lol, yup i ‘invented’ the use of the angle meter from first principles at the weekend, lol - where were you a week ago (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:
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
@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.
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.
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…
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:
I assume i am editing the billinear mesh (as catmull is calculated)
The first column in the output is the left edge
The last column in the output is the right edge
The first row is the front of the bed
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?
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.