I will be away from home for one month and a half, and won't be able to work on my printer during that time.
I thought that if I still have enough energy in the evenings, I want to have a project to bring with me, as I'm not really a TV guy.
I thought about coding SliceBlender, an interface that allows you to select STLs, call different slicers, and then blend the slicing results in one GCode file to send to your machine.
Obviously, the goal is for multi nozzle printing, but it could also be useful for single extruder machines. The advantage is that you could use separate slicers for what they are good at... infill, perimeters, supports... etc.
Do you guys think you could be interrested in such a software, provided freely, and open sourced ?
If yes, please let me know of what you want to see in it, and what you don't want to see.
If someone wants to jump in, I am ready to share the work, may it be specifying, coding, testing or writting manual.... etc.
Whether you are interrested or not, I hope you can tell me why.
SliceBlender
Re: SliceBlender
Wow, that would be my current definition for the word "recombinant".
Personally, I don't think it's practical. Most printers have their slicer of choice. They get used to all the peculiarities and deal with them accordingly. I also think you might end up dealing more with conflicts than being able to produce something useful.
What I think would be of value - if you're considering a code lift:
1. Something to paint a normally sliced G-code file to accommodate multiple extruders. In other words, you have an object rendered from the gcode and a user gets to draw lines/circles/triangles on it and assign extruders to those areas. They might select whole surfaces, mark up surfaces, etc. If I'm not mistaken, nothing does that post-slice.
2. Something visual to avoid manual editing of G-code - paint or select certain areas of the print that get different treatments (speed, layer thickness, etc). (I've heard that some folks are gradually working this feature in.)
3. Something that does a significantly better job of replaying head-movements - or something that does a non-print head movement analysis.
Just some thoughts...
Personally, I don't think it's practical. Most printers have their slicer of choice. They get used to all the peculiarities and deal with them accordingly. I also think you might end up dealing more with conflicts than being able to produce something useful.
What I think would be of value - if you're considering a code lift:
1. Something to paint a normally sliced G-code file to accommodate multiple extruders. In other words, you have an object rendered from the gcode and a user gets to draw lines/circles/triangles on it and assign extruders to those areas. They might select whole surfaces, mark up surfaces, etc. If I'm not mistaken, nothing does that post-slice.
2. Something visual to avoid manual editing of G-code - paint or select certain areas of the print that get different treatments (speed, layer thickness, etc). (I've heard that some folks are gradually working this feature in.)
3. Something that does a significantly better job of replaying head-movements - or something that does a non-print head movement analysis.
Just some thoughts...
Technologist, Maker, Willing to question conventional logic
http://dropc.am/p/KhiI1a
http://dropc.am/p/KhiI1a
Re: SliceBlender
Thanks for your response.
well, probably, I won't do it then... not much interest, as I see it.
Anyway, I have other ideas... but not of any help to reprap community.
well, probably, I won't do it then... not much interest, as I see it.
Anyway, I have other ideas... but not of any help to reprap community.