dragonn pisze:Ale to było dawno, może coś się poprawiło od tego czasu.

Zmieniło się dużo. Jak jeszcze miałem NAS który robił backup na ext2 to miałem takie i działały, ale przyznam że były to n-te które testowałem. Teraz nie jestem na bieżąco, ale skoro w czasach Win2000/XP się dało to dziś pewnie też.

Tj "widzi ale nie umie" ;p
Trzeba użyć jakiegoś narzędzia do grzebania w ext2/3/4 - np to https://sourceforge.net/projects/ext2read/ czy po prostu sterownik: http://www.fs-driver.org/.

ethanak pisze:czy taki, który Ci uczciwie powie "nie wiem, nie potrafię, sprawdź sobie sam"?

W sytuacji gdy tak powie, powinien wyłączyć drukarkę.
System zabezpieczeń który uniemożlkiwia pracę nie jest systemem zabezpieczeń.

ethanak pisze:Jeszcze co do awaryjności Linuksów... rozumiem że procki w drukarkach działają bezawaryjnie, programy nie mają żadnych błędów i w ogóle świat jest piękny?

uC w którym panujesz nad wszystkim zawsze będzie pewniejszym rozwiazaniem niż system który żyje własnym życiem.

@GUTEK@ pisze:Ja mam drukarkę podłączoną przez Sonoff. Wprawdzie nie współpracuje z Octo, ale mam podgląd z kamerki i w razie czego mogę na chama odciąć zasilanie.

Zabezpieczenie IMHO ma być bezobsługowe. Przy założeniu że użytkownik to kretyn (to nic osobistego, piszę to jako programista ) urządzenie ma poradzić sobie samo. A co jak zacznie się palić jak akurat bedziesz miał zatwardzenie i nie lukniesz na kamerę?
Nawet jeśli Marlin nie jest pewnym softem, to jest lepsze niż nic. I mimo masakrycznego kodu działa takze ten tego... (*1)

dragonn pisze:Nawet nie o to chodzi, jak ktoś chce może sobie stawiać. Ale poleganiem na jakimkolwiek dużym OS jako jedyna linia obrony przed czymś tak poważny jak ryzyko pożaru... chyba sam przyznasz że to nie jest dobry pomysł?

Przecież wiesz co Ci napiszę
uC ma tą przewagę że nawet jak jest skomplikowany czy ma RTOSa to zawsze możesz wymusić tryb kiedy działą jeden konkretny kawałek kodu i tyle. Zawsze jest coś. Zawsze można się zresetować i wstać w 10ms.
Żaden komputer tego nie zrobi; do tego w tle pracuje w cholerę rzeczy nad któymi zwyczajnie nikt nie panuje. Bo on nie jest od tego.


(*1)
Tak mi się przypomniało - mam, tu zegar. Mój pierwszy program w asm na 8051 (w ogóle na uC). Przemiatany ekran, RTC, alarmy, temperatura otoczenia, wyliczanie dnia tygodnia z daty... Bez watchdoga bo nie potrafiłem go obsłużyć (jest zewnętrzny). Działa z jednodniową przerwą (przeprowadzka) od 14 lat... Bez obudowy; boje się że jak go ruszę to coś padnie. Także nawet ciulowy program, a ten taki jest, może działać dobrze o ile jest przyzwoicie spieprzony Piszę to - bo mimo mojego grzebania i innych dziwnych rzeczy to Marlin mi się jeszcze nie zawiesił.

ethanak pisze:@dragonn: Nie zgodzę się.
W każdej z tych sytuacji Octoprint mógłby uprzejmie zareagować. Nie ma nic w tych zabezpieczeniach, czego nie mogłaby zdziałać jakaś prosta wtyczka do OP. Jedyną awarią w której wbudowany w drukarkę soft będzie bezradny jest właśnie przebicie - a Octoprint z modułem przekaźnika mógłby w tej sytuacji odłączyć zasilanie.

1. Podepnij do płyty przekaźnik odłączający zasilanie grzałek. Ten sam który możesz podpiąć do rPi.
2. W configuration.h/configuration_adv.h dodaj sobie definicję pinu np

#define PANIC_RELAY_PIN 10

3. Przy starcie programu go włącz:
w Marlin_main.cpp, w funkcji setup (na końcu) dodaj:

SET_OUTPUT(PANIC_RELAY_PIN);
WRITE(PANIC_RELAY_PIN, LOW); // LOW/HIGH zależnie od logiki

4. W temperature.cpp w funkcji _temp_error dopisz sobie

WRITE(PANIC_RELAY_PIN, HIGH); // LOW/HIGH zależnie od logiki

Nie wiem czy dla 4 linii kodu trzeba stawiać obok komputer.