@dmbutyugin
I was using your scurve-pa branch which was going well but alas it had a hiccup at about the 5 hour mark.
I have included the log
any chance you may update your extr-is-compress branch?
Or if you have a branch you want tested let me know.
scurve-pa-klippy.zip (2.2 MB)
Cheers from
Australia
Hi! Any reason you were using that branch?
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):
[input_shaper]
shaper_type_x = smooth_ei
smoother_freq_x = 50
shaper_type_y = smooth_mzv
smoother_freq_y = 40
Thanks hopefully I will get time today to give it a try. if not today asap.
Cheers
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.
Cheers Mate.
I have done about 40 hours of printing with this branch the longest print being 15 hours and has been working great.
I had to reduce PA from 0.052 to 0.028
Great work
Cheers
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)
Thanks for reporting it. What kind of a host and an MCU board are you using? I see that you’ve got pretty high CPU load on the host:
[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.
Hello,
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.
Kind regards
I don’t know of any common slicer that produces arcs (G2/G3).
There is a plugin for OctoPrint that can generate arcs. That one can go into Cura as plugin too.
BTW: Do you run Klipper on OctoPrint with that certain plugin (ArcWelder) installed?
Keep in mind that slicers nowadays include images of the sliced object. That can increase the gcode file by some amount depending on how the settings for that image are.
OrcaSlicer is a fork or SuperSlicer. Pure gcode should not differ in size a lot.
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.
I work with OrcaSlicer and SuperSlicer and never found that feature. Can you give me a hint?
Please be respectful!
I still got no proof that these slicers produce G2/G3 from you.
nothing good will come of your entitled attitude, just to be clear I do not need to prove anything get off your entitled butt and look yourself!
I think I do not like the way you express yourself.
