Jestem programistą, piszącym na GNU GPL od kilkunastu lat - nie musisz mi tłumaczyć, na czym to polega

Projekt wielkości LinuxCNC ktoś koordynuje, ktoś decyduje, co ma być w całość wmontowane. Jasne, że nie wszystko się dodaje, ani nie rzuca wszystkiego, żeby coś zmienić, bo sobie tego jakiś Miki zażyczy.

Ale zawsze się robi jakiś plan - co jest do zrobienia, co trzeba poprawić, co dopisać, żeby razem grało.

I chodzi właśnie o to, żeby poinformować o niedoróbkach, i potrzebach. I może poprawi to autor NGCGUI, albo ktoś inny, bo mu to będzie akurat potrzebne, albo będzie miał po prostu chęć, jak ja na te podcięcia. Bo napisałem je dlatego, że chciałem, a nie dlatego, że wykazałeś się umiejętnościami w podpuszczaniu. Po prostu mi pasowały do kompletu w kobyle.

Toć ja nie piszę, że micges ma mi to zrobić na wczoraj, albo, że ma w ogóle zrobić. Ze względu na trudności językowo-komunikacyjne ja tego nie wytłumaczę bezpośrednio twórcom. Nie jestem również na bieżąco z tym, kto za co odpowiada w projekcie. Nie władam językami programowania, których znajomość jest niezbędna do poprawienia funkcjonalności programu.

Programista, który nie pracuje bezpośrednio na maszynie, nie jest w stanie przewidzieć wszelkich komplikacji, i powinien być o nich informowany przez użytkowników. Takiego programu nie tworzy się jedynie dla idei - on ma być funkcjonalny i użyteczny.

Jestem np w stanie przejrzeć wszystki configi pod kątem wstawienia odpowiednich osi w tabelach narzędzi, czy dopisania linijki z pracą w średnicach dla tokarkowych. Ale ktoś potem to musi podmienić w repozytorium - ja tego nie zrobię sam. I nie dogadam się sam z twórcami, bom za mało gramotny...

Kolejna sprawa: Procedurę, poskładaną z kilku zakładek NGCGUI można zapisać przez "Zapisz plik g-code". Miło by było, gdyby przy wciąganiu jej do programu LinuxCNC rozpoznawał, że to jest składanka NGCGUI, i tworzył odpowiedni zestaw wypełnionych danymi z pliku zakładek, co umożliwiałoby edycję zaprogramowanego dawno detalu.

Plik zawiera dość informacji, by to było wykonalne, kwestia dostosowania systemu, importującego pliki z G-code do współpracy z NGCGUI.

Wszystkie takie kwestie wklejam w pierwszym poście - jak coś się komuś przypomni, też tam dopiszę. Micges nie będzie musiał szukać po całym wątku pełnym oftopów w razie czego.

Moje detale są dużo bardziej skomplikowane, niż ten z przykładu. Element tłumika ma na przykład kilka wtoczeń z fi 19 na fi 8, między nimi zostają milimetrowe przegrody. Każde wtoczenie musi być wykonane dwoma nożami, i po skończeniu jednego maszyna musi przejść na kolejne bez uszkodzenia przegrody.

Przykładowy detal wziąłem na warsztat, bo był gotowy rysunek, który sobie mogłem użyć. I pokazać tutaj. W realnej pracy zbyt często właśnie mam potencjalną kolizję na przejściu między procedurami, stąd temat poruszam. Oczywiście - daje się to ogarnąć, bo puszcza się procedurę na sucho, i patrzy, jak się wykonuje. Ale jak będzie to procedura na kilka godzin toczenia, to już tak fajnie nie jest...

Zresztą już tak było, że ja o czymś pisałem, tyś twierdził, że ci to zupełnie niepotrzebne, a potem pytałeś, czy już to zrobiłem, bo i tobie zaczyna przeszkadzać. Pamiętasz?

Dla porządku przypomnę - w NGCGUI fokus ucieka z okienka formularza razem z kursorem myszki. A nie powinien. I to jest kolejna prośba do autorów softu.

Nie ma znaczenia, czy poskładasz skomplikowany detal z dziesięciu prostych procedurek, czy pięcioma wywołaniami kobyły. Na podglądzie musisz widzieć kolizje. Na dziś poszczególne zakładki nie dziedziczą po sobie, nie sprawdzają też, co robiła poprzednia. Zwizualizowanie przejazdu między zakładkami nie jest jakąś wielką trudnością, a życie ułatwi.

Ty swoją metodą i swoimi procedurami detalu ze zrzutu nie złożysz. Chyba, że sobie napiszesz dodatkową zakładkę na przejazdy między zakładkami.

W profesjonalnym programie bez wizualizacji wprowadzasz do maszyny kod z CAM-a, gdzie jak najbardziej jest wizualizowany. Tutaj mamy wszystko w jednym, i tak, jak ty pragnąłeś widzieć wymiarowanie w średnicach, tak ja bardzo pragnę widzieć przejazdy między zakładkami

Piszący to w procedurze uwzględnił, ale operator musi w podglądzie widzieć.

Po to założyłem temat, żeby szersze grono mogło się wypowiedzieć.

Na tę chwilę ustaliliśmy, że trzeba wprowadzić dwie zmiany w plikach konfiguracyjnych dla tokarki - ustawienie pracy w średnicach jako default, i poprawka w ustawieniach tabeli narzędzi.

Przy przejściach między zakładkami NGCGUI wizualizacja jest niezbędna. W widocznym wyżej przykładzie nie pomoże G61, trzeba dać G0 x#<srednica_materialu> po drugiej zakładce, inaczej pojedzie po skosie. I ta jazda po skosie musi się pokazywać na podglądzie, jeżeli NGCGUI ma być profesjonalnym narzędziem pracy.

OK, nie wiem, czemu sobie zakonotowałem ciebie jako autora interfejsu Ale to na tę chwilę nieistotne. Ja sam ze względu na słabą umiejętność pisania w lengłydżu, nie przebiję się z tematem na emc-developers. Z pomocą tuxcnc udało się tam uzyskać pomoc odnośnie zwiększenia ilości dostępnych dla podprocedury zmiennych, ale juz moje pytania odnośnie wizualizacji przebiegów między zakładkami NGCGUI przeszły bez żadnej odpowiedzi.

Ustawienie G7 jako default to kwestia bardziej porządkowa, każdy sobie to może ustawić, ale początkującym będzie łatwiej, jak dostaną gotowe prawidłowe configi.

Przebiegi między zakładkami są istotne, i to chyba dotyczy w równym stopniu również frezarki.

Na pierwszym zrzucie widać przebieg noża między dugą a trzecią zakładką, dorysowany ręcznie. Drugi zrzut przedstawia realną wizualizację. Jak operator uwierzy, że jest prawidłowa, to mamy piekną kolizję. Ja się tego dowiedziałem w realu, jak mi nóż wjechał w materiał, choć się tego nie spodziewałem.








No a kwestia tabeli narzędzi, która ich nie umiejscawia w czasoprzestrzeni to już zupełna podstawa. Nie doszedłem jeszcze do faktycznego użycia tego na maszynie, ale pisana procedura już taką możliwość uwzględnia. Tyle, że choć mogę sobie zażyczyć zmiany noża w trakcie procedury, to zmieniony nóż nadal będzie szukał materiału tak jak poprzednik, i nie ma w tej chwili możliwości poinformowania programu o jego właściwym ofsecie.

Po bliższym zaznajomieniu się z programem, i jego możliwościami ogólnie z jego działania jestem zadowolony. Jednak interfejs obsługi tokarki został potraktowany nieco po macoszemu, co zresztą sam micges w jakimś wątku pośrednio potwierdził, pisząc, że sprawdzał go jedynie dwa razy na realnej maszynie.

Po pierwsze - wszystkie przykładowe configi tokarkowe powinny zostać uzupełnione o linijkę
w sekcji [RS274NGC]. Tokarka pracuje defaultowo w średnicach, i tak powinna startować.

Po drugie - brak wizualizacji przebiegów noża między zakładkami NGCGUI to poważne zagrożenie kolizją - to, że nóż po zakończeniu pracy w jednej zakładce przechodzi do kolejnej przez materiał widać dopiero na wizualizacji gdy jedzie.

Po trzecie - wyszło to wczoraj w dyskusji w innym dziale - brak jest możliwości ustawienia korekty położenia narzędzia względem bazy maszynowej w tabeli narzędzi. Skutek jest taki, że co z tego, że se mogę zażyczyć zmiany narzędzia w trakcie pracy, jak po zmianie ono będzie miało czubek w zupełnie innym miejscu, jak zapamiętany dla poprzedniego ofset?

Sprawa się wyjaśniła - problem wynika z błędu w przykładowym pliku .ini dla tokarki, nie wpisano w nim kolumn dla ofsetów osi z i x. Należy to sprawdzić i poprawić we wszystkich przykładowych configach.

To się pojawiło w configach tokarki wersji 2.6.0 pre.
Gdyby wyglądało to tak:
nie miałbym żadnych problemów, ani wątpliwości, co trzeba poprawić.

A powinno wyglądać tak:
Wtedy nic bym nie musiał poprawiać.

Kolejna sprawa: w NGCGUI fokus ucieka z okienka formularza razem z kursorem myszki. A nie powinien.

Kolejna sprawa: Procedurę, poskładaną z kilku zakładek NGCGUI można zapisać przez "Zapisz plik g-code". Miło by było, gdyby przy wciąganiu jej do programu LinuxCNC rozpoznawał, że to jest składanka NGCGUI, i tworzył odpowiedni zestaw wypełnionych danymi z pliku zakładek, co umożliwiałoby edycję zaprogramowanego dawno detalu.

Plik zawiera dość informacji, by to było wykonalne, kwestia dostosowania systemu, importującego pliki z G-code do współpracy z NGCGUI.