This topic contains 18 replies, has 10 voices, and was last updated by
akira28hk 1 year, 8 months ago.
-
AuthorPosts
-
30/09/2014 at 10:04 am #7066

AnonymousI thought they had implemented a slower print speed on small layers? When I print a pyramid I think I can hear the printer going slower as the layers get smaller. The problem seems to be that it just not going slow enough on the smallest layers.
30/09/2014 at 10:25 am #7070Yeah, I thought it was working too. It definitely seemed to improve the pyramid prints I did.
@darthviper107 : If you’ve found buggy GCode, definitely file a ticket. I expect @ian will want to know about it.
Tom Gidden -- Bristol, UK
30/09/2014 at 10:51 am #7074@darthviper107, have a look at the print profile config file (C:\Users\user\Documents\CEL Robox\PrintProfiles in Win 7). You will find the settings file for any custom profile you’ve created and you can modify print speeds and a whole host of other advanced settings in there too. You may find that modifying this directly will enable you to print with speeds less than 20mm/s
30/09/2014 at 4:13 pm #7114Looking at the Gcode there’s no where in the print that it goes at the slow speed I set for the small perimeters.
I’ve submitted a ticket for the gcode errors-maybe there’s a setting that can be changed to get it to avoid tracing over the print
-
This reply was modified 1 year, 8 months ago by
Zach.
03/10/2014 at 11:44 am #7357Hey guys,
As it seems you know, we are FULLY aware of this issue - the only reasonable fix is for the head to either move out of the way or circle over the part until the previous layer has cooled before printing the next. Unfortunately it doesn’t seem that slowing the layer time down really helps, as @milchkuh said, the radiated heat also proves an issue. Although it sounds like a very simple change, we have 100’s of ‘simple changes’ to do, all of which are tracked using our web based issue tracking package - these changes are prioritised based on what we consider most important. The slicing engine is an incredibly complex set of code, and nothing is ‘simple’.
Please bear in mind we currently have 2 software engineers working their socks off (we’re looking for more) to improve all aspects of the software - macros, print profiles, interface, slicing etc., but it’s never as simple as you think… The good news is, you all get software and firmware updates delivered online, so over time, you will all see improvements in print quality, speed and functionality - we’re working as fast as we can. A large number of the problems with print quality can be attributed to our opensource slicer - Slic3r, which doesn’t always behave as you’d expect, we’re currently trialling a number of other slicers in the hope they offer some improvement in the quality of GCode generation.
03/10/2014 at 12:08 pm #7359Thank you for the update Chris, much appreciated
03/10/2014 at 1:39 pm #7375 -
This reply was modified 1 year, 8 months ago by
-
AuthorPosts
You must be logged in to reply to this topic.



