reprapy.pl

Hej,
Walczę od tygodnia z dziwnym problemem z Sbase. Jak w temacie - płytka resetuje się w trakcie druku. Przy pierwszym po około 30 minutach, jak chwilę pochodzi to po 5-10 minutach

Wydruki puszczałem przez webif z karty SD, ale również z pronterface przez USB. Nie dostaję żadnych konkretnych komunikatów tylko
"[ERROR] Can't read from printer (disconnected?) (OS Error 6): Device not configured"

Druk pocięty zarówno S3D jak i slic3rem. Kiedyś był ciekawy bug na smoothie przy odtwarzaniu kodu z S3D, ale to nie to. Nie wiem w sumie gdzie mam najpierw zajrzeć. W sieci pojawiają się jakieś wątki o resetach, ale są mało pomocne.

Inne szczegóły:
Wiatraki stają
Grzanie staje (na ile mogę stwierdzić po restarcie zasilania)
Diody mają taki stan: [1] [1] [0] [1] [0]
Karta po USB pozostaje zamontowana.

Smoothie edge ostatni (próbowałem też na starszym z listopada), konfig jest tutaj:
https://github.com/zen/zHevo/blob/master/config.txt

zen pisze:Hej,
Walczę od tygodnia z dziwnym problemem z Sbase. Jak w temacie - płytka resetuje się w trakcie druku. Przy pierwszym po około 30 minutach, jak chwilę pochodzi to po 5-10 minutach

Wydruki puszczałem przez webif z karty SD, ale również z pronterface przez USB. Nie dostaję żadnych konkretnych komunikatów tylko
"[ERROR] Can't read from printer (disconnected?) (OS Error 6): Device not configured"

Druk pocięty zarówno S3D jak i slic3rem. Kiedyś był ciekawy bug na smoothie przy odtwarzaniu kodu z S3D, ale to nie to. Nie wiem w sumie gdzie mam najpierw zajrzeć. W sieci pojawiają się jakieś wątki o resetach, ale są mało pomocne.

Inne szczegóły:
Wiatraki stają
Grzanie staje (na ile mogę stwierdzić po restarcie zasilania)
Diody mają taki stan: [1] [1] [0] [1] [0]
Karta po USB pozostaje zamontowana.

Smoothie edge ostatni (próbowałem też na starszym z listopada), konfig jest tutaj:
https://github.com/zen/zHevo/blob/master/config.txt

Wiatraczek na procka i zobacz czy zasilanie nie przysiada.

Czesto wymiana zasilacza, albo puszczenie wydruku bez grzanego stołu jest wskazówka.

Wyświetlacz to tft czy lcd?

zen pisze: Wydruki puszczałem przez webif z karty SD, ale również z pronterface przez USB. Nie dostaję żadnych konkretnych komunikatów tylko
"[ERROR] Can't read from printer (disconnected?) (OS Error 6): Device not configured"

To jest wystarczający komunikat.
"Device not configured" sugeruje że padło połączenie z urządzeniem USB, FTDI w tym wypadku. Jako że tenże kontroler jest niezależny od samego uC, a też padł, można obstawiać tylko odgórny problem - jak @mcxmcx pisał - sprawdź zasilacz.

Oj bardzo, bardzo nie. Jakie ftdi?

emartinelli pisze:Wyświetlacz to tft czy lcd?

Żaden. Jak pisałem wyżej, pronterface albo webif

zen pisze:Oj bardzo, bardzo nie. Jakie ftdi?

Jakoś mi się wydawało że tam kontroler osobny jest. Ale mniejsza z tym - sprawdziłeś zasilacz?

No przedziwna sytuacja.
Testowałem godzinami w różnych konfiguracjach, z wyłączonym stołem, hotendem, odpiętym ekstruderem, odpiętymi wszystkim mislnikami, itp. W końcu zmieniłem mikrokrok na 16 i wszystko działa. Deweloperzy smoothie oczywiście mnie olali i obrzucili gównem za używanie MKS SBase, więc tam pomocy raczej nie znajdę. Buga zamknęli bez żadnej analizy, twierdzą, że to problem sprzętowy. Znalazłem jeden podobny problem i tam również zmiana mikrokroku pomogła:
https://github.com/Smoothieware/Smoothieware/issues/922
Chociaż tam problem był również związany ze sposobem w jaki S3D generuje gcode.
Warto poczytać ten wątek, żeby zobaczyć jak deweloperzy smoothieware traktują użytkowników

Sprawdzę jeszcze z innym zasilaczem, chociaż wątpię, aby to było związane z zasilaniem.

Osobiście mam w mojej delcie mks Sbase v1.3 ustawioną na 32 mikrokrok i bez żadnych problemów, oprogramowanie sam kompilowałem(przerabiałem odrobine, kąty ramion). Używam Cury 3.1. Drukowałem max po około 10 godzin. Oni tak traktują ludzi z mks sbase bo nie kupili ich płytki, nie dali im zarobić, ja się nie dziwię. Zrobił byś komuś serwisową naprawę sprzętu który nie ty zrobiłeś za darmo?

Pamiętam że miałem jeden błąd przy próbie startowania wydruków, trzeba było jakiś parametr ustawić bo miał pustą wartość i powodowało crash. Musze się podłączyć do drukarki by sprawdzić. Teraz drukuje jak skończy.

Setki ludzi mają MKS Sbase w podobnych konfiguracjach. Tylko że to jest software, w którym są dziesiątki tysięcy zmiennych i nikt nie jest w stanie przetestować wszystkich ich iteracji, dlatego mamy dziwne bugi.

Ja nie wymagam serwisowania sprzętu, tylko pomocy z softwarem, bo jestem na 90% pewien, że to problem software'owy. To jest jednak open source. Ja im się trochę nie dziwię, bo Makerbase to cwaniaki, które nie przestrzegają otwartych licencji. Niestety nie wiedziałem tego, kiedy kupowałem płytkę. Z drugiej strony - cena czyni cuda

Najpewniej uzbieram i kupię DuetWiFi, ale chciałbym już stabilnie drukować na moim HEVO.

Zrobię jeszcze tak, że ściągnę od kogoś z HEVO i MKS Sbase jego konfig i wersję FW i zapuszczę u mnie. Zobaczymy, czy coś się zmieni. Być może też drukuję za szybko i procek się nie wyrabia. Zejdę z prędkościami i zobaczymy.

zen pisze:Setki ludzi mają MKS Sbase w podobnych konfiguracjach. Tylko że to jest software, w którym są dziesiątki tysięcy zmiennych i nikt nie jest w stanie przetestować wszystkich ich iteracji, dlatego mamy dziwne bugi.

Nie prawda. To open-source rozwijany po części "na hura". To powoduje że niektóre rozwiązania są, delikatnie mówiąc, beznadziejne.
Mam oryginalne smoothieware i grzebię sobie trochę w starszej wersji softu - szacuję że 15-20% zasobów leci w gwizdek z powodu organziacji softu. Dużo jak na uC.

zen pisze:Ja nie wymagam serwisowania sprzętu, tylko pomocy z softwarem, bo jestem na 90% pewien, że to problem software'owy. To jest jednak open source. Ja im się trochę nie dziwię, bo Makerbase to cwaniaki, które nie przestrzegają otwartych licencji. Niestety nie wiedziałem tego, kiedy kupowałem płytkę. Z drugiej strony - cena czyni cuda Najpewniej uzbieram i kupię DuetWiFi, ale chciałbym już stabilnie drukować na moim HEVO.

Open source też nie gwarantuje wsparcia. A imho logiczne jest że wspierają tylko swoje, no bo co mają wróżyć z fusów kto co spieprzył w innym sprzęcie. Jak w oryginalnym działa to na tym powinna się sprawa skończyć. Imho.

A pamiętasz w jakim miejscu wydruku smoothie się wiesza? Czy zawsze w tym samym dla tego samego gcode? Jesteś w stanie określić jakie dane wtedy poszły?
Wiem że S3D potrafił generować nieprawidłowy gcode (ale slic3r też ;p). Z tym że firmware powinien sobie z tym poradzić, no ale to open-source...

Spróbuj ten sam wydruk puścić na marlinie zamiast smoothie, wykluczysz problem sprzętowy.

dziobu pisze:
zen pisze:Setki ludzi mają MKS Sbase w podobnych konfiguracjach. Tylko że to jest software, w którym są dziesiątki tysięcy zmiennych i nikt nie jest w stanie przetestować wszystkich ich iteracji, dlatego mamy dziwne bugi.
Nie prawda. To open-source rozwijany po części "na hura". To powoduje że niektóre rozwiązania są, delikatnie mówiąc, beznadziejne.
Mam oryginalne smoothieware i grzebię sobie trochę w starszej wersji softu - szacuję że 15-20% zasobów leci w gwizdek z powodu organziacji softu. Dużo jak na uC.

W ogólności nie mogę się zgodzić, 20 lat siedzę we FLOSS i w większości przypadków QA jest lepsze niż w komercyjnych projektach. Ale co do smoothieware to niestety prawda

Jest parę miejsc, gdzie Artur i Jim wiedzieli lepiej

dziobu pisze:
zen pisze:Ja nie wymagam serwisowania sprzętu, tylko pomocy z softwarem, bo jestem na 90% pewien, że to problem software'owy. To jest jednak open source. Ja im się trochę nie dziwię, bo Makerbase to cwaniaki, które nie przestrzegają otwartych licencji. Niestety nie wiedziałem tego, kiedy kupowałem płytkę. Z drugiej strony - cena czyni cuda Najpewniej uzbieram i kupię DuetWiFi, ale chciałbym już stabilnie drukować na moim HEVO.
Open source też nie gwarantuje wsparcia. A imho logiczne jest że wspierają tylko swoje, no bo co mają wróżyć z fusów kto co spieprzył w innym sprzęcie. Jak w oryginalnym działa to na tym powinna się sprawa skończyć. Imho.

Jasne, że nie gwarantuje, ale jest jeszcze kwestia tego, jak traktują użytkowników swojego softu. Nigdzie nie jest napisane, że masz tego używać tylko ze smoothieboard. A obrzucanie użytkowników wyzwiskami jest jednak słabe, a oni są z tego wręcz sławni. Przeczytaj sobie konwersację w bugu, który wrzuciłem wyżej. Ciekawa

dziobu pisze: A pamiętasz w jakim miejscu wydruku smoothie się wiesza? Czy zawsze w tym samym dla tego samego gcode? Jesteś w stanie określić jakie dane wtedy poszły?
Wiem że S3D potrafił generować nieprawidłowy gcode (ale slic3r też ;p). Z tym że firmware powinien sobie z tym poradzić, no ale to open-source...

Nie ma znaczenia jaki wydruk, wiesza się losowo. Najpierw po 30 minutach, potem po 5, 10 - ogólnie różnie. Bug z S3D został ponoć naprawiony, zresztą ciąłem i S3D i slic3rem i kurczakiem. Ta zmiana czasu jest mocno podejrzana, bo może wymagać z temperatury. Ale jak polecali koledzy w ostatnich testach chłodzę wszystko, puszczałem nawet z odpiętymi silnikami, nic to nie zmienia, ale czyni problem jeszcze bardziej zagadkowym.

tig33r pisze:Spróbuj ten sam wydruk puścić na marlinie zamiast smoothie, wykluczysz problem sprzętowy.

No właśnie puszczę to chyba na 2.0, ale mam na widok Marlina mdłości

Liczyłem, że w 2.0 coś się zmieni, ale jest taki sam bajzel.
Przydałaby się konfiguracja pod HEVO do Marlina 2.0, nigdy na tym corexy nie robiłem.

zen pisze: W ogólności nie mogę się zgodzić, 20 lat siedzę we FLOSS i w większości przypadków QA jest lepsze niż w komercyjnych projektach. Ale co do smoothieware to niestety prawda Jest parę miejsc, gdzie Artur i Jim wiedzieli lepiej

Otwarty kod ma szereg zalet jeśli korzysta z niego ktoś posiadający mózg. Niestety to co raz rzadziej spotykane za sprawą Arduina. Ale też dzięki niemu docenia się indywidualne wsparcie i systemy zamknięte.
Mój zakres działalnośći jest po prostu dość zamknięty - przemysł, laboratoria, jednostki badawcze. Inni klienci, inne wymagania

zen pisze: Jasne, że nie gwarantuje, ale jest jeszcze kwestia tego, jak traktują użytkowników swojego softu. Nigdzie nie jest napisane, że masz tego używać tylko ze smoothieboard. A obrzucanie użytkowników wyzwiskami jest jednak słabe, a oni są z tego wręcz sławni. Przeczytaj sobie konwersację w bugu, który wrzuciłem wyżej. Ciekawa

Tak, zgoda. W sumie to nie czytałem tegoż forum (sam grzebię w sofcie, bo lubię ;p) ale rzeczywiście w wielu miejscach leci po bandzie. To dobrze - kolejny impuls żebym w końcu swój zaczął kończyć ;p

zen pisze: Nie ma znaczenia jaki wydruk, wiesza się losowo. Najpierw po 30 minutach, potem po 5, 10 - ogólnie różnie. Bug z S3D został ponoć naprawiony, zresztą ciąłem i S3D i slic3rem i kurczakiem. Ta zmiana czasu jest mocno podejrzana, bo może wymagać z temperatury. Ale jak polecali koledzy w ostatnich testach chłodzę wszystko, puszczałem nawet z odpiętymi silnikami, nic to nie zmienia, ale czyni problem jeszcze bardziej zagadkowym.

Jak jest w róznych losowych miejscach to obstawiam że jednak nie jest to błąd programowy. Mimo wszystko smoothie aż takim syfem nie jest i nie ma cech polimorfizmu więc konsekwentnie powinno wykładać się w tym samym miejscu.

Trochę się też pogubiłem - na mikrokroku 16 wszystko działa prawidłowo?

Jeszcze jedno - nie masz w konfigu "planner_queue_size" a to dość istotne. Nie wiem jaką to ma wartość domyślną - dodaj na wszelki wypadek:

Kod: Zaznacz cały

planner_queue_size 32

dziobu pisze:Jeszcze jedno - nie masz w konfigu "planner_queue_size" a to dość istotne. Nie wiem jaką to ma wartość domyślną - dodaj na wszelki wypadek:
Kod: Zaznacz cały
planner_queue_size 32

Też się nad tym zastanawiałem, ale konfiguracja przykładowa też tego nie ma. Dodam i zobaczę. Dzięki za hinta

Ja miałem dziwne problemy przez alpha_max , beta_max , gamma_max, nie mogą być puste musza mieć wartość(właśnie skończyło drukować).

dziobu pisze: Jak jest w róznych losowych miejscach to obstawiam że jednak nie jest to błąd programowy. Mimo wszystko smoothie aż takim syfem nie jest i nie ma cech polimorfizmu więc konsekwentnie powinno wykładać się w tym samym miejscu.

Trochę się też pogubiłem - na mikrokroku 16 wszystko działa prawidłowo?

No ja się pogubiłem

Tak, na 16 wszystko działa cacy. Zastanawiam się jak to może wpływać jednak na ilość operacji do przeprowadzenia i możliwość wywalania się. Podepnę się jeszcze jak znajdę czas pod MRI i zrobię zrzut, obiecali mi, że w to zajrzą.

skmskm pisze:Ja miałem dziwne problemy przez alpha_max , beta_max , gamma_max, nie mogą być puste musza mieć wartość(właśnie skończyło drukować).

Jesteś pewien? One są wykorzystywane tylko, kiedy robisz home do max, a nie min. W kodzie też tak to wygląda.

Może je próbuje odczytać i świruje.

zen pisze:
skmskm pisze:Ja miałem dziwne problemy przez alpha_max , beta_max , gamma_max, nie mogą być puste musza mieć wartość(właśnie skończyło drukować).
Jesteś pewien? One są wykorzystywane tylko, kiedy robisz home do max, a nie min. W kodzie też tak to wygląda.

To również jest ograniczenie pracy jeśli nie masz krańcówki w daną stronę. Ja mam krańcówki przy min a tymi wartościami określam maksymalny ruch w danej osi. A Ty masz:

Kod: Zaznacz cały

gamma_max_endstop nc

dziobu pisze:
zen pisze:
skmskm pisze:Ja miałem dziwne problemy przez alpha_max , beta_max , gamma_max, nie mogą być puste musza mieć wartość(właśnie skończyło drukować).
Jesteś pewien? One są wykorzystywane tylko, kiedy robisz home do max, a nie min. W kodzie też tak to wygląda.
To również jest ograniczenie pracy jeśli nie masz krańcówki w daną stronę. Ja mam krańcówki przy min a tymi wartościami określam maksymalny ruch w danej osi. A Ty masz:
Kod: Zaznacz cały
gamma_max_endstop nc 

Spytam jeszcze raz: jesteście pewni? Smoothie nie ma software endstops. To jest wręcz niemożliwe, by działało, bo to jest oznaczenie pozycji po home do maksa:
"alpha_max 250 # This gets loaded as the current position after homing when home_to_max is set"

Czyli robisz home danej osi, i ta wartość się ładuje jako pozycja. Nie ma raczej możliwości, aby to działało tak jak mówicie, chyba że Smoothie ma błąd, o którym nawet twórcy nie mają pojęcia

zen pisze: No ja się pogubiłem Tak, na 16 wszystko działa cacy. Zastanawiam się jak to może wpływać jednak na ilość operacji do przeprowadzenia i możliwość wywalania się. Podepnę się jeszcze jak znajdę czas pod MRI i zrobię zrzut, obiecali mi, że w to zajrzą.

W sumie to może. Jest jeszcze jeden pomysł:
zwiększ mikrokrok x2 (do 32; tyle masz domyślnie?) i zmniejsz szybkość druku 2x.

zen pisze: Spytam jeszcze raz: jesteście pewni? Smoothie nie ma software endstops. To jest wręcz niemożliwe, by działało, bo to jest oznaczenie pozycji po home do maksa:
"alpha_max 250 # This gets loaded as the current position after homing when home_to_max is set"

Czyli robisz home danej osi, i ta wartość się ładuje jako pozycja. Nie ma raczej możliwości, aby to działało tak jak mówicie, chyba że Smoothie ma błąd, o którym nawet twórcy nie mają pojęcia

OK, masz rację. Ja to dodałem u siebie bo pole robocze miałem ograniczone w innym miejscu i działa jak pisałem ale faktycznie jest to doróbka którą miałem wywalić ;p

zen widziałem Twój post na githubie. Rozumiem ich niechęć do MKS ale jak dla mnie z takim podejściem tylko więcej tracą niż to jest warte bo tracą potencjalnych klientów. Ja teraz już wiem że na pewno nie kupię nigdy smoothieboard. Z takim podejściem dev-ów nie warto się w to pakować, to już wolę Marlina xDDD.

Skończą jak multikopter, jeżeli ktoś jeszcze ich pamięta

A kolega powinien sobie wrzucić jedna generację w tył software, i ówczesny, starszy konfig.

Może to jest powodem, większość ma bez problemowo działające płytki.

Nie kojarzę o co chodzi z multikopterem. Ale na deser wrzucę to https://github.com/Smoothieware/Smoothieware/issues/637

tl;dr możesz streścić?

tig33r pisze:tl;dr możesz streścić?

40 komentarzy na temat tego że soft powinien wyłączać grzałki jak coś się wywal. I teksty typu "if your machine is dangerous, you shouldn't rely on Smoothieboard to stop it anyway". I po tych 40 postach i tak nie zostało to zrobione (możliwe że zrobili to później).

dragonn pisze:zen widziałem Twój post na githubie. Rozumiem ich niechęć do MKS ale jak dla mnie z takim podejściem tylko więcej tracą niż to jest warte bo tracą potencjalnych klientów. Ja teraz już wiem że na pewno nie kupię nigdy smoothieboard. Z takim podejściem dev-ów nie warto się w to pakować, to już wolę Marlina xDDD.

No ja też musze się przeprosić z Marlinem. Ale smoothieware jest zajebiście fajne w konfiguracji, miałem nadzieję, że Marlin 2 też dostanie konf w pliku, a nie w zmiennych

Zrobiłem błąd kupująć MKS Sbase, ale nie znałem szczegółów i niechęci devów do userów

Następny na pewno będzie DuetWiFi, ale tyle kasy poszło na HEVO, że musiałbym się wyprzedać.

mcxmcx pisze:Skończą jak multikopter, jeżeli ktoś jeszcze ich pamięta

A kolega powinien sobie wrzucić jedna generację w tył software, i ówczesny, starszy konfig.

Może to jest powodem, większość ma bez problemowo działające płytki.

Co masz na myśli? W smoothie nie ma poprzedniej generacji, pracuje się tylko n edge. Chyba, że jakiś inny pomysł

dziobu pisze: W sumie to może. Jest jeszcze jeden pomysł:
zwiększ mikrokrok x2 (do 32; tyle masz domyślnie?) i zmniejsz szybkość druku 2x.

Tak zrobiłem i niestety to samo. Teraz leci na Marlin 2.0. I leciiiiii. Nic się nie dzieje, zaraz koniec druku.

zen pisze:
mcxmcx pisze:Skończą jak multikopter, jeżeli ktoś jeszcze ich pamięta

A kolega powinien sobie wrzucić jedna generację w tył software, i ówczesny, starszy konfig.

Może to jest powodem, większość ma bez problemowo działające płytki.
Co masz na myśli? W smoothie nie ma poprzedniej generacji, pracuje się tylko n edge. Chyba, że jakiś inny pomysł

W sensie że poprzednia kompilacje.

Ostatnio Artur wrzucił .bin , kilka /naście dni temu.

Może w tym jest problem?

Chyba że sam kompilujesz.
Ja mam jakiś .bin sprzed roku, działa, konfig troszkę inaczej zorganizowany niż aktualny.

Może, może coś nie tak z tym bin.

A multikopter, miał fajne kontrolery kopterow, można bylo robić DIY, aż po którejś szczególnie fajnej zmianie zamknęli możliwość robienia swoich płytek (odpowiednik sytuacji z MKS).

Zdechło, za wyjątkiem kilkunastu zapaleńców

No i na marlinie poszło. Całkiem chyba nieźle jak na pierwszy wydruk bez żadnego tuningu Obrazek

Czyli elektrycznie płytka jest ok.

Możesz wgrać na test starszy software i sprawdzić.

Chyba się muszę zebrać na skompilowanie marlina.

No gwarancji nie ma, że jest elektrycznie ok, tylko wtedy smoothie musiałby w jakiś specyficzny sposób wyzwalać ten błąd. Jakoś nie mogę sobie tego wyobrazić. Wrzucę starszy firmware, a może nawet wersję MKS sprzed 2 lat i zobaczę

Sprawdzałeś na nowej karcie SD? Mimo że z niej nie drukujesz to może firmware próbuje coś czytać a jak karta jest uszkodzona to mogą być problemy. Ja miałem podobnie na Duecie, płytka się często resetowała podczas odświeżania WebUI, okazało się to być winą uszkodzonej karty SD.

zen pisze:(...)tylko wtedy smoothie musiałby w jakiś specyficzny sposób wyzwalać ten błąd. Jakoś nie mogę sobie tego wyobrazić. Wrzucę starszy firmware, a może nawet wersję MKS sprzed 2 lat i zobaczę

No własnie na szybko luknąłem w źródła tego co ja mam; pominąwszy kilka "kwiatków" za które bym kogoś z roboty wyp* (np. ustawienie zegara rdzenia w system_*.c) to jest sporo miejsc gdzie faktycznie może być kicha.

Obstawiam że może nie wyrabiać się przy wyliczaniu czasów podczas przyspieszania/hamowania. To Cortex M3 bez FPU, do tego zaprany innymi rzeczami i obudowany w kosmiczną ilość klas (tak, obsługa klas też kosztuje czas uC lub wymaga odpowiedniego podejścia).

Ja mam mikrokrok /16 (chyba nawet sprzętowo na sztywno) to nie sprawdzę, ale patrząc po kodzie to wcale bym się nie zdziwił jakby gdzieś to było na sztywno liczone i durniało przy innych wartościach.

krzaku pisze:Sprawdzałeś na nowej karcie SD? Mimo że z niej nie drukujesz to może firmware próbuje coś czytać a jak karta jest uszkodzona to mogą być problemy. Ja miałem podobnie na Duecie, płytka się często resetowała podczas odświeżania WebUI, okazało się to być winą uszkodzonej karty SD.

Sprawdzałem 4 różne karty. Przyjąłem, że 4 próby eliminują możliwość uszkodzonej karty SD

No i dzisiaj tez mi się zresetowała po 5h druku,w weekend puszcze jeszcze raz . Drukowałem już dłużej i nie było problemu. Mam nadzieje że to tylko software.

Moja się sama wyleczyła

Którą wersję płytki masz?

1.3, to chyba ostatnia

Ja u siebie musiałem wymienić stabilizator, bo miałem duże skoki temperatury na głowicy i czasami wydruk potrafił się zatrzymać. Ale ja mam V1.0

reprapy.pl

MKS SBase - reset? podczas druku

MKS SBase - reset? podczas druku

Re: RE: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: RE: Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: RE: Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: RE: Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku

Re: MKS SBase - reset? podczas druku