When performing a "Gap Fill" without a reduction, the head may violently shake left to right. For a machine with a light bowden extruder this isn't much of an issue. But on any machine with one or more direct drives. There is far more torque. Not only does this require more powerful motors, but also better drivers, to avoid loose of tracking. Say that loss of tracking isn't an issue, the machine is vibrating itself apart in the process. (edit: Marlin 2.1.x firmware has a function now to reduce high speed vibration from zig zag movements) Honestly, I hate Gap fill. When I see gap fill, its like the pathing tool could not have been bothered to Finnish it's job and left a hole for no good reason. Now it remains a hole or the machine becomes a jack hammer every time I need to fill it in.
Another good reason for some kind of dynamic reduction of speed.
Take a circular pattern. Start the outer perimeter. Speed is set to F1800, and it's working really great.
But with each line, As the head gets closer the the middle, the machine starts shaking as the revolutions per min is increasing, though the speed of the line is drawn remains the same. Get the picture? It takes less and less time to create each loop, not only causing vibration but also reducing the amount of time the line has to cool, increasing the over all temp of the material in that area.
There are many other great reasons to have some kind of dynamic speed reduction.
This is a function that must be implemented in the slicing engine.
Edit: Using S3D as it is: Unlike per layer where I can simply generate a new FFF. This cannot be done within a layer. Not without a separate object. So if I was to make a solid cylinder. I would need to use my modeler to break it down into multiple objects. Each can have its own print speed. Its a manual way of forcing the slicer to reduce the speed of the head as the radius decreases. I really need the support of S3D on this. But given the silence. I feel like the request is simply being regarded as a joke. I see this as a powerful tool in the Swiss army knife that is S3D.
Dynamic reduction of speed
Last edited by rflulling on Sun Nov 05, 2023 11:25 am, edited 1 time in total.
Re: Dynamic reduction of speed
Thanks for your request! It sounds as if you're more interested in disabling gap fill than reducing the speed of your prints. You can have gap fill omitted by changing your internal fill type to perimeters only. This will fill the section when it's able to fit another perimeter. It will also print at a slower speed than gap fill.
"A bird does not sing because it has an answer. It sings because it has a song."
Re: Dynamic reduction of speed
There is a time and place for the gap filling. I am not a fan of it as it is. However there are times when S3D refuses to fill any other way. Even when the extruder could produce one more line, or even dynamically reduce the extrusion width.
Perhaps another Feature quest is an over stitch of gap fill. That is where a gap fill is less than two extrusions wide and the engine has determined that a the head should use a left to right stitch pattern. Then the Extruder could produce an optional pattern where the head crosses the gap at a 90deg angle, and the fill is only deposited over the gap. The head continues over the previously extruded lines, causing some of the new material to over lap and merge. This is repeated over the area producing a stitch rather than a simple fill.
Regardless. If all things remain the same, having a dynamic throttle built in that says when a line is less than X reduce speed. Perhaps this can be done logarithmic. Max to min, and down steps determined by segment length regardless of function. Maybe a filter that looks at everything that's already been done by the primary engine, and ignoring user script. Says ok, based on the filter the following areas are moving to fast and require a reduction. Extrusion remains the same, but speed is reduced slightly to eliminate jerking and excessive vibrations.
Another user hated this behavior so much, that he separated his Direct extrude into a head that followed the extruder, but then also created a counter balance head that offset the motion of motors and the heads.
The only thing I can do right now is keep speeds very low. Adding this system would allow me to increase over all speeds. I could very easily create a video of exactly the behavior I need throttled. I think this could be dealt with far easier in the slicer than the Firmware. Though the firmware already tries to deal with similar issues, such as sudden changes in direction.
Perhaps another Feature quest is an over stitch of gap fill. That is where a gap fill is less than two extrusions wide and the engine has determined that a the head should use a left to right stitch pattern. Then the Extruder could produce an optional pattern where the head crosses the gap at a 90deg angle, and the fill is only deposited over the gap. The head continues over the previously extruded lines, causing some of the new material to over lap and merge. This is repeated over the area producing a stitch rather than a simple fill.
Regardless. If all things remain the same, having a dynamic throttle built in that says when a line is less than X reduce speed. Perhaps this can be done logarithmic. Max to min, and down steps determined by segment length regardless of function. Maybe a filter that looks at everything that's already been done by the primary engine, and ignoring user script. Says ok, based on the filter the following areas are moving to fast and require a reduction. Extrusion remains the same, but speed is reduced slightly to eliminate jerking and excessive vibrations.
Another user hated this behavior so much, that he separated his Direct extrude into a head that followed the extruder, but then also created a counter balance head that offset the motion of motors and the heads.
The only thing I can do right now is keep speeds very low. Adding this system would allow me to increase over all speeds. I could very easily create a video of exactly the behavior I need throttled. I think this could be dealt with far easier in the slicer than the Firmware. Though the firmware already tries to deal with similar issues, such as sudden changes in direction.
- Attachments
-
Re: Dynamic reduction of speed
If we can work this issue out now, or if it can be available in 5.0, then I can shift focus to developing a new extruder for myself. For now the Direct drives are fast enough, as 5mm per second extrude rate is far above were this machine can operate. Anything even remotely close to that speed and the jitters would start making screws break loose.
With a dynamic reduction in place where the slicer is able to allow greater speed or reduce it as part of the code, more effectively than now, I could start testing speeds up 70 maybe even 100mm/second movement rates. I could do this knowing that even as the machine runs at 100mm/s over larger areas, it will slow down for small details and fill.
I also want to define, this is not a request for some kind of breaking mechanism.
With a dynamic reduction in place where the slicer is able to allow greater speed or reduce it as part of the code, more effectively than now, I could start testing speeds up 70 maybe even 100mm/second movement rates. I could do this knowing that even as the machine runs at 100mm/s over larger areas, it will slow down for small details and fill.
I also want to define, this is not a request for some kind of breaking mechanism.
Re: Dynamic reduction of speed
Bump: To renew my interest in this feature request.
Dynamic reduction of speed
Marlin employs several strategies to limit deceleration or deceleration, however for the most part, they end up having to much or two little effect. Sudden changes in direct. These are effective on every layer and ever line equally only regarding the distance to the end of a line, which can often lead to unintended consequences since the Firmware cannot see the whole picture. But a slicer can.
In addition, what is typically employed is a strategy to look at the time to print a layer, and make reductions if a layer might print to fast, or if the buffer empties to fast.
One option is to simply change the values of the functions on the fly. Such as G1 F(nnn), Jerk M205, Acceleration M204, and or Max Feed M201.
A way to describe what I am asking for is to say that while the Firmware will account for sudden changes in direction such as a linear infill. It doesn't do much to anything for a reducing the speed of a constant line, like an arc. This means objects that use a concentric or cubic/circular infill will move at the same speed at outer lines versus shorter inner lines. It takes maybe the same amount of time to printer the inner 80% as it did to print the outer 20% lines on a layer.
What I have done to bridge the gap is to create a unique FFF that only prints a specific area of a layer or layers, with specific infill or skin and the the scripting function is used to update the Firmware behavior at the start of the Layer. But it would be far simpler and far more effective to be built into the FFF.
Though it would also be useful to add some tools to determine how the gradient is defined so that each ring is reduced in speed proportional to the length of the line without impacting extrusion, and maintaining a smooth finish per layer.
Dynamic reduction of speed
Marlin employs several strategies to limit deceleration or deceleration, however for the most part, they end up having to much or two little effect. Sudden changes in direct. These are effective on every layer and ever line equally only regarding the distance to the end of a line, which can often lead to unintended consequences since the Firmware cannot see the whole picture. But a slicer can.
In addition, what is typically employed is a strategy to look at the time to print a layer, and make reductions if a layer might print to fast, or if the buffer empties to fast.
One option is to simply change the values of the functions on the fly. Such as G1 F(nnn), Jerk M205, Acceleration M204, and or Max Feed M201.
A way to describe what I am asking for is to say that while the Firmware will account for sudden changes in direction such as a linear infill. It doesn't do much to anything for a reducing the speed of a constant line, like an arc. This means objects that use a concentric or cubic/circular infill will move at the same speed at outer lines versus shorter inner lines. It takes maybe the same amount of time to printer the inner 80% as it did to print the outer 20% lines on a layer.
What I have done to bridge the gap is to create a unique FFF that only prints a specific area of a layer or layers, with specific infill or skin and the the scripting function is used to update the Firmware behavior at the start of the Layer. But it would be far simpler and far more effective to be built into the FFF.
Though it would also be useful to add some tools to determine how the gradient is defined so that each ring is reduced in speed proportional to the length of the line without impacting extrusion, and maintaining a smooth finish per layer.
Re: Dynamic reduction of speed
Edit: Looking over 5.0.0 and 5.1.2, I have realized part of this may have already been addressed. Not as in depth as I was asking but, at the very least it is on the same page. I might well be able to use the High Flow rates reduction tool in a very similar way.
I also note that some of the dynamic function I was asking for are included on the speed page. However I do not know if they are used in the way as I have hoped or if they are simply per FFF values. It would be really nice to see these as ranges that take effect based on behavior and criteria. Still, I had not thought to base a speed reduction on flow rates. Yet all of these tools seem to be either in the ON or OFF state, versus Dynamic. I am glad see they are included all the same.
I also note that some of the dynamic function I was asking for are included on the speed page. However I do not know if they are used in the way as I have hoped or if they are simply per FFF values. It would be really nice to see these as ranges that take effect based on behavior and criteria. Still, I had not thought to base a speed reduction on flow rates. Yet all of these tools seem to be either in the ON or OFF state, versus Dynamic. I am glad see they are included all the same.
Re: Dynamic reduction of speed
Finally starting to get some solid results with V5. I am able to test changes, for better, for worse.
One I can report does seem to be for better is what does seem to be the inclusion of a function that is behaving very much as requested. Though as far as I know this was never marked as a planned inclusion.
I can see as the radius of the circle gets smaller, there is a marked decrease in RPM. If this were to remain constant the motor would continue to spin faster and faster into the center was reached. At least from our perception would be faster since each circle would take less time to lay, at the exact same print rate. - Since this observation also followed a Firmware bump, there is a chance it is tied to firmware behavior. But as far as I know, it is not.
I wonder if this is linked to Reduce speed for short perimeters, since I use the perimeter multiplier as a way to create controlled and uniform concentric infill.
For certain this is not high flow rate or a quick layer.
-This would linked successive lines or arcs, where is there is no reversal or change in direction greater than 72Deg.
One I can report does seem to be for better is what does seem to be the inclusion of a function that is behaving very much as requested. Though as far as I know this was never marked as a planned inclusion.
I can see as the radius of the circle gets smaller, there is a marked decrease in RPM. If this were to remain constant the motor would continue to spin faster and faster into the center was reached. At least from our perception would be faster since each circle would take less time to lay, at the exact same print rate. - Since this observation also followed a Firmware bump, there is a chance it is tied to firmware behavior. But as far as I know, it is not.
I wonder if this is linked to Reduce speed for short perimeters, since I use the perimeter multiplier as a way to create controlled and uniform concentric infill.
For certain this is not high flow rate or a quick layer.
-This would linked successive lines or arcs, where is there is no reversal or change in direction greater than 72Deg.
Re: Dynamic reduction of speed
Yes, V5 added the ability to print short perimeters using reduced speeds. It's helpful for small holes, embedded text, or anything similar.
You can see the new feature described in the "Targeted Build Customizations" section of the V5 announcement page. It's also mentioned in the release notes.
https://www.simplify3d.com/products/sim ... rsion-5-0/
If you set the preview to Movement Speed coloring, it should be easy to see that this setting is having an effect.
You can see the new feature described in the "Targeted Build Customizations" section of the V5 announcement page. It's also mentioned in the release notes.
https://www.simplify3d.com/products/sim ... rsion-5-0/
If you set the preview to Movement Speed coloring, it should be easy to see that this setting is having an effect.
Re: Dynamic reduction of speed
So to be clear, this is specifically the perimeter speed reduction?
-I see nothing that says this should effect any other aspect of printing including infill.
-and to be fair the the only thing in the PR, is a tiny one line comment as part of a graphic.
Regardless, based on how I do my work, this is working for now.
---
Another related issue:
So while a dynamic reduction of speed is needed for concentric or perimeter reduction has been addressed.
Then comes the other types of dynamic speed reduction.
Marlin employs a ZigZag speed reduction, and Competing functions known as Junction Deviation and Jerk.
I generally keep them both disabled since they can create artifacts when doing work with vase mode, by causing speed up and speed down when I want constant speeds. However, there is a time and place for those behaviors even if the firmware versions are disabled.
My machine can easily lay at 82.5mm/s. I would like a way that I can enable and disable these functions from per FFF. This can be via a S3D variant or a by a direct command to the firmware adjusting the settings. Both options work.
-I see nothing that says this should effect any other aspect of printing including infill.
-and to be fair the the only thing in the PR, is a tiny one line comment as part of a graphic.
Regardless, based on how I do my work, this is working for now.
---
Another related issue:
So while a dynamic reduction of speed is needed for concentric or perimeter reduction has been addressed.
Then comes the other types of dynamic speed reduction.
Marlin employs a ZigZag speed reduction, and Competing functions known as Junction Deviation and Jerk.
I generally keep them both disabled since they can create artifacts when doing work with vase mode, by causing speed up and speed down when I want constant speeds. However, there is a time and place for those behaviors even if the firmware versions are disabled.
My machine can easily lay at 82.5mm/s. I would like a way that I can enable and disable these functions from per FFF. This can be via a S3D variant or a by a direct command to the firmware adjusting the settings. Both options work.
