FWIW, it was just something I put together for quick experimentation with PA and S-Curves. Alas, the results were not what I thought I may achieve, so I abandoned it for now. If you post the GCode you was printing, I could take a look, cause otherwise I cannot really reproduce the issue, and my code has quite a few rough edges that could potentially cause problems. But I’m not sure if you should be using that branch for long-term. So, is it beneficial somehow?
I was a fan of scurve when you first implemented way back and I liked that the stepper motors while printing seem quiet and printer smoother not a scientific answer.
I wasn’t sure if it was ok to use but had to have a play hehe.
Thanks for you work but from what you have said I will just leave it alone.
If you feel like it, you could give a try to ‘input smoothers’ implemented in my advanced-features branch. Unlike regular discrete input shapers, they are polynomial smooth functions, and so they may provide a similar-to-s-curve acceleration profile, although not exactly the same, since they have fixed timing rather than S-Curve spanning the whole acceleration/deceleration. These smoothers are somewhat more effective vs corresponding discrete input shaper (though give a tad more smoothing). Alas, they are more expensive computationally, so I’d say RPi3 is a minimum required hardware (e.g. runs fine on Ender 3 up to speeds ~250 mm/sec with 127 msteps on RPi3b+), but ideally RPI4/OrangePi4/etc. There’s some support for them in scripts/calibrate_shapers.py in that branch for better overview of what’s available.
They can be configured similarly (though smoother_freq_? parameter isn’t exactly the same as before - it corresponds to the minimum frequency that the smoother cancels, or, more precisely, equals to the smallest frequency of the pole it cancels; this makes a difference for smooth_ei and smooth_2hump_ei for instance; hopefully, it is more straightforward that way):
I finished a print with no issues.
Anecdotally I would say it is similar to what I recal s-curve was like, I have the voron sitting on a Ikea Lack table which is far from solid so any harsh movement in the printer rocks the table like a boat in the ocean.
I noticed when doing solid infil over short distances normally the table was be rocking back and forth but with your branch it is stable or moving ever so slightly.
I will be doing some more prints over the next few days hopefully so I will keep you up to date if any problems arise.
I have been printing quite a lot, printed parts for a voron 2.4 for a family member and their friend been no issues until now.
I have been using SuperSlicer but thought I would try Orca Slicer pretty much used Orca’s Voron 2.4 preset with Arc’s enabled.
38min into the 7h print hit timer too close
Enclosing log and gcode just incase there is something of interest to @dmbutyugin klippy.zip (2.3 MB) pcb_klicky-side-mount_ABS_7h2m-ORCA.zip (7.5 MB)
and around that failure time, it actually reached over 100%. So I imagine that maybe host isn’t up to the task here. I’d say for smooth input shapers RPi3 is a bare minimum, but probably only so-so, and RPi4 is the minimum recommended. Worst case, perhaps you could reduce ‘G-Code resolution’ a bit (the parameter itself needs to be increased, at least in Prusa Slicer) and/or resolution in [gcode_arc]. I see that you gcode uses G2/G3 commands for infill apparently. And I super-basically estimated based on what the slicer preview says that your gcode has ~30-60 commands per second execution rate. That’s not ridiculously high, but it isn’t a small gcode rate either, and that includes G2/G3 commands which have their own segmentation, and bed_mesh, which additionally splits gcode moves.
Then, I see that the MCU bandwidth utilization is also rather high:
I am using a Pi4 and a Fysetc Spider STM32F446 USB connected.
Interesting I have never used Orca slicer before or Arcs so maybe a double whammy I ticked Arcs in Orca out of curiosity.
I went back to Superslicer and sliced the same stl’s and it printed without issue I don’t use Arc in Superslicer.
I checked the files size SuperSlicer is about half the size of Orca Slicer, I will certainly have to look at the settings in Orca Slicer if I was going to used it again which I am not keen on it was more of a curiousity factor.
This is the first time I’m hearing about this and it sounds super interesting.
Does anyone have photos of example prints to sort of show differences? Right now the only thing tangible for laymen is that it lessens the need for heavy PA.
Well just because they are not known to you does not mean they do not exist for your info - Bambu Labs Slicer, Orca slicer which is a fork of Bambu labs not Superslicer and Superslicer and there is more then likely other but those 3 all are capable slicers with options of producing G2/G3
I have not use Octobloat for a very long time been a user of Klipper since 2017 and as soon as there was a alternative to Octobloat I jumped ship. So no I dont use Octoprint or ArcWelder
As above OrcaSlicer is a fork of Bambu labs Slicer. variation of slicers have a habit from time to time of adding a lot of somewhat useless gcode commands that just overload the gcode stream and in the case of Orcaslicer you might want to look at this example of way too many fan speed changes
but the point of saying that the gcode was half the size was that possibly that Ocra Slicer was allready less effcient in the slicing but ading G2/G3 gcode was not a good idea on my side.
I appreciate your help but maybe a little research first would be more helpful.