Closed kefir- closed 11 years ago
It would also be necessary to keep track of or reset E coordinate for each layer of each part, of course.
I fear there's one thing that make this request close to impossible (in the general case) : how do you detect Z lift on move ?
2013/6/1 kefir- notifications@github.com
It would also be necessary to keep track of or reset E coordinate for each layer of each part, of course.
— Reply to this email directly or view it on GitHubhttps://github.com/kliment/Printrun/issues/385#issuecomment-18792773 .
I see what you mean, in the generic case. But in practice, it should be quite easy to spot eg 0.5 retract and then 0.5 extrude (or 0.5 + extra extrude) in various cases. But I see how this gets difficult if retraction gets more complex. But it could work for the current common case.
Yeah, but these heuristics could get crazy. I'd tend to say that the host program is not the best place to fiddle with GCode in such a constructive way (we can dynamically ignore some commands, which is just about not sending them, but it sounds quite hard to construct something new by reordering a shitton of commands)
Sounds very promising for a gcode merge project, but I see no reason, why this should be part of Printrun,
I agree. Can be a separate project.
+1
It would be really nifty if it were possible to load multiple gcode files at the same time to print them all at the same time. To do this, it would be necessary to relocate prints so they don't overlap, and interlace the layers so they are all printed in increasing z height order.
I guess it would also be necessary to remove or consolidate duplicate/conflicting start.gcode and end.gcode.
This could be used to print multiple parts together that have already been sliced and take a long time to reslice. It can also be used to slice one part with two or more different settings for print at the same time, which could in turn be used to build calibration wizards into printrun for different settings like bridge speed, retract settings, etc.