I’ve been working on a print that’s very large and flat - it takes up most of the bed.
Using the distributed high_speed.ini, with travel_speed set to 200, I’ve noticed that if the Y axis travels at that speed across its entire surface, you hear a pretty bad sound. Sure enough, after 17-18 layers, one print was ruined because that very long travel ended up skipping off by half a centimeter or so.
Does anyone else have experience with fast Y axis travel, at 200 mm/sec, across the entire board? Does it work for you, and maybe I have a problem with my Y-axis? Or is it possible the high_speed.ini or the firmware should be toned down a bit?
though the Y should be able to go 200mm/SECOND. but your machine may be slightly different than mine. Perhaps your belt is slipping. Or it is skipping during MAX speed moves (most likely is)
I used the M code mentioned above to limit the max speed of each axis seperately, and I slowly increased each axis until it moved as fast as possible without skipping steps (the nasty grinding like noise).I just had the machine move as fast as possible from X0Y0 to XmaxYmax using G-codes after adjusting the M-code…and repeat.
just put that M-code in the custom G-code in SLic3r, at the beginning of every program and it will make sure you never go too fast, even if slic3r commands it to.
Well, that tells me how to fix my Y-axis problem without limit X-axis speed, which is really helpful.
It also tells me that your Taz may be able to handle a higher Y-axis travel_speed than mine by some 20mm/sec at least. I don’t know if anyone else can comment on their experiences to give a few more data points? I suppose Aleph folks would probably have the best idea of what the manufacturing tolerances are.
Just noting, that high travel_speed is only an issue for a very long, non-extruding traversal of the entire Y-axis range, or near to it. In other words, if you weren’t printing something big, as in, bed-sized, or even then, if it didn’t have full-Y traversals at high speed, you might never see an issue at 200mm/sec even if there was one.
I’m not losing any sleep over this. At least so far, it appears to be a pretty minor issue, but it is interesting.