I’ve been wondering if they can run calibration tests to compensate, like the thing they did with the motor noise.
I imagine because it varies across the entire print area - it does not happen on the Y axis and the 2mm VFA occur most toward the rear not near the front. It also varies in intensity wildly from machine to machine. Since not enough people are complaining and it’s not easy to address it, why address it?
I think still possibly replacing the belt itself could help or rounding the teeth since it is caused by the flange tooth rub if anything.
Today I did my 2k hour printer maintenance. Replaced the belts and the X gantry as I had spares. Noticed the new gantry moving a lot more freely. No change whatsoever on the VFAs and the gantry is perfectly square and belts are equally tensioned and aligned with the pulleys. Also the tape mod did nothing of note. So back to square one…
1 Like
did you use a Bambu belt or a real Gates?
I actually replaced my belts today as well and I tried sanding the teeth off of one end of each belt so that those two idlers aren’t against teeth. It’s hard to fully sand off the teeth without exposing the internal banding but at least the first test it looks like an actual improvement.
Could you please post the test results?
Bambu belts. But I’ve also seen that gates equally make no difference.
So here’s what the sanded belts look like.
Then this is with a flashlight at a low angle.
They’re not gone but at least in this image it looks improved and in person it does too. Below are the same but just normal light in a bright room (the 45 degree morie pattern in the middle top isn’t really there, it’s just somehow from my phone).
I’m going to try adding a coupe wraps of teflon tape back in to see how that looks.
How hard was it to remove your belt wedges? Two of mine were fairly hard to get out, the third ripped off the belt as it exited, and the last one I actually sheared the plastic tab and had to dig out the rest of the wedge.
What happens when you move the tool head all the way to the back and all the way to the left or right? Seems like there won’t be any teeth to engage on the stepper motors? And if they are what happens when you’re all the way to the front and then right or left? There would be a jump caused by teeth coming into contact with the pulley then?
Before i postet the solution i testet your question with a dot on the belt right before it goes over the pulley and moved the toolhead on every position of concern. Did reach about half way to the stepper. so plenty of teethed belt left.
Interesting. What about the other way? All the way to the front and tool head to the right? Is the left belt still riding on the sanded down part? A couple of pictures with the two scenarios would help a ton!!
One of my thoughts after reading all the posts, couldn’t we think of proposing to Bambu Lab to modify the anti-oscillation test so that it also includes the movement phase at various speeds of the print head?
Don’t you think it can take into account the vibrations theoretically emitted by the toothed belt on the smooth pulley?
If they are indeed vibrations (micro-clicks), perhaps they fall within a frequency that the system can compensate for?
I don´t understand, why every problem should be solved on the Software Side only? It´s kinda frustrating, that we are heading in the direction of fixing poor physical designs with computers. Imagine the possible print qualitys, with a almost perfectly physical machine and then adding the software side… In my master programm, we are working on postdigital designs and i think it´s really important to again incorporate the whole picture instead of fixing everything with software…
On the other hand, in this belt discussion a question arose… Would it be feasible to alter the core x/y in future designs, to add adaptive belt tension. A first draft would be adding load cell sensors to the stepping motors (if even necessary / current feedback could be enough) and intentionally let one lack behind a little bit during movement. What would adaptive belt tension change in different print scenarios.
1 Like
There are those who have already done it, printer without belts:
https://www.wired.it/progettisti/2016/06/21/come-fun-roboze-stampante-3d-cinghie/
I would like to see if they solved the VFA…
but in my opinion at high speeds the rack wears out and deforms over time.
The idea of voltage on motors is interesting if manageable…
magnets would solve this…Tesla 3d Printer?
I don’t really understand this, “I don´t understand, why every problem should be solved on the Software Side only?”
I don’t think anyone suggested to “only” fix it with software. I don’t know about you, but I would much rather have this problem fixed automatically with a software update than if they offered a new replacement belt that I have to physically install. It would be great if they had a hardware and a software solution, but if the software one worked, it would be way easier for the end user. Of course they should make sure to design the next version with hardware that does not have that problem, but for everyone that already has the problem, a software update is the easy, quick, and inexpensive solution.
There is nothing to fix “in software” here. It is a mechanical resonance caused by the drumming of the belt teeth against the smooth pulley.
1 Like
By software, I’m talking about creating some sort of thing in the firmware so the machine can calibrate it out. Like they cut down on some motor noise, and they compensate for vibrations, etc. It’s not fixing something in the software, but rather a software based solution.
I know what you were talking about, it just isn’t viable.
They reduced motor noise in software because that is where the motor noise originated from.
These 2mm artifacts are mechanical vibrations generated by impulses from the belt teeth. There is nothing “in software” that can cancel this out effectively. That’s like saying “the wheels on my car are not balanced, so I’ll change the ECU tune to cancel it out”.
1 Like
Whether or not it is fixable in software control I think the issue being mechanical in origin would be the easier to solve in hardware. I’ve also said it before, but I do not think Bambu has any incentive to fix this issue that only bothers a meager couple percent of their users. If we want it fixed we have to fix it.