They did not resolve the fundamental calibration issue I discovered on my unit and that snapmaker a)validate happens on their reference machine and b)have not yet explained.
I have held off documenting this issue on the forum until this point, but feel i have given support more than enough time to resolve this issue (over 90 days).
Issue
Simply put the head does NOT maintain the same fixed distances across the build surface. this manifests as getting closer to the build surface as the build surface moves to the front or to the back. It can be seen in this video after bed levelling head is not consistent height when jogged - YouTube.
Detail
This issue occurs with new rails and old rails.
This issue occurs with new v2 heard and old v1 head.
This issue occurs with old build platform and new latest build platform (what some of you call the bedframe)
This issue occurs with both manual and automated calibrations
If one moves the head to any given xy coordinate that was measured during calibration it reports as being at the same height when the sensor is queried (this was proved by support, i have their test results)
This incorrect height offset does not vary (this is not bed wobble) and is consistent when one visits any given xy coordinate.
This issue also appears to happen with multiple metallic build surfaces.
The firmware R& D team believe this is mechanical and referred it to Mechanical R&D team
The mechanical R&D team have yet to report back to the support ticket on this issue.
Where my head is at --edit: hmm pun not intendedā
I know this affects at least 2 machines (mine and the one support tested).
I donāt know if it affects other folks machines like yāall.
Is this enough of a difference in pressure to explain a subset of first layer issues some folks have- it certainly make chasing a flat bed / perfect first layer pointless
I donāt know if this affects folks with the IR mod.
At this point if support cannot resolve this in a timely manner then anyone in the Seattle area is welcome to make me an offer for a machine / new rails / enclosure.
This post is an FYI, i donāt need to debate troubleshooting, how i must be stupid, etc.
This is for snapmaker to resolve.
During all of your and supportās testing have you noticed is there any correlation between these points where the sensor returns the wrong result and the mounting screws that hold the heated bed down to the platform? The increase in the amount of metal in those areas should theoretically affect the reading.
Something like that would indeed be a fundamental issue, but something that theoretically could be compensated for in software as it should be consistent between machines.
Also, I donāt remember all of the tests youāve done - if youāve tried multiple sized grids (5x5, and others) have you noticed if the high and low spots are usually in the same areas of the bed?
Understandable. Frustrating itās been going on so long. Take care.
I havenāt bothered noting specific XY coords - but the testing report does, if that helps?
It is consistent that the center of the bed is always lower than front/back/left/right edges.
I just checked with my straight edge and the snapmaker calibration card:
edge along the X center line the card wonāt slip under the edge anywhere
edge along the 320 X line the card will slip under the edge in center
edge along the 20 X line the card will slip under the edge at ~260 Y point
edge along the 160 Y lines the card will slip under the edge at ~170 X point
edge along the 290 Y line the card will slip under the edge almost along the entire length (aka much larger gap)
to be clear i think the levelling mesh is absolutely offsetting some of this, just not all of it and not accurately.
i donāt remember all the tests either lol, for me it comes down to I have a repeatable test, that has been repeated on ā3ā machines (mine with and without new v2 rails) and snapmakers own machine they use in support.
IF and thats a big if given the low number of datapoints, this occurs on other folks machines it would make a mockery of all the bed calibration efforts people have been doingā¦ if i had an ask of the community it would be for folks to repeat the test in the video (probably worth doing on 3 Y axis and 3 X axis as i can imagine that the issue could occur along either a different axis or along a different vector) - mine might just āhappenā to be along the Y center lineā¦
I wasnāt thinking anything that specific. Mostly just thinking youāve been working on this so long if there were any areas you kept coming back to that would correlate with anything in the hardware. I think your next section addresses what I was after.
Hopefully the developers can come up with some sort of improvement here. Lord knows thereās been bugs fixed related to this before.
@scyto I just read through everything that you brought up, and I am wondering if this is somehow related to the Z Offset not resetting to 0 (zero) prior to leveling issue that I reported. I noticed the Z Offset issue shortly after the auto-leveling patch was released, which this too might possibly be related to. There is this other post Calibration Issues after firmware update which describes my issue in a different way, but to me, they all sound very similar.
There are a bunch more tests that are not posted in public topics as @scyto and I were in a PM trying to get it figured out. Keep up the documentation, I really want it thrown in Snapmakerās face, even though I know theyāll just ignore it since they just pick and choose what issues to fix that people are having and wonāt ever acknowledge the actual serious problems.
Good suggestion, donāt know, other than in my case the offset has always seemed to work well when I have used it, modulo the issues on GitHub I posted. My gut says firmware issue, but I donāt discount it being a mechanical issue (or even multiple issues combining in some way).
So I appear to have a final reply on this issue from support that amounts to not much more than a shrug and an admission that yup this is just how A350s are and they can give me a 10% discount on yet more rails. As such I believe the machines have a critical design flaw in calibration that renders everyone efforts pretty much moot.
If anyone is in the pacific northwest and wants to make me an offer for my machine, upgrades rails, enclosure, PM me. I donāt think this machine is for me when an ender can get better results.
We appreciate your effort and sharing so many test results with us. But we have to admit that itās hard to be 100% precise thus far.
The difference in the distance from the carriage to the base in two Y axes may cause the problem. And the printing platform may also be affected due to the assembly gap between the U-shaped bearing inside.
As for the upgraded modules, the main difference between them and the old version is that they are quieter.
We will keep improving our products, and hope we can figure out a better solution eventually.
If you are interested in any modules in our official store, please feel free to let me know. I will do my best to apply an additional 10% OFF discount for you.
This is something that has bothered me since the initial setup. Clearly the machines are not assembled, tested, disassembled, and shipped - so they are relying on the uniformity of the components (specifically, the carriages on the linear modules, and the bed itself) to ensure accuracy. This would require an enormous investment in QC of those parts, which is clearly not being done (just look at the difference in all the bed plots being posted).
My initial conclusion was āthey know what they are doing; it must not matter that muchā, whether that is due to 3D printing not requiring that sort of accuracy, or the software being super clever. But it turns out 3D printing does require that sort of accuracy, and their software has bugs and isnāt doing anything particularly clever.
All this is fine, I can work with it, Iāve fixed machines in worse shape - I just didnāt pay close to two grand for them.
Not really sure what this refers to. Is this bearing in the linear modules? Carriage rides along a lead screw, presumably in a track to reduce wobble. For the bearing gap to be a problem there, the leadcrew would either be at an angle or wobbling, and in either case - holy crap, thatās never going to work.
Thanks for posting that excerpt, gives me some ideas of what needs to be worked on.
Where Iām at with my own A350: Iāve steadily lowered my expectations for 3D printing, which may not be as useful as I thought it would be. I have no real use for laser engraving. Now preparing to play with the CNC: currently making workholding fixtures in the actual shop. The A350 itself has been mothballed until I find a better way to reduce the noise; the missus complains when I run overnight jobs - with my enclosure the printer is not loud, but it can be heard if you listen for it, especially in the quiet night. And generating plastic garbage is not a hobby that has been encouraged in my household, so you bet itās listened for and teeth ground in response
Itās not the leadscrew at an angle or wobbling, the leadscrew only pushes and pulls. Itās the bearings not maintaining proper tension on the rails, and they have a very narrow spacing with which to resist the applied torque from the platform in-line with the lead screw (the pitch, if you will, not the roll).
It does lol. If you crash into the bed too hard, or with CNC thereās excessive force from the bit because it binds in a cut, or the laser head crashed during calibration, anything like like it can cause it to loosen up.
Thereās not really a good way of maintaining tension. Itās a small metal eccentric nut on a small metal bearing on tiny metal rails, with a large leverage advantage against them. If anything shifts at all there will be a drastic reduction in tension. And for the platform thereās a huge lever arm that moves. A 1" bearing gap is holding a 14" platform, so even a tenth, 0.0001" will result in 14 thou of movement.
The particular bearings being used arenāt actually particularly suited to being axial thrust bearings, either. They are just basic ball bearings.
A better solution would be to use a real linear rail which resists the pitch forces in a robust way.
Which is why this mod is such a good one for improving platform rigidity:
That still doesnāt address the rigidity in the X axis where the toolhead mounts, and thatās actually where my problemās seem to occur the move as it canāt adequately withstand the roll forces applied during a toolhead crash, resulting in large backlash requiring disassembly and adjustment.
Iām considering mounting another rail parallel with the X axis along with a small mounting plate that sits between the toolhead and X axis mount to resist those forces better. Essentially adding the top rail here to support the roll and yaw forces:
Ouf. And letās not forget thatās in the cutter head rail (X) as well. A little bit of dig-in, or deflection from a knot in the wood, is going to move the X carriage one direction and the table another.
Been considering the linear rail guide, but the TODO stack is growing and growing and the SM2 is not helping reduce it.
I have been back-burner designing some modifications to the X-axis carriage. Originally for toolhead registration, which should (if done properly) cut down on the amount of calibration needed every time a head is swapped out. Additional rails for the X carriage had occurred to me as well, though with using the SM2 for 3D printing they havenāt been a priority.
Iāve been wondering how much flex is in the saddle of the carriage itself, under load. Rails should resolve that as well.
Thatās an interesting question. I havenāt measured that specifically, but I have noticed when the dial indicator is mounted on the X axis you have to use proper measurement techniques because ANY stray forces will skew the measurements. Getting repeatable measurements is actually incredibly tedious, and is the reason I had to start using 1-2-3 blocks for repeatable tramming of the X axis.
