[FEATURE] Simulation of real filament flow/springiness

[DRracer]

Is your feature request related to a problem? Please describe.
My request is related to a problem, which is however not in MK404 :) .

Describe the solution you'd like
Right now we are able to make detailed visualization of extrusion thickness. We can even do nonlinear behavior of the TMC+motors. The functions responsible for doing this are:

void OnXStep(const uint32_t &value)
void OnYStep(const uint32_t &value)
...

@vintagepc do you see a possibility of passing some kind of simulation step or temporal difference? Imagine adding filament dynamics into the visualization. That may help tackling ghosting artefacts and Linear Advance issues which we think are still present even in FW 3.9.1

[vintagepc]

Hmm.... I had no designs on it initially, but it's code, so anything is possible.

Are you just asking for a way to see the extrusion derivative with respect to distance or time? (Time would be trickier, but probably also possible) Or, are you asking about a very literal simulation of the plastic flow?

If the latter, what's tricky is figuring out the actual plastic simulation; I suppose an initial start could be a simple sliding window impulse filter on delta E (so that spikes turn into "blobs").

That might be sufficient, but my concern here is that this is going to very quickly become a very deep rabbit hole because of the number of factors and complexity involved (temperature, melt volume, pressure, extrusion rate, ....) bottom line, it would be a very complex physics simulation, to the extent there are entire software packages for modelling such things...

[DRracer]

@vintagepc I'd like to develop a very simple spring model of plastic flow to smoothen the extrusion visualization similarly as real plastic does. I'm looking for artefacts in Linear Advance (ghosting in acceleration segments to be exact - you have them on your print as well ;) ), which can be then mitigated by clever timing of LA pulses.
My initial idea was to get time (steady time stamp, temporal difference, whatever else) into the functions above and plug in some separate spring model of plastic just like we are using the motor nonlinearity right now. The rest would remain the same, nothing too complex.

[vintagepc]

Hmm... that doesn't seem too wild. For time it would likely be best to use the delta in CPU cycles converted to seconds, as that should be fixed regardless of how fast or slow the simulation is running.

[DRracer]

yes, that would be sufficient - I just need some time stamps to try it out ;)

[vintagepc]

I'll see what I can plumb in, then I can just hand you a place to stick the equation ;-)

[vintagepc]

I'm extending this a little; I'm working on some math to use dT to detect when we exceed the max volumetric rate of the hot-end. No idea how well it will work in practice but if I can get it working it would be good to help ID underextrusion artifacts caused by excessive travel speed or extrusion volumes.

Leaving it permanently on would probably suppress impulse artifacts so I think it will be most useful as an alternative to --colour-extrusion where we change the lerp to track the segment volumetric rate instead of the extrusion width. I don't think designating clamped values alone is going to be all that useful, seeing the colour variations as we get closer and move away from the (theoretical) limit is likely going to be more relatable to what we've seen in practice, if anything.

[vintagepc]

I think I've got it working, I'll push up a branch with this feature shortly once I add a command line flag to enable it. I think it's obvious where any inspiration came from 😛

Gcode with perimeter speeds @ 50mm/s to start (volumetric rate 4.1mm^3/s) and increasing speed (M220) by 50% every 3 mm (so 150, 200, 250, 300) thereafter.

"Red" or "max" is calculated based on the published max capacity of 11.5mm^3/s, but of course this will vary depending on filament properties and nozzle temperature)

Edit: pushed, with --colour-volume

https://github.com/vintagepc/MK404/tree/265-extrusion-visualizations-EVol

[wavexx]

On Mon, Oct 19 2020, vintagepc wrote: I think I've got it working, I'll push up a branch with this feature shortly once I add a command line flag to enable it. I think it's obvious where any inspiration came from 😛

It would be nice to switch between colorization modes without having to restart ;)

[vintagepc]

Alas that's challenging with the current design. we don't retain the source data once the triangles have been pushed into the vertex vector. (Same reason toggling nonlinearity does not retroactively enable on things that have already been rendered) I suppose it's possible if we retain the originals but this particular bit of code is already fairly costly in terms of computation so I'm not sure it would be a good idea to run additional calculations that are not actively in use. In fact I need to look at it and see if it can be optimized a bit.

I suppose the cost of storing the path is << the triangles rendered though, so maybe a nice middleground is to support changing that on the fly but only on-demand. Perhaps it's even worth printing a greatly simplified rendering until the print is finished (plain lines which comprise the path) and then being able to shove all of the vertices into an actual graphics card vertex buffer for the final render in highres mode.

Thoughts? I don't have a good sense of the use case; is there a lot of benefit to seeing the realtime output or do we generally just look at the final result once it's "done" printing?

[vintagepc]

Filed #277 to investigate this.

[wavexx]

On Mon, Oct 19 2020, vintagepc wrote: Thoughts? I don't have a good sense of the use case; is there a lot of benefit to seeing the realtime output or do we generally just look at the final result once it's "done" printing?

I didn't actually mean to change the existing path, just to switch to a different mode for the new vertexes as they're being pushed. This is already more than helpful when printing objects which are repeated in Z. If I see suspicious behavior I can always clear the buffer and start anew for a more in-depth inspection.

[vintagepc]

*looks at the entirety of MK404

I thought by now it's clear I either go big or go home... 🤣

[wavexx]

Muhahah ;). I wouldn't discard the option to switch mode without changing the existing path.
I still like the idea to look at a wall which has been colored in 2 different modes over time 😛 across Z.
Much easier to compare than looking at two models side-by-side, even now that we have that ;)

[DRracer]

@vintagepc wow, I love it! This looks exactly like what is needed to fix (counteract) the ghosting artefacts in Linear Advance.

[vintagepc]

👍 I've pondered it and I think I'll do away with the separate command line arguments and just move both colourization options to the context menu so that one can be picked on the fly. I'll leave recalculating the existing content to a future endeavour.

[vintagepc]

Pushed - I moved the colourization options to the menu.
Note - they will not show unless you have passed --colour-extrusion on the command line; this is because we skip processing the colour entirely if we haven't been asked to do so and the colour vector would not be correctly aligned if one tries to go from "no colouring" to such an option it on mid print.

[vintagepc]

Note I'm holding off merging this since when we do I'd like to have #276 merged in and be able to add some test coverage for these features. I also expect it to change/expand in the near future, so no point writing tests too early if they are going to be invalidated anyway.

[vintagepc]

I stumbled upon a very interesting print today while experimenting. 5% gyroid at normal infill speeds seems to produce some very interesting patterns:

I suspect this rippling may be the burst-mode stepping that was previously mentioned

[wavexx]

@DRracer found a case earlier this week where a low-poly circle would significantly increase LA due to the jerk limit being hit (due to a bogus jerk calculation really).

I guess you generated this using the latest PS right? I submitted a patch earlier this year to perform aggressive simplification which likely hits the case/resolution combo.

Please don't trash the settings ;), this is speed/height dependent

[vintagepc]

Correct 😄

[DRracer]

Yes, this is one thing we have to fix - this is entirely an error in the FW breaking several types of "smooth" print paths.

[vintagepc]

Yup.

What I find very interesting (and completely unrelated) is how some of these prints look a lot like those ChromaDepth 3d images that you often see for geography and topographic displays.. 😆