Gyroid Infill Requested Speed != Actual



  • I've high speeds set on my infill that were easily achieved with infills such as slic3r rectilinear, grid, and aligned. I've now chamged to the gyroid and notice that my current acceleration and instant speed settings leave that target speed unobtainable. Is there lilely to be any issue running like this? A mechanical sympathy makes me want to pick an infill speed that gives a little constant speed between the accelerations but aware I may be wasting my time a little?



  • With gyroid you have constant acceleration and deceleration instead of straight lines with slic3r hence the slower speed. There will be no issues running like that until the end of times.



  • I prefer cubic infill for this reason. Straight lines and better connections between layers. Gyroid seems like a fad to me. It’s cool but to what benefit?



  • @Phaedrux said in Gyroid Infill Requested Speed != Actual:

    I prefer cubic infill for this reason. Straight lines and better connections between layers. Gyroid seems like a fad to me. It’s cool but to what benefit?

    While I don't know if the rumored strength increases are true are not, I've found that using a gyroid infill with translucent filaments is really amazing cosmetically.

    As for print speed, if the duet is simulating speeds properly, just slice the same model twice: once with gyroid infill and once with some other infill, and then compare the simulated print times. I've found that for more smaller models, the difference is extremely minor.



  • junction deviation or jerk are the parameters that affect gyroid much more than acceleration so experiment with increasing them.. it depends on the machine but on my "light" machines the junction deviation can be set to a very high value without issues with ringing and gyroid can be as fast as linear infill with added strength .. on some heavy not that stiff machines high junction deviation introduce too much ringing and on them gyroid is not very useful ...

    now this is smoothieware based info (as most of my printers are smothieware, I just recently started converting single printer to duet) so I don't know if RRF is using junction deviation (like big CNC mills, cutters, lathes; like smoothieware..) or is using jerk (like grbl based engravers, 3d printers; like marlin...) or is using some 3rd system I don't even know about... in any way it comes to "speed trough corners" all these "path finders" with or without "look ahead" calculate the speed change between two straight lines based on the angle between those two lines so for e.g.

    if you print a line A from A' to A" speed in A' point and A" point is 0mm/sec, it will accelerate using your acceleration settings till set speed and than deccelerate to stop in point A" if line is short you might not reac set speed and you will start to decelerate before you reach it. Depending on firmware implementation usually if you do not reach set speed by the middle of the move you start decelerating at the middle of the move.

    for some "50% value" (however that is defined in any firmware / system) when you have line B printing after line A and line B is "continuing" line A so angle between A and B is 180° there is no "change in direction" the speed in A"B' will be whatever max was machine able to reached before it. So if the "full move" is A+B that speed in A' is 0 and B" is 0 and A"B' is whatever it would be if move was A'-B", but if B is on 90° angle to A you have 90° change of direction and speed in A"B' will now be 1/4 of set speed so let's say that both A and B are long enough and that acceleration is high enough that you can reach the max/set speed in both A and B move you start 0 at A', you accelerate to SET, move at set speed for a while, you decelerate to SET/4 at A"B', you then accelerate to SET, move at set speed for a while, decelerate to 0 at B" ...

    now depending on the system, note that this require "look ahead" so you have to have in buffer the next g-code in order to know how to perform current one (you don't want to decelerate to 0 but to value depending on angle of the future move) and can get more complicated than this, instead of looking at only current and next move the length of the current and next move can come to play and if next move is short (think circle) it can look further than one move ahead ...

    no clue about how RRF2/RRF3 handles any of these 😄 but in any way, this is how things work in general so that gives you an idea how to configure your slicer.

    what I like to do is up the speed through corners as much as the machine can handle for the infill's and supports and drop the speed trough corners to a crawl for outlines. make sure not to lower it too much as at some point slowing too much at corners will give you blobs, zits and other artefacts



  • @garyd9 said in Gyroid Infill Requested Speed != Actual:

    rumored strength increases

    it depends, I did some measurements and found that for me gyroid is not as strong as others but that's mostly cause I print it super fast so it's not laid down properly, uneven extrusion, untrue position.. but if I print it slow and nice (same setting as for perimeter) than it is stronger... hexagon is still stronger for me in XY .. but all these changes are so superficial and not very reproducible .. I for e.g. did almost same tests one of the YT guy's did and got totally different results using similar (and in some cases really professional compared to his diy) equipment... so tad different filament, different settings, different slicer, different ambient and you get totally different results ..

    I use gyroid for speed, as for same amount of bridging a top layer need to do over support I print gyroid much faster than hexagon for e.g. ... and that's important for me as PETG on my printers bridge like shit 😞 so big bridges are not something I love, and high temp materials in high temp chamber don't bridge at all so instead of getting more solid layers I increase infill ...



  • Gyroid is old news apparently. All the cool kids are rocking Schwarz P now.

    https://community.ultimaker.com/topic/30456-new-infill-patterns-in-experimental-cura-builds/



  • I am officially an old fart .... no interest in exotic looking infill stuff! Heck, I'd be happy if 4.4 would work properly with two configured printers 😞



  • @Phaedrux said in Gyroid Infill Requested Speed != Actual:

    Gyroid is old news apparently. All the cool kids are rocking Schwarz P now.

    https://community.ultimaker.com/topic/30456-new-infill-patterns-in-experimental-cura-builds/

    Schwarz P is very slow to print because it consists of disconnected loops. Schwarz D is more like gyroid in that it is made from wavy lines. I implemented them because someone wants to do some comparative testing of TPMS infills.



  • Choice of infill is bordering on irrelevant on the concern I was trying to cover.

    Regards acceleration, dynamic acceleration adjust, and instant speed settings they are determined by my personal tolerance to artefacts such as ghosting and ringing.

    Rephrased; when a path or geometry type has no potential of reaching the requested speed are there detrimental effects to be expected from the constant cycle of jerk, acceleration, deceleration, jerk, repeat? In order for the material metering to be accurate how far are your margins for the setting of pressure advance, extrusion corrections, extrusion multiplier? (Edit: Are you reducing the tolerance on suitable setting values for your parameters before you start to see detrimental build issues)

    Regards simulation it isn't accurate for me. See one of my other threads. However, I would hope that whatever the error is in the simulation or print I would be able to scale back the infill speed and note at what point the simulation time increases.

    So predicting what speeds are attainable based on instant speeds and acceleration values is fairly straight forward. Is there an easy way of calculating how much steady velocity would be needed for the pressure advance to stabilise after acceleration before needing to adjust for the oncoming deceleration?


Log in to reply