This topic contains 19 replies, has 4 voices, and was last updated by 
click 4 months, 1 week ago.
-
Posts
-
@nebbian “Cura also seems to put lots of short extrusions into my model, whereas when Slic3r slices that exact same model, it manages to use long, straight, continuous extrusions.”
Did you compare ‘pure’ Cura and ‘pure’ Slic3r or AM post-processed Cura gcode vs Slic3r’s gcode?
“Another issue is the limited tweaking that’s available in AutoMaker. I can understand why CEL have done this, they want something that’s easy for beginners to use, but for me (I’ve been printing for almost 2 years, and have explored every advanced option in Slic3r), it’s frustrating. I know that it’s possible to tweak some more options by opening the print profile in a text editor, but that only has a few more options than is available in the AM GUI.”
… and hence my hopes that AM will some day become more open or at least allow some plug-in system. The other day I tried to find my feature request for making such framework so people like you could ‘slot-in’ different pre, post and post-post-processor scripts. Also, AM is getting new bugs (or features - depending whom you are talking to) which are really minor and as such would never get any attention. For instance if you have restricted resolution and long project names it doesn’t take long before you cannot add new project as ‘+’ slides under configuration icon.
“I was hoping to see if it would be possible to get the stock slicer to use another configuration file, perhaps one that was exported from Cura. Cura by itself (the standalone version) has lots of configuration options to tweak, which might allow me to get the quality that I’m after. I can only really do this if I understand the differences between the Robox version of the CuraEngine, and the freely available current Github source for CuraEngine.”
A couple of years ago I did think about it and got solution. It could be relatively easy to slot in script/simple program that will be called ‘CuraEngine’ which will, in turn, call whatever else you want (or the same CuraEngine) and do enough ‘pre-processing’ or ‘pre-post-processing’ needed. Something similar to what I did with jssc-2.8.0.jar to achieve what Root is doing a few years before it was conceived - see here: http://www.cel-robox.com/forums/topic/remote-robox-on-osx/
So, replacing ‘current, robox’ version of Cura with the newest or even Slic3r is possible by giving AM different executable/script with exactly the same name. That, for instance, can help those who would like to exploit some Cura parameters that are not handles by AM. All of it is seems clunky bodge, but could be, in theory, made far less painful by adding code outside of AM that would do it for people.
But, all of it would be completely unnecessary had CEL decided to work with community and allow anyone else contribute to the software for their printer. At some point year a half or so ago (probably sslightly more!) I was more than happy to sign all non-disclosure contracts needed and donate my time to make such outside of AM integration happen but unfortunately my long support ticket post didn’t arrive to right hands (and even then there was no guarantee it would have done much).
You must be logged in to reply to this topic.
