już nievirgin71 pisze:W becie narazie.rafaljot pisze: btw: w Curze ostatnio dodali opcję, coś jak rozdzielczość w Slic3rze
Drukowanie przez wifi. część 1
- Berg
- Zasłużony
- Postów w temacie: 5
- Posty: 7570
- Rejestracja: 05 lis 2016, 11:57
- Lokalizacja: Kraków
- Drukarka: Lume, K8400, HC Evo
- x 2675
Re: Drukowanie przez wifi. część 1
Prusa i3 mk3s https://tinyurl.com/y65mva4m
Photon
Velleman Vertex K8400x2 https://tinyurl.com/y55pnudv
HyperCube Evolution ST 250 https://tinyurl.com/y36cexyw
Anycubik Kossel Plus https://tinyurl.com/y5ybrh8v
K40 https://tinyurl.com/y3gzdnbg
MD-16 https://tinyurl.com/y4lz6bpf
CNC https://tinyurl.com/y5ku9jf2
Photon
Velleman Vertex K8400x2 https://tinyurl.com/y55pnudv
HyperCube Evolution ST 250 https://tinyurl.com/y36cexyw
Anycubik Kossel Plus https://tinyurl.com/y5ybrh8v
K40 https://tinyurl.com/y3gzdnbg
MD-16 https://tinyurl.com/y4lz6bpf
CNC https://tinyurl.com/y5ku9jf2
- artur_n
- Postów w temacie: 5
- Posty: 984
- Rejestracja: 20 lis 2017, 21:48
- Lokalizacja: RJA
- Drukarka: Prusa MK4, P1S AMS
- x 181
Re: Drukowanie przez wifi. część 1
Co robię źle?
Kod: Zaznacz cały
Opcje projektu zmienione, przeładuj całość
sketch\config.cpp: In static member function 'static bool CONFIG::InitBaudrate()':
config.cpp:94: error: 'class HardwareSerial' has no member named 'baudRate'
if (ESP_SERIAL_OUT.baudRate() != baud_rate)ESP_SERIAL_OUT.begin(baud_rate);
^
config.cpp:96: error: 'class HardwareSerial' has no member named 'setRxBufferSize'
ESP_SERIAL_OUT.setRxBufferSize(SERIAL_RX_BUFFER_SIZE);
^
sketch\config.cpp: In static member function 'static bool CONFIG::check_update_presence()':
config.cpp:1013: error: 'class HardwareSerial' has no member named 'baudRate'
if (ESP_SERIAL_OUT.baudRate() != baud_rate)ESP_SERIAL_OUT.begin(baud_rate);
^
sketch\config.cpp: In static member function 'static void CONFIG::print_config(tpipe, bool)':
config.cpp:1412: error: 'class HardwareSerial' has no member named 'baudRate'
uint32_t br = ESP_SERIAL_OUT.baudRate();
^
Znaleziono wiele bibliotek w "ESP8266WebServer.h"
Wykorzystane: C:\Users\artur\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0-rc2\libraries\ESP8266WebServer
Niewykorzystane: C:\Users\artur\OneDrive\Documents\Arduino\libraries\WebServer
Niewykorzystane: C:\Program Files (x86)\Arduino\libraries\WebServer
Znaleziono wiele bibliotek w "DNSServer.h"
Wykorzystane: C:\Users\artur\OneDrive\Documents\Arduino\libraries\DNSServer
Niewykorzystane: C:\Users\artur\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0-rc2\libraries\DNSServer
Niewykorzystane: C:\Program Files (x86)\Arduino\libraries\DNSServer
exit status 1
'class HardwareSerial' has no member named 'baudRate'
-
- Konto z ograniczeniami
- Postów w temacie: 2
- Posty: 489
- Rejestracja: 06 lut 2018, 18:38
- Lokalizacja: Warszawa
- x 74
- Kontakt:
Re: Drukowanie przez wifi. część 1
A ja się odniosę po części do podobnej sprawy... i teraz tak dlaczego nie ESP32 który może jest ciut droższy, a ma fajną sprawę jaką są dwa rdzenie.dragonn pisze: Niestety Octoprint ma jedną wadę - wysyłanie g-code oraz obsługa WWW jest w tym samym wątku.
Spokojnie można rozdzielić obsługę WiFi czyli stos tcp/ip itd. puszczając na jednym rdzeniu i drugi mamy pełen do dyspozycji. Jakiekolwiek problemy z dużym obciążeniem WiFi itp. nie odbiją się na sofcie pracującym sobie osobno na drugim core (i vice versa).
Pomijam już większą wydajność ESP32 oraz kupę innych ciekawych funkcjonalności w tym np. BT...
For every complex problem, there is a solution that is simple, neat, and wrong.
Ultimaker 1 i 1/2, Szrotek, Vertex K8400, Anycubic I3 Mega
Ultimaker 1 i 1/2, Szrotek, Vertex K8400, Anycubic I3 Mega
- dragonn
- Zasłużony
- Postów w temacie: 5
- Posty: 6384
- Rejestracja: 12 gru 2016, 21:50
- Lokalizacja: Opole
- Drukarka: LUME
- x 1455
Re: Drukowanie przez wifi. część 1
Oczywiście że tak , zrób soft to chętnie skorzystamy .sp6vgx pisze: A ja się odniosę po części do podobnej sprawy... i teraz tak dlaczego nie ESP32 który może jest ciut droższy, a ma fajną sprawę jaką są dwa rdzenie.
Spokojnie można rozdzielić obsługę WiFi czyli stos tcp/ip itd. puszczając na jednym rdzeniu i drugi mamy pełen do dyspozycji. Jakiekolwiek problemy z dużym obciążeniem WiFi itp. nie odbiją się na sofcie pracującym sobie osobno na drugim core (i vice versa).
Pomijam już większą wydajność ESP32 oraz kupę innych ciekawych funkcjonalności w tym np. BT...
-
- Konto z ograniczeniami
- Postów w temacie: 2
- Posty: 489
- Rejestracja: 06 lut 2018, 18:38
- Lokalizacja: Warszawa
- x 74
- Kontakt:
Re: Drukowanie przez wifi. część 1
@dragonn
To była bardziej sugestia do autora tematu, bo poruszyłeś ciekawy problem który też może występować na ESP który to do mistrzów wydajności nie należy. Natomiast jakiekolwiek większe obciążenie tego jednego core potrafi powodować problemy z obsługą stosu lwIP jaki tam jest używany.
Natomiast co do mnie to ja już od dawna nie publikuje projektów... ot kiedyś na pewnym forum pisałem o elektronice 32bit aby dać lepszy procek z dużą ilością ramu aby z wyprzedzeniem liczyć więcej ramp itd. itp. (można to znaleźć). Generalnie uciec od obciążeń jakie niesie Arduino czyli HAL i ograniczenia 8bit - no i jakoś tak średnio to było przyjęte. Projekt powstał dawno temu na STM32F407 z własnym softem, działa i jestem szczęśliwy. Może kiedyś udostępnię... W sumie to powstaje teraz taki nowy koncept na Cortex M7... z eth itd. jak ktoś chętny do poklepania kodu można się jakoś ugadać (ale projekt zamknięty tzn. nie będzie dalej udostępniany)...
To była bardziej sugestia do autora tematu, bo poruszyłeś ciekawy problem który też może występować na ESP który to do mistrzów wydajności nie należy. Natomiast jakiekolwiek większe obciążenie tego jednego core potrafi powodować problemy z obsługą stosu lwIP jaki tam jest używany.
Natomiast co do mnie to ja już od dawna nie publikuje projektów... ot kiedyś na pewnym forum pisałem o elektronice 32bit aby dać lepszy procek z dużą ilością ramu aby z wyprzedzeniem liczyć więcej ramp itd. itp. (można to znaleźć). Generalnie uciec od obciążeń jakie niesie Arduino czyli HAL i ograniczenia 8bit - no i jakoś tak średnio to było przyjęte. Projekt powstał dawno temu na STM32F407 z własnym softem, działa i jestem szczęśliwy. Może kiedyś udostępnię... W sumie to powstaje teraz taki nowy koncept na Cortex M7... z eth itd. jak ktoś chętny do poklepania kodu można się jakoś ugadać (ale projekt zamknięty tzn. nie będzie dalej udostępniany)...
For every complex problem, there is a solution that is simple, neat, and wrong.
Ultimaker 1 i 1/2, Szrotek, Vertex K8400, Anycubic I3 Mega
Ultimaker 1 i 1/2, Szrotek, Vertex K8400, Anycubic I3 Mega
- artur_n
- Postów w temacie: 5
- Posty: 984
- Rejestracja: 20 lis 2017, 21:48
- Lokalizacja: RJA
- Drukarka: Prusa MK4, P1S AMS
- x 181
Re: Drukowanie przez wifi. część 1
Z czystej ciekawości uruchomiłem to mając nadzieję, że pozbędę się tematu wyjmowania karty, lecz szybko przyszło rozczarowanie gdzie gcode 2,5MB idzie wieczność i to dosłownie.
-
- Konto z ograniczeniami
- Postów w temacie: 3
- Posty: 7
- Rejestracja: 03 lip 2018, 12:40
- Lokalizacja: Piła
- Drukarka: Anet A8
Re: Drukowanie przez wifi. część 1
Witam,dragonn pisze:Niestety Octoprint ma jedną wadę - wysyłanie g-code oraz obsługa WWW jest w tym samym wątku. Zazwyczaj się to nie objawia ale jak spróbujemy załadować stronę z kompa który jest mocno obciążony i w trakcie ładowania strony 'przytnie' to potrafi to również przyciąć wydruk. A z drukowanie z USB i gorszą jakością chodzi o szybkość przesyłania danych przez połączenie szeregowo która jest dużo niższa niż odczyt przez SD - przez co przy bardziej skomplikowanych modelach i dużych szybkościach wydruku może dojść do tego że drukarka będzie się zacinać czekają na komendy z Octoprint.Kopytko pisze:Octoprint prawie wogole nie uzywa procesora raspberry przy pracy. Chyba ze macie wlaczony podglad na zywo w fhd to wowczas proces rosnie a tak to jest to ok 2-3%.
Z kontekstu wnioskuje że problem dotyczy "małych" Pi, czy ten problem pogorszenia wydruku występuje również w przypadku raspberry pi 3 ?
Pozdrawiam
P.
Raczkujący... dosłownie... na poziomie fug w kwestii druku 3d
Re: Drukowanie przez wifi. część 1
Nie
PS.: nie z winy wi-fi i/lub.
Nie chce mi się czytać starego wątku / wyłapywać kontekstu, ale ogólnie druk po USB (drukarki) ma mniejszą przepustowość od karty SD (w drukarce) - nie ma to związku z octoprint. Po prostu jest wąskie gardło w transmisji po USB / emulowany port szeregowy w elektronice drukarki.
Jeżeli nie drukujesz szybciej niż 60mm/s to nie zauważysz różnicy. Tylko na szybkim druku i skomplikowanych kształtach wracasz w ograniczenia.
PS.: nie z winy wi-fi i/lub.
Nie chce mi się czytać starego wątku / wyłapywać kontekstu, ale ogólnie druk po USB (drukarki) ma mniejszą przepustowość od karty SD (w drukarce) - nie ma to związku z octoprint. Po prostu jest wąskie gardło w transmisji po USB / emulowany port szeregowy w elektronice drukarki.
Jeżeli nie drukujesz szybciej niż 60mm/s to nie zauważysz różnicy. Tylko na szybkim druku i skomplikowanych kształtach wracasz w ograniczenia.
Ostatnio zmieniony 03 lip 2018, 13:03 przez McKee, łącznie zmieniany 1 raz.
Motto na dziś: "How may I abuse you?"
-
- Konto z ograniczeniami
- Postów w temacie: 3
- Posty: 7
- Rejestracja: 03 lip 2018, 12:40
- Lokalizacja: Piła
- Drukarka: Anet A8
Re: Drukowanie przez wifi. część 1
W takim razie dziś będzie zabawa z instalowaniem Octoprint'a . Malinke mam "doposażoną" w wyświetlacz - muszę poszukać na forum i w necie czy istnieje możliwość wyświetlania na nim jakiś dodatkowych informacji.
Dzięki za szybką odpowiedź.
P.
Dzięki za szybką odpowiedź.
P.
Raczkujący... dosłownie... na poziomie fug w kwestii druku 3d
- dragonn
- Zasłużony
- Postów w temacie: 5
- Posty: 6384
- Rejestracja: 12 gru 2016, 21:50
- Lokalizacja: Opole
- Drukarka: LUME
- x 1455
Re: Drukowanie przez wifi. część 1
Nie do końca, problem występuje ale raczej nie jest widoczny z względu na wydajność pojedynczego rdzenia w Pi 3.