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