Kolejny temat o: elektronikach 8 bit vs 32 bit, niedokładności mikrokroku

[FlameRunner]

No to jak to w końcu jest z okręgiem o średnicy 100 mm i segmentami 1 mm @ 120 mm/s na sekundę w kartezjańskim sterowanym zwykłym MEGA2560?
Będzie wszystko jak należy?
Nie osiągniemy takiej szybkości, bo przyśpieszenie 2000 mm/s^2 to za mało?
Szybkość jest osiągalna, ale drukarka będzie regularnie "przystawać i namyślać się"?

Załączam STL testowy.
Graniastosłup prawidłowy o podstawie 314-kąta foremnego wpisanego w okrąg o średnicy 100 mm.
Długość segmentu: 1.00049
Obwód wielokąta: 314.154

[grawires]

Czytam te pierdoły i czytam... sprawdzam UMO i nadal jest tam mega (w um2 też) i mimo tego drukarka leci 100mm/s w warstwie 0.1 bez zająknięć. Jakość większość widziała na targach. Oczywiście przyszłością jest 32-bit, ale nie róbmy jaj, 8-bit w drukarkach się sprawdza i sprawdzać będzie. Szczególnie kiedy nie będziemy używać wypasionych wyświetlaczy, tylko będziemy po prostu drukować.

Nie wiem czy nawet UM3 nie stoi na 8 bitach Tyle że z jakimś dodatkowym Linuxowym minikomputerkiem odpowiedzialnym za peryferia

[Berg]

Poczytaj sobie co to quadstep,(...)

Tak się wbiję, bo temat mnie zainteresował.
Jeśli dobrze zrozumiałem, to polega to na generowaniu kilku impulsów pod rząd żeby przyspieszyć jazdę. Dobrze rozumiem? Bo jeśli tak, to jest to...żenada. Najpierw wymiana stepsticków żeby kroki był równe, a potem program generuje po dwa.

Ileż energii ludzie ładują w rozwiązywanie problemów które sami sobie tworzą. Ciekawe tylko po co.

Domyślnie w konfiguratorze Repetiera jest quad stepping włączony. I tak mi Vertex działa. Wyłączyłem kiedyś i starałęm się odnaleźć jakieś artefakty wynikające z hipotetycznej niedokładności. Nie znalazłem.
Teraz w HC go wyłączyłem bo nie miał sensu.

[Berg]

Czytam te pierdoły i czytam... sprawdzam UMO i nadal jest tam mega (w um2 też) i mimo tego drukarka leci 100mm/s w warstwie 0.1 bez zająknięć. Jakość większość widziała na targach. Oczywiście przyszłością jest 32-bit, ale nie róbmy jaj, 8-bit w drukarkach się sprawdza i sprawdzać będzie. Szczególnie kiedy nie będziemy używać wypasionych wyświetlaczy, tylko będziemy po prostu drukować.

poprawcie mnie jeśli się mylę. Czy Prusa czasem nie dawał przez jakiś czas 32 bitów a teraz z powrotem 8 ?

Ja się skłaniam do AVRów i 8 bitów. Tanio i solidnie, pada, wymieniam bez bólu. A peryferia, najlepiej na drugiej płytce, tak jak np graficzny wyświetlacza MKS z wifi, octopi itp.

Nawet przez chwilę się zastanawiałm czy nie było by fajnie jeszcze bardziej rozdzielić i prosty "motion-controller" na jednym np RAMPSIe
Albo bardziej programowalne stepstiki z buforem komend na poj. silnik i wspólnym zegarem do synchronizacji.

[grawires]

No to jak to w końcu jest z okręgiem o średnicy 100 mm i segmentami 1 mm @ 120 mm/s na sekundę w kartezjańskim sterowanym zwykłym MEGA2560?
Będzie wszystko jak należy?
Nie osiągniemy takiej szybkości, bo przyśpieszenie 2000 mm/s^2 to za mało?
Szybkość jest osiągalna, ale drukarka będzie regularnie "przystawać i namyślać się"?

Załączam STL testowy.
Graniastosłup prawidłowy o podstawie 314-kąta foremnego wpisanego w okrąg o średnicy 100 mm.
Długość segmentu: 1.00049
Obwód wielokąta: 314.154

Tak. Drukuję co prawda nie twój ale praktycznie taki sam model tyle że niższy. W S3D ustawione 100mm/s. Przy podkręceniu feedrate do 115% czyli 115mm/s jest jeszcze ok. Przy 120mm/s i więcej - czkawka. Nadmieniam raz jeszcze że nie drukuję na kartezjańskim tylko corexy + stale pracująca oś Z.
Tylko o co jest ten cały dyskurs? Sprostowałem już wcześniej co miałem na celu przytaczając przykład okręgu, nie był to konkret ani zaproszenie do badań empirycznych. Użyłem tam słowa "powiedzmy" aby dać przykład. Jak już sprawę mamy wyjaśnioną czyli 120mm/s da się uzyskać przy tym naszym przykładowym okręgu z odcinkami 1mm to wrzuć na ruszt ot choćby to:
https://www.thingiverse.com/thing:2423723/
Prędkość 100mm/s, zryw 20, przyspieszenia 2000.
Podgoń zrywy do 50, przyspieszenie do 6000 i miłej zabawy feedratem który nic już nie zmienia Z g**na bata nie ukręci.
I podkreślę po raz kolejny - 8 bit mi pasuje, bo realnie nie często drukuje się z prędkościami >100mm/s. Mimo to przy bardziej złożonych modelach ciężko osiągnąć założone parametry bo mocy obliczeniowej mało.

W każdym razie wciąż czekam na jakieś sensowne 32bity. Testowałem 2 rozwiązania i nie przypadły mi do gustu (Lerdge oraz mks sbase). Zbyt mała możliwość konfiguracji (zamknięte źródła). W przypływie wolnego czasu zainteresuję się smoothie tyle że na 32 bitach o ile się nie mylę mogę zapomnieć o I2C więc musiałbym przerabiać cały kontroler wyświetlacza i pewnie sam wyświetlacz

Ja się skłaniam do AVRów i 8 bitów. Tanio i solidnie, pada, wymieniam bez bólu. A peryferia, najlepiej na drugiej płytce, tak jak np graficzny wyświetlacza MKS z wifi, octopi itp.

Mi na tą chwilę również bardziej pasują 8bit. Szkoda jednak że przy chęci rozbudowy trzeba się wspomagać właśnie rozwiązaniami typu raspi+octopi, z kolei wyświetlaczy mks bez napisania kodu od podstaw nie da się przerobić do własnych potrzeb. Dobrze by było mieć coś "all-in-one"

[dragonn]

MKS SBASE jest przecież na smoothieware. BTW Zobacz sobie Re-ARM, szczególnie ciekawe że nowy Marlin ma działać na tej płytce.

[Berg]

MKS SBASE jest przecież na smoothieware.

https://pl.aliexpress.com/item/MKS-Mini ... 87017.html

BTW Zobacz sobie Re-ARM, szczególnie ciekawe że nowy Marlin ma działać na tej płytce.

Fajne, tylko możliwoście RAMPSa mi się skończyły. mało sterowania wentylatorami, o jedno gniazdo silnika za mało.

Spoko jest ten RAMPS-FD, chyba najtańsze 32bity i to na wypasie. Koledzy elektronicy tu, zamiast wymyślać nowe płytki wziął by ktoś poprawił tego RAMPSa-FD i zrobił wersję 2.0.
kilka prostych rzeczy trzeba poprawić, wiadomo co i będzie projekt znany na świecie