Check (and limit?) for too many segments / second in gcode

[Sebastianv650]

I know this would be an option not a lot of the normal user would use. Nevertheless, it would be very helpful:

At the moment, Slic3r has options to limit max. print speed and max. volumetric print speed. While the max. volumetric speed is a nice value which is determined by the hot end, there is another hardware specific speed limiter which isn't handled up to now and that can ruin the optical print quality: The amount of G1 segments in the gcode which can be processed the the printers controler.

While that's usualy not a problem for self-designed parts, it's a quite common problem in high-detail figures as they can be found on thingyverse and simmilar sites where the designer has sometimes limited knowledge about 3D printer limits. If an arc contains more segments per second than the printer can handle, it will start to stutter which always leads to visual imperfections. While a simple mechanical part can be printed at 100mm/s for example, a high resolution cylinder might fail at 70mm/s.

As nearly every 3D printer uses a 16Mhz Arduino, it would be also possible to define a default value in the profiles. A warning should be displayed if the sliced model contains more than x segments / second inside a layer, maybe together with a recommended speed where the value is not exceeded.

At the moment, I'm using a quick and dirty VBA script to check my gcodes before sending them to my printer. I'm trying to stay below 63 segments / second.

[bubnikv]

Funny thing, I received a similar request from Josef Prusa a week ago. My immediate response was: Show me the models first, and then let's find out how far is the firmware from managing to process the G-code without stuttering, then let's optimize the firmware by doing some magic like turning some hot spot into assembler, turning some floating point to fixed point arithmetic etc.

Your proposal certainly makes sense, only it does not seem trivial to implement it correctly. And I have to implement your improved supports first #612, right :-)

Would you please share your script?

[Sebastianv650]

While optimizing the FW is always a great thing, I don't think it will, say, double the speed. Some numbers: The ~63 segments / second are on my TAZ 5 with a graphical LCD (but no bed leveling matrix on the other side) and with printing over USB. From SD-Card printing faster is possible, but only about 10% more. I know from tests disabling the LCD completely also makes some %, maybe another 10%. Therefore, I guess it's not possible to tune the firmware to a point where I can print something at 120 segs/second which would equal maybe a 30mm cylinder in Fusion 360 at medium export quality and 100mm/s for example. By the way I don't need that speed at all as it's not changing print time much compared to the % of increased top speed, but as an end user you never know how many polygons are within an stl. That's why sometimes 50mm/s is already way to much.

I thought there might some usable code in the layer time / fan speed thing as you know the print speeds and times there already. But I guess it's not calculated using the gcode "points"? Of course, #612!! :-D No, just take everything like a sticky note with ideas. I know there are a lot things to do and everyone has different priorities.

Here is my quick and ugly thing, I realy had no plan showing it to anyone. I added some comments so it should be understandable. Insert it to an Excel module, change the path to an existing gcode file and run it: find_max_P_sec.txt Note it is full of limitations, I wanted a quick result to check my gcode files on one evening:

• Will crash if there are more than 200segs/s due to fixed array size.
• Will only count G1 moves with X and Y coordinates. Others will be droped. No Z move taken into account.

By the way, the Print Settings -> Advanced -> Resolution setting is a very useful thing to fight insane detailed stl files to keep segments/ s in a useful area. I noticed that most users don't understand it's function or even think it's broken. Maybe if some segments/s check is in place, a better explaination (maybe with example presets high/medium/low) would be a good next step to give the users another work around than reducing speed too much. Not everyone is able to load the stl into Meshmixer and remesh it.