Skip to content

Feature Request: Export of extrusion velocity and continous timer #9

@TimKrautwald

Description

@TimKrautwald

Hi,

there is a known limitation to the way our hotends work and produce melt. It is uncertain at which temperature the melt leaves the hotend as this depends not only on the current state of the extrusion but also the total time which the material spent inside the hotend (and a lot of other factors).

While shorter hotends like the standard E3D V6 can easily be overwhelmed by too much filament beeing stuffed inside them, there is also a problem with proper layer adhesion. This is due to the fact, that it depends greatly on thermal energy to bond. I believe that the real temperature of the filament leaving the hotend can easily drop more than 30C resulting in parts that have strong and weak bonding between layers. This is obvious when you take e.g. black ABS and check how white the broken off surface is. On bigger machines with long melting zones (60mm and longer) the thermally induced change in density becomes a severe problem. When you push the hotend anywhere near the limit you get a temperature distrubtion with an average clearly below your actual hotend temperature. On longer travels the temperature homogenize and the density gets lower. You either loose that amount by an unsufficient retraction or push an ugly overextrusion for some distance after unretracting. On acceleration the problem is not so obvious, but leads vice versa to underextrusion as the density increases. I guess many people notice this effect when they randomize the seam position vs constant seam position. The randomized version tends to look more rough due to this effect, while it is somewhat hidden on constant seam position.

If we could get a rough estimation what is going on in the hotend this could yield various advantages like faster printing speeds, better layer adhesion and more reliable printing overall.
Initially I thought it would be the best to do the calculations on the fly in firmware. But that severly limits the potential as the printer can not react fast enough and has to constantly guess if the melt will be up on temperature in time. And it would be a lot of work to port it to different firmwares etc. So it may be better to approach this with a postprocessor that can spectate the whole length of each path (or integrate into cura long term). The first step would be to simulate the real movement after trajectory planning as close as possible. Cura seems to use acceleration and jerk to calculate total printing time already. I dialed the numbers in and the predicted time is pretty close, even though I am using Linuxcnc, which uses junction devation.

So, wall of text done, is it a lot of work to get these numbers (current speed and time) from cura and print it to the gcode for each line? I am not familiar with the engine, but I guess everything is already there? This could be a good starting point for everyone that wants to develop advanced features.

Looking forward for your opinion on this.

Best regards,

Tim

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions