Temporal-Based post-processing plugin (vs. layer based)

[Megahurtz 1]

Good day.  I find myself wondering if there is a post-processing plugin that can modify g-code in a time-based manner vs. a print progressive manner.

Use Case: FDM, forcing an action via g-code modification every xxx seconds vs. adopting an event based triggering i.e. on layer change.  Right now I have a post processing task of wiping the printer nozzle at layer change: https://youtu.be/lnH9Nze5cHM?t=43   While this works for many prints, there are cases where having temporal triggers would make more sense - prints that are small in X/Y but tall (think a tower or some such construct), or ones that are very large in X/Y (think having a print bed full of small highly-detailed short parts).  In the former, the nozzle gets wiped at every layer and just wastes time however, for the latter, it would nice to be able to force a wipe every xxx seconds (xxx being driven by the material dynamics), to keep excess filament artifacts from getting baked into the printed model.

So, does anyone know of such a way in which to modify Cura-generated g-code to have gcode steps every xxx seconds, to facilitate temporal-based actions?  TIA.

 

~MHz

 

Edited December 15, 2020 by Megahurtz

[GregValiant 1,251]

That's interesting.

Cura time calculation is not very accurate.  Determining the Z value in a file with Z-hops is tricky.  Thinking on this though...

At the beginning of each file, Cura puts in a guesstimate of print time in seconds.

At the end of each layer Cura adds a line ;TIME_ELAPSED:428.207830 for the guesstimate of the print time of that layer (a guess to 6 decimal places!).  Unfortunately, if the layer takes a long time and you require multiple wipes during the layer things get problematic.  I don't like my thoughts on "temporal" so I've just erased them.

 

How about count the bytes?  We know the approximate print time and the file size.

I have a file that Cura tells me takes 17880 seconds to print and is 18,790,673 bytes.  I want to wipe every ten minutes.

17880/600 = ~30 wipes in the file.

18,790,773 / 30 = ~626,359 bytes/wipe (sounds vaguely disgusting)

 

Count bytes in the file to 626,359 and insert your code there.  Keep doing it until the end of the file.  It would also require a "read behind" to know the print height Z (as opposed to a Z-hop height).  There might be a need to insure the code didn't get inserted in a "bad place".  Do you need to know the E value in case of retraction and prime moves?

 

Then there is extrusion distance (I like it).  You could parse the file for E values.  You know the feed rate, line width, layer height, and mm of extrusion/mm of filament.  Every so often (1000mm of filament?) insert the wipe code.  It has the advantage that you always know the E value and Z value.  The disadvantage is you would need to parse every line in the file.  Cura by design resets the extruder to 0 every so often (its a math "round off" thing) so you would need to keep track of the E to figure where the next 1000 actually occurs, or easier, don't worry about a possible 10% error occurring every so often.  Another plus is that you get multiple wipes during long layers for free.

 

[ahoeben 1,948]

I think that in the usecases you sketch, doing things purely timebased won't be great either; you probably don't want the printer to start doing a wipe in the middle of printing the outer wall. I think you'll want something more intelligent than just layers OR just time. You'll want to know how long a layer takes (which is available in the gcode, though might not be extremely accurate depending on the printer definition), and decide based on that and the type of feature that is currently being printed (eg not during outer walls).

[Megahurtz 1]

On 12/15/2020 at 12:15 PM, GregValiant said:

Then there is extrusion distance (I like it). 

I too like it.  I think byte count is likely pretty suboptimal, and, given time that time may be somewhat sloppy, that too is suboptimal now that I know that (time guesstimates being potentially inaccurate).  The concept of popping a wipe at some threshold of material extrusion, during travel/infill/internal walls seems to be the best approach.

 

On 12/15/2020 at 12:15 PM, GregValiant said:

Another plus is that you get multiple wipes during long layers for free.

This is exactly what I am interested in - having the option to do multiple wipes per layer, when they are long layers (i.e. first layer with support and adhesion, a bed full of elements, or both).

 

On 12/15/2020 at 12:38 PM, ahoeben said:

you probably don't want the printer to start doing a wipe in the middle of printing the outer wall

This is a good point.  I do think it best to articulate a wipe during (in descending order): 1) travel, 2) infill, 3) an internal wall, avoiding, if at all possible, doing a wipe during 4) an external wall.

 

Given these considerations, does it make sense to try to tackle this approach in a plugin, or via post-processing?

Edited December 20, 2020 by Megahurtz

[ahoeben 1,948]

9 hours ago, Megahurtz said:

does it make sense to try to tackle this approach in a plugin, or via post-processing?

It is already possible to do this within a postprocessing script. Not easily, and it has not been done in any scripts I know of, but certainly possible. Doing it in a separate plugin would not be easier.

[Megahurtz 1]

Thank you, sirs (gender assumption - forgive if incorrect).

Edited December 20, 2020 by Megahurtz