I have broken it breaking it in What seemed to start so well ended rather embarrassingly disastrous.
How much of a shakedown would the break-in be? What are the typical problems that show up and resolutions?
Could 200mm/s be too fast for RAMPS/TMC2100 drivers?
At first there was a bit of a hum that I assumed was bearing āstictionā but seemed illogical as I had just oiled the rods . Then it got worse and I started to think that the belts seemed looser, and then it was obvious that the belts were loose and I was skipping teeth. The last part of the video the printer is trying to put the effector out of bounds. Its almost embarrassing to show, but I believe that only through talking openly about our failures can we succeed.
3 segment video- I had to use my phone to capture the sounds. Forgive any bobbles or sneezesā¦
I will admit to suffering from a little instant gratification threw on piece of glass and tried printing a couple of test cubes but it did not go well.
I donāt even know where to start looking. I do have one axis with 2 rubber/kevlar reinforced belts and one with 2 polyurethane/steel belts. I donāt think this could be the cause or matters.
I am thinking its either something mechanical or the RAMPS/TMC2100 is not up to snuff.
I am thinking that I will start with rechecking the frame and try to double check the main rods and see if there is something amiss there.
In case its relevant, here are my Marlin files. I bumped the default speed and acceleration to somewhere between the defaults and the ones I read in the Smoothieware files.
Check to make sure you arenāt overheating the tmc2100 drivers causing missed steps due to thermal shutdown. The TMC are great drivers for many things, but I will admit they are the most sensitive drivers I have used in terms of getting current set correctly.
Until you get the current tuned in for your motors and torque requirementsā¦ 200mm/s is a bit too ambitious imho. Especially since the gantry and everything is not broken in yet.
As far as acceleration, i used to think i needed acceleration crazy high. But over the years, once you get above 1500 there is a very diminished return. 1500-3000 is a good range for a Eustathios. Any more than 3000 and you will never see the benefits.
200mm/s seemed fast to me too. I did not question it since 200mm/s was the speed noted in the breakin gcode file that was on github.
Is there a different one, or more updated one we should be using?
I have been studying the gcode file in an attempt to rewrite it into a spreadhsheet so that we can change parameters for bigger or smaller machines and change the travel speeds
Thanks for sharing this, I am also having similar issues albeit not quite as severe. I get the chatter/buzzing like you do running the break in code. I let it do its thing once through and I then went around and adjusted the lower rod bearing holders one at a time like in Ericās video and that seemed to lessen it a bit. Iām going running again will do the same. Iāll try to post a short clip as well.
@Dennis_P there are spread sheets on the internets to do exactly what you seek. I speak g code for a living. The F command is what you seek ie F200. Must have decimal or turns into f.2 it stays modal until called again.
@Dennis_P i meant printing at 200mm/s is ambitious. The break-in code can be sped up or slowed down via your lcd by rotating the knob on the main status screen (feed rate override). I have run it at 2x before (though I donāt recommend it).
The main thing we need to figure out for you is the source of the skipping steps. With all the long fast moves of the break-in code, any skipped step error will accumulate fast and cause and āout of boundsā condition.
My first guess is a thermal shutdown issue. I have fought with TMC drivers before, so the current there will be where I would start.
@Ryan_Fiske for the chatter (at the end of the travel move I assume). You can try tuning acceleration and jerk (or acceleration and junction deviation on smoothieware). I have noticed with my machines, break-in takes time. And I havenāt found a good way to rush it along. Its like soaking a pan with burned on food. Give it a little soak in time
One trick I recommend to people is put a stack of 7 or so Post-it notes under one of the printer frames feet. Run the break-in code and listen, does it sound better or worse. Then stop the code, move the stack of Post-it notes to the second footā¦ Rinse and repeat with all 4 feet.
What that is checking is if imparting a twist in to the frame on purpose makes things better or worse. If for any of the 4 feet the stack makes noise and chatter betterā¦ Then you have a mild frame alignment issues. Or you have a table which isnāt as flat as your frame, causing the table to impart twist into your squared printers frame.
@Eclsnowman thanks so much for the suggestion on acceleration. The stock config file on the main page has acceleration set at 9000. I put it down to 3000 and am no longer experiencing the chatter/buzzing! I lowered my current from 1A to 0.8A as well and itās still fine! Going to run it through another break-in cycle then attempt it at a slightly lower current.
The left belt on the video seems a tad loose. Be also sure that the screws on the pulley are properly tightened on the stepper axis, any small shift will throw your printer out of square. Good luckā¦ Youāre so close!
I started dissecting the breaking gcode fileā¦ the comments say 200 mm/s but its actually 166.67 mm/s if you convert the F10000.
I learned a lot by deciphering it line by line. I ultimately decided to write a spreadsheet to write the code snippets. @j.r_Ewing could you review and comment on it? @Eclsnowman have time to look and share your thoughts? I would like to improve on it and make a little more elegant for everyone to use.
I did linear moves for small and large squares and diamonds on one tab and circles on the other tab with G2 and G3. I would appreciate suggestions and comments.
My intent was to be able to change the bed dimensions, Z offset, boundary margin, square size, travel speed, etc and have it auto-populate the appropriate locations. We can certainly add fields and parameters to the strings.
It looks like most of the mainline firmwares support it. I donāt think that its up to date though, even though the wiki says no for Marlin, the Marlin pages say yes. Smoothie, Marlin, Repetier, etcā¦
@Michael_Memeteau that left belt and holder have been problematic. Its really loose at this point. I cant not tell if its the belt stretching or belt slipping. I am actually reprinting another set b/c i donāt like the fit of the belt and belt clamp.
@Dennis_P i will certainly look over this tonight. That would be a great addition. I generated the break-in gcode years ago as my first attempt at hand coding gcode. I havenāt looked at since, just ran it. So having a system by which to custom generate one based on input variables would be awesome.
@Michael_Memeteau The analyzer does not like my simplistic gcode. I think i am missing some instructions that it might be looking for. I think that it is looking for a properly formatted print file with layer info and the like.
These two seem to display the tracks https://nraynaud.github.io/webgcode/
@Dennis_P I amkinda new to the 3D printing world but Iāve been a cnc programmer 5 axis and lathe live tooling c y axis for 20 years. Iāve been using cura I noticed itās all g1 linear moves in some cases itās a blocks per second thing that limits feed rates. Fitting arcs (g2/3)can shorten the code and make smoother parts but the controller does more work. Iām going to start building one of these ASAP. I was posting code as marlin. Iām getting a smoothie Ware this week. It supports g2g3. On a 3 axis always use IJK delta start to center. Not just R. There is a real chance you can zig not zag
All my machine warmup programs do figure 8 after each pass around picks up speed.
Do you have to have % at beginning and end and O#### for printer code?
@j.r_Ewing no hijackā¦ i TOTALLY hear you on this. I too come from some machining experience. I hate this simplistic triangle crapā¦ but what you and I need to āappreciateā is that the meshes and layers that these printers and slicers rely on is an antiquated concept of surface generation via layers and a mesh of triangles because that was the most efficient way with the computing power we had TWENTY years ago. Its very much like a CAT scan in reverse because it was invented at the same time.
Fast forward 20 years and we are doing 5D & 6D CAM from CAD directly. There is not intermediate dumbing down of the physical model to fabricate it like the the consumer world of 3D printing that we are dabbling in. I want Mastercam for 3D printing. I suspect that the complete workflows from ACAD and SW might be more efficient, but I dont have the funds to time to dabble.
I made a post a few months ago complaining about thisā¦ .Cura is the worst for me, S3D is unnecessarily complicated and KISS is lacking in the interface department- but I consistently get NICE prints with KISS so I stick with it. I have an easier time following the KISS gcode files too.
If you donāt want to trig out the arcs use 45 degree corners and linear moves thereās a few free 2.5d cam packages out there that will give you centerline tool paths. Autocad 360 the home use one I thought did this. Remember I is not the Y. I could give you the code you seek if you really are at a hardspot but you should learn it.
It maybe possible to run a filter and fit arcs to existing point move code. My buddy had to use it to get a huge program on a small controller. The layers should stack just the same even with .005 spline tolerance once my righ is running again I see science progestin
I am fluent in Masterscam, Feature-cam and solid works
What seemed to start so well ended rather embarrassingly disastrous.