Odkopię trochę temat, tutaj ciekawa rzecz wychodzi https://forum.duet3d.com/topic/5951/per ... ringing/40
Wychodzi na to że w teorii większa prędkość wcale nie musi oznaczać większego ghostingu.
I tu https://forum.duet3d.com/topic/2629/s-c ... eration/24

slicer żaden nie implementuje akceleracji czy hamowania, ustawień tego trzeba szukać w firmware ale jedyny co dotychczas widziałem co umożliwiał ustawienie osobnej wartość deakceleracji to był klipper.

Myślę że chodzi CI o to że wraz z spadkiem prędkości silnik krokowy zaczyna pracować co raz bardziej "krokowo" niż płynie co nie?
To jest łatwo do sprawdzenia, odpal wydruk z prędkością 5-10mm/s i jerk 0, jak będzie echo to znaczy że faktycznie silnik coś powoduje. Chociaż jestem przekonany że nic takiego nie będzie.

McKee pisze:Przecież tam też trzeba podawać coraz mniejsze napięcia a silnik krokowy "nie potrafi" hamować "analogowo" tylko robi kroki (fale?).

Tutaj muszę Cię poprawić - przy zwalnianiu silniku krokowego nie ma żadnego "zmniejszania napięcia":
- po pierwsze silnik krokowy sterowany jest prądem nie napięciem
- po drugie prąd ten jest stały kompletnie nie zależenie od prędkości, gdyby nie inteligencja driverów to nawet przy zatrzymaniu silnika byłby taki sam jak przy ruchu na pełnej prędkości.
Sterowanie silnikiem krokowym odbywa się poprzez zmianę tego przez którą z dwóch cewek płynie prąd, im szybciej robimy tą zmianę tym szybciej silnik się kręci (pomijam działanie mikrokroku który rozkłada prąd pomiędzy obie cewki jednocześnie).

A co do Twojego PS. nie hamowanie nie jest robione na pełny krokach, soft drukarki tak naprawdę nie ma nawet wiedzy na temat tego czy leci po pełnym kroku czy po mikrokroku (dlatego w każdy sofcie kroki na mm podajesz po wzięciu pod uwagę mikrokroku, zazwyczaj nawet nie ustawia się mikrokroku).

Czy więcej energii to taki problem? Wydaje mi się że bardziej istotne jest to ile pasek się rozciągnie, ilość energii w to włożona ma drugorzędne znaczenie. A nie mówcie mi że pasek szerszy się bardziej rozciąganie od wąskiego, to tak jak sprężyna o grubszych zwojach.

Nie zgodzę się tylko z jedną rzeczą. Moim zdaniem zmienianie rezonansu "elementu" wcale nie jest złą metodą, wiele elementów jest projektowanych tak żeby częstotliwości które mogą wpływać na nie nie powodowały ich rezonansu.

Marcin1415 pisze:Ja aktualnie walczę z pionowymi prążkami w osi Y (prusa steel). Z tego co zaobserwowałem to ważna jest sztywność konstrukcji, jakość sztywność prowadnic, wałków liniowych oraz rama z materiału który nie wpada w wibracje.

Ghosting =/= prążki.

skmskm pisze:Od biedy mam własny interpreter G-codu do rampsa 1.4, mógł bym go przerobić by dawał rampy typu S. Musze to przemyśleć jak to zrobić.

Na Atmege2560? Wydoli to z generowanie s-rampy?

skmskm pisze:Rampy typu S powinny zmniejszyć efekt. Efekt rośnie względem prędkości dojechania do rogu wydruku.

a to na pewno, niestety żaden soft tego nie ma. Rzuciłem pomysł i Klippera i tam jest jeszcze otwarty. Problem z rampami typu S jest taki żeby je tak zaimplementować żeby działy np. przy drukowani okręgów który składa się w naszym przypadku z wielu punktów po kolei.
https://github.com/KevinOConnor/klipper/issues/57
zacytuję:

I think one challenge to implementing s-curves would be proper
handling of lots of small moves. The current trapezoid generator can
seamless accelerate over many small moves, seamlessly cruise over lots
of small moves, and seamlessly decelerate over lots of small moves.
In effect, if one big long move is broken up into many small moves,
there is no adverse impact. This is a nice feature as current g-code
slicers tend to emit lots of tiny moves when handling arcs. Having
similar flexibility while using s-curves might be challenging.

No dla mnie teoria jak najbardziej jest ok! Piwo . Czekam tylko na rozwiązania problemu bo ja sam na podstawie teorii nic wymyślić nie umiem .