kliment / Printrun

Pronterface, Pronsole, and Printcore - Pure Python 3d printing host software
GNU General Public License v3.0
2.37k stars 997 forks source link

Feature request: add multiple gcode files for the same print #385

Closed kefir- closed 11 years ago

kefir- commented 11 years ago

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.

kefir- commented 11 years ago

It would also be necessary to keep track of or reset E coordinate for each layer of each part, of course.

iXce commented 11 years ago

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 .

kefir- commented 11 years ago

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.

iXce commented 11 years ago

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)

hroncok commented 11 years ago

Sounds very promising for a gcode merge project, but I see no reason, why this should be part of Printrun,

kliment commented 11 years ago

I agree. Can be a separate project.

iXce commented 11 years ago

+1