MlKl pisze:Jeżeli z jakiegoś powodu axis trzyma ten plik jako otwarty do zapisu, to po ingerencji innym programem widzi go jako zamknięty, i nadpisuje defaultową zawartością. A że operuje, jak już wcześniej pisałem, tak naprawdę dwoma plikami o tej samej zawartości, za każdym zapisaniem tworząc nowy plik .var, a stary zapisując jako .var.bak, to i dopiero drugie zamknięcie pozbywa się go całkowicie.

Teoretycznie plik otwarty do zapisu i zablokowany, nie powinien dać się ruszyć żadnym innym programem. Z drugiej strony ofsety musi mieć w RAMie bo przecież na okrągło musi wyliczać współrzędne względne dla narzędzia, więc nawet jeśli zapisywałby nowy plik, to powinien zapisać "defaultowo z ofsetami" . Podróżujemy po nieznanym i pozostają próby i kombinacje, próby i kombinacje.... Nawet jeśli problem zostanie pokonany, to po kolejnym upgrade może powrócić... Wydaje mi się, że nadpisywanie konfigami - o ile będzie skuteczne, może być pewniejsze

Wszystko wskazuje że są 2 problemy: jeden to opóźniony zapis na dysk - z tym sobie poradzicie i drugi, to jakieś błędy w axisie. Powiem tak: podchodzę trochę jak Miki: to nie jest system za milion dolarów. Sam zamykam system tak, żeby mnie serce nie bolało, a i tak zauważam, że po kilku-kilkunastu odpaleniach mojemu emc2 rozjeżdżają się ofsety i osobiście to wolałbym, żeby u mnie za każdym razem automatycznie się zerowały bo wtedy ubyłoby mni roboty z ręcznym zerowaniem .
Jeśli już musiałbym kombinować, to w takim przypadku szedłbym chyba w kierunku zapisania wszystkich konfigów cnc (po ustawieniu ofsetów i zamknięciu axisa) w innym miejscu i nadpisywania nimi roboczych katalogów przed każdym odpaleniem axisa (odpalałbym axisa jakimś batchem ręcznie lub automatycznie) a jak to nie pomoże to całego axisa - to w końcu nie jest jakaś duża aplikacja. Taka trochę proteza ale może zadziała ?

Teoretycznie, axis i tak powinien trzymać ofsety w RAMie, a plik powinien służyć jedynie do przechowania ofsetów do następnego uruchomienia maszyny. Pytanie, czy plik zapisuje się synciem na dysk przy otwartym axisie ? Jeśli tak, to kolejne wywołania synca nie powinny już wnieść żadnych zmian, bo plik został przepisany z systemowego RAMu na dysk i w systemie operacyjnym już go nie ma.

Jest wielce prawdopodobne, że axis sprawdza wiarygodność pliku (np. porównując z datami modyfikacji innych swoich bieżących plików), a to w tym celu, żeby przypadkowa podmiana pliku nie spowodowała awarii maszyny. Stąd możecie mieć problemy, iż po ręcznej modyfikacji pliku, axis odrzuca go i tworzy nowy, "własny".

Akurat USB to raczej nie dla Kamara kiedy wyłącznik główny pod ręką . Jeśli faktycznie to system leni się z zapisem, to wrzucenie synca do crona powinno załatwić sprawę. Gorzej jeśli to axis trzyma otwarty i zablokowany plik.

Hm, inżynier popracowałby nad systemem, zostawił samo jądro ze sterowaniem, wrzucił wszystko do jakiegoś flashdiscu, a to co dla systemu pilne zapis-odczyt, wrzucał do wirtualnego RAMdysku. I taki system miałby oficjalne błogosławieństwo do szybkiego wyłączania za pomocą zwykłego wyłącznika. Ale jeśli przeprowadziliście u siebie już tyle prób i jest ok, to faktycznie ogołociliście system do tzw. rosołu

Badsectorów na dysku wynikających z wyłączenia nie trzeba się bać - stare dyski, tak do ok. 1990-95 roku trzeba było parkować ręcznie. Od tej pory, po każdym zaniku zasilania, głowica w ułamku sekundy zjeżdża na pozycję parkowania, a w talerz nie uderzy dopóki talerz się kręci. Zanim talerze zwolnią na tyle, że przestaje działać poduszka, głowica już dawno jest zaparkowana

kamar pisze: To nie powinno specjalnie rzutować, offsety zmieniasz na stojącej maszynie.

Owszem, tylko tak jak w windowsie podczas wysyłania większych danych na drukarkę lpt potrafił zatrzymać się na chwilę system, tak i tu musisz zawsze mieć świadomość, że jeśli w czasie obróbki system akurat będzie miał coś większego do zapisania i nie będzie mógł poczekać bo mu na to nie pozwoliłeś, to dla axisa na chwilę czas może stanąć w miejscu. Jest to mało prawdopodobne, ale po prostu trzeba mieć tego świadomość i na to uważać

[ Dodano: 2012-11-15, 22:10 ]
Wypadałoby powyłączać wszystkie logi i wszelakie inne, zupełnie przy obróbce niepotrzebne usługi (apacze, sqle i co pod rękę podejdzie )

kamar pisze:

jacek-1210 pisze: Prawodopodobnie gdybyście zamknęli normalnie axisa i trochę poczekali z wyciągnięciem wtyczki, to pliki zapisałyby się.

Masz rację, po około dwóch minutach plik zapisał
Tyle ze to niewiele zmienia.

To teraz szukaj w systemie znacznika, który odpowiada za "inteligentne zapisywanie plików na dysku" i wyłącz to w pieruny. Tylko może się okazać, że system RealTime już nie jest RT .

To nie musi być od razu błąd programistów. Przypominają mi się czasy DOSa i wczesnych windows'ów, w którymś dosie stworzono program bodaj "smartdrv" służący przyspieszeniu pracy systemu. Polegało to na tym, że system nie zapisuje pliku od razu, tylko robi to "w dogodnym dla siebie momencie" tak, żeby operacja zapisu nie spowodowała spowolnienia pracy aplikacji. Takie zasady wciąż są stosowane, w niektórych systemach można je było wyłączyć. Prawodopodobnie gdybyście zamknęli normalnie axisa i trochę poczekali z wyciągnięciem wtyczki, to pliki zapisałyby się. Równie dobrze problem może być gdzie indziej: nadinstalowywanie LinuxCNC na EMC2 na starym Ubuntu wymaga zdaje się kombinacji ze ścieżkami, więc tu mogą być jakieś problemy i niedopracowania

[ Dodano: 2012-11-15, 21:42 ]
Możnaby jeszcze zrobić batcha np. kill lub shutdown -h 0 to byłaby jedna ikonka do kliknięcia na każdej maszynie a wszystko powinno pozamykać się cacy.
Swoją drogą typowy Linux, bez przeróbek to raczej nie jest system do nagłych, awaryjnych wyłączeń. Raz, drugi, trzeci ok, ale za którymś razem to i journaling nie pomoże