cnc.info.pl - FORUM CNC

tuxcnc

Walki z wiatrakami ciąg dalszy....

G-kod ścieżek generuje się poprawnie, ale plik wierceń za cholerę nie chciał...
Tutaj to już myślałem że szlag mnie trafi...
Co prawda domyślałem się, że jeżeli plik nie jest generowany, to się program gdzieś wywala, ale robił to tak dyskretnie, że podejrzanych nie było...
W końcu zobaczyłem w dolnym rogu okna taki skromny komunikat:

No to see shell, ale tam żadnego komunikatu o błędzie nie było...
Program tylko raportował:

Kod: Zaznacz cały

[DEBUG] Creating CNC Job from Excellon for tool: 1
[DEBUG] Using OR-Tools Basic drill path optimization.

W końcu, z braku innych pomysłów, postanowiłem poszukać tego OR-Tools i znalazłem FlatCAM_beta_8.994/appTools/ToolQRCode.py
Szybki test:

Kod: Zaznacz cały

# python3 ToolQRCode.py 
Traceback (most recent call last):
  File "/opt/FlatCAM_beta_8.994/appTools/ToolQRCode.py", line 11, in <module>
    from appTool import AppTool
ModuleNotFoundError: No module named 'appTool'

No i niby wszystko wiadomo, ale zrobić nic się z tym nie da...
Nie ma pakietu appTool w Ubuntu 22.04...
Jest apptools (s na końcu), ale to najwyraźniej nie to samo...
Natomiast istnienie popularnego pakietu apptools powoduje, że Google za żadną cholerę nie chce szukać appTool...
Normalnie masakra....
Jedyne co mi przyszło do głowy, to znaleźć wywołanie ToolQRCode.py, zakomentować je i zobaczyć co się stanie...
No to poszukałem pliku zawierającego ciąg "Using OR-Tools Basic drill path optimization" (tak, tak, komunikaty nie biorą się znikąd...) i w FlatCAM_beta_8.994/camlib.py znalazłem następujący fragment:

Kod: Zaznacz cały

        # #############################################################################################################
        # #############################################################################################################
        # ##################################   DRILLING !!!   #########################################################
        # #############################################################################################################
        # #############################################################################################################
        if opt_type == 'M':
            log.debug("Using OR-Tools Metaheuristic Guided Local Search drill path optimization.")
        elif opt_type == 'B':
            log.debug("Using OR-Tools Basic drill path optimization.")
        elif opt_type == 'T':
            log.debug("Using Travelling Salesman drill path optimization.")
        else:
            log.debug("Using no path optimization.")

Jak widać, w zależności od wartości zmiennej opt_type są wybierane różne opcje, z czego dwie mają w nazwie trefne "OR-Tools", ale trzecia nie...
Pierwsze o czym pomyślałem, to w preferencjach zaznaczyć opcję "Travelling Salesman", ale się okazało że zaznaczać można sobie do woli, a i tak wywala komunikat "Using OR-Tools Basic"....
No coś jest totalnie spieprzone, może celowo, czasem się zdarza że autor blokuje funkcje które go nie satysfakcjonują, ale zostawia je w menu, bo ma nadzieję kiedyś to poprawić...
W każdym razie miałem już dość kombinowania i zrobiłem numer chamski, ale skuteczny:

Kod: Zaznacz cały

        # #############################################################################################################
        opt_type = 'T'
        if opt_type == 'M':

To opt_type = 'T' trzeba zapisać z poprzedzającymi spacjami, nie używać klawisza TAB, bo python jest wrażliwy na formatowanie...
Nietrudno się domyślić, że bez względu na to co było wcześniej, od tej linii będzie użyta opcja "Travelling Salesman", nie używająca trefnego OR-Tools z trefnym importem appTool....
Ta optymalizacja działa dość kiepsko, ale działa i g-kod jest generowany...
Jak pisałem wcześniej, windowsowa wersja robi problemy z unicode, więc pomimo tego skopanego eksportu wierceń, wersja na Linuksa może być atrakcyjna, a że maszyna będzie wiercić trochę dłużej da się przeboleć...

tuxcnc

grg12 pisze: ↑
09 kwie 2023, 12:43
Aż dziwne że taki nowoczesny i popularny język nie ma jakiegoś narzędzia kontroli wersji

Ale tutaj akurat nie ma czego kontrolować, wiadomo że będzie działać na 3,9 i żadnym nowszym.
Problem polega na wyborze tragicznym (jeśli możesz się otruć albo powiesić, to teoretycznie wybór masz) czy zepsuć Linuksa robiąc downgrade Pythona, czy zmarnować wiele godzin na dłubanie w kodzie i zmienianie literek, bo jakiemuś kretynowi stara nazwa się nie podobała...
Ten ostatni wykryty problem jest teoretycznie prosty, trzeba tylko dopisać literki int przed kilkoma nawiasami, tylko nie bardzo wiadomo gdzie...
No i oczywiście zero gwarancji, że się program nie wywali na jakiejś następnej debilnej "poprawce"'...
Ludziom się wydaje, że programiści to jacyś wyjątkowo inteligentni ludzie, a tak naprawdę pełno wśród nich debili, którzy niewiele rozumieją, za to dobrze pamiętają co powinni napisać, bo kiedyś gdzieś to zadziałało...

No ale skoro już jestem przy tablicy, to napiszę o kolejnym irytującym problemie.
Flatcam to program pisany pod Windows, przez miłośników Windows, którzy o istnieniu Linuksa coś tam słyszeli, ale ich to nie interesuje...
Tak więc mamy nie tylko windowsowe kodowanie końca linii (to akurat można poprawić dos2unix), ale też windowsowe kodowanie znaków narodowych, a nie unicode będące standardem w Linuksie...
No i teraz mamy taki kwiatek...
W KiCAD autor tłumaczenia nazwał sobie warstwę "Dolna sygnałowa", niby poprawnie, ale z polskim znakiem...
Przy eksporcie do gerbera nazwa warstwy jest dodawana do nazwy pliku...
Flatcam dodaje do g-kodu linię komentarza z nazwą pliku źródłowego, ale literkę "ł" koduje po windowsowemu...
G-kod w bCNC się nie otwiera, bo wywala błąd unikodu...
Wszystko się rozpieprza o linię KOMENTARZA !!!
No i znowu tragiczny wybór, czy spieprzyć tłumaczenie w KiCAD, czy zmieniać nazwy wygenerowanych plików gerber, czy edytować g-kod żeby poprawić jedną literę w komentarzu....
(We Flatcam nie warto dłubać, bo tam część kodu jest skompilowana do postaci binarnej...)

Dodane 45 minuty 52 sekundy:
Przemyślałem sprawę i wróciłem do edycji linuksowego kodu...
W pliku FlatCAM_beta_8.994/appGUI/GUIElements.py trzeba znaleźć ten fragment:

Kod: Zaznacz cały

    def setMinimum(self, value):
        return super(FCDoubleSlider, self).setMinimum(value * self._multi)

    def setMaximum(self, value):
        return super(FCDoubleSlider, self).setMaximum(value * self._multi)

    def setSingleStep(self, value):
        return super(FCDoubleSlider, self).setSingleStep(value * self._multi)

    def singleStep(self):
        return float(super(FCDoubleSlider, self).singleStep()) / self._multi

    def set_value(self, value):
        super(FCDoubleSlider, self).setValue(value * self._multi)

    def set_precision(self, decimals):
        self._multi = 10 ** decimals

    def set_range(self, min, max):
        self.blockSignals(True)
        self.setRange(min * self._multi, max * self._multi)
        self.blockSignals(False)


class FCSliderWithDoubleSpinner(QtWidgets.QFrame):

    def __init__(self, min=0, max=10000.0000, step=1, precision=4, orientation='horizontal', **kwargs):
        super().__init__(**kwargs)

I zmienić żeby było:

Kod: Zaznacz cały

    def setMinimum(self, value):
        return super(FCDoubleSlider, self).setMinimum(int(value * self._multi))

    def setMaximum(self, value):
        return super(FCDoubleSlider, self).setMaximum(int(value * self._multi))

    def setSingleStep(self, value):
        return super(FCDoubleSlider, self).setSingleStep(int(value * self._multi))

    def singleStep(self):
        return float(super(FCDoubleSlider, self).singleStep()) / self._multi

    def set_value(self, value):
        super(FCDoubleSlider, self).setValue(int(value * self._multi))

    def set_precision(self, decimals):
        self._multi = 10 ** decimals

    def set_range(self, min, max):
        self.blockSignals(True)
        self.setRange(min * self._multi, max * self._multi)
        self.blockSignals(False)


class FCSliderWithDoubleSpinner(QtWidgets.QFrame):

    def __init__(self, min=0, max=10000, step=1, precision=4, orientation='horizontal', **kwargs):
        super().__init__(**kwargs)

Zmienić trzeba tylko cztery linie, trzy ze wspomnianym int przed nawiasem (nawiasy też trzeba dodać), oraz definicję zmiennej max (cztery zera po kropce definiują ją jako zmienną float, a bez kropki i zer jako int).
Teraz już zmienne są int zamiast float i program się nie wywala.

Dodatkowo linuksowa wersja obsługuje unicode i nie ma problemu z polskimi znakami w nazwach plików...

BTW. Znalazłem w necie informację, że autor spieprzył w wersji 8.994 obsługę freza typu V i zaleca żeby z domyślnego V przestawiać na Cx, i głębokość ustawiać ręcznie.
To jest to okno:

tuxcnc

tuxcnc pisze: ↑
21 lis 2022, 22:23
Po tej walce program daje się uruchomić i chyba wszystko działa jak potrzeba.

Niestety nie działa.
Przy próbie wygenerowania g-kodu program wywala błąd, że dostał zmienną typu float...
To ten sam cyrk, że domyślną konwersję typów zamieniono na jawną.
Oczywiście wystarczy gdzieś przed nawiasem dopisać trzy litery int, ale tym razem nie wiem gdzie, więc na razie dałem sobie spokój.
Autor programu o problemie wie już od jakiegoś czasu, u siebie poprawił, ale innym obiecuje że będzie działać w nowej wersji, którą wyda w nieokreślonej przyszłości, jeśli w ogóle wyda...
Wróciłem do windowsowej wersji pod wine...
Zapewne dałoby się spakować Flatcam razem z Pythonem 3.9 do appimage i stworzyć program niezależny od wersji systemu operacyjnego, ale to sporo roboty, a motywacji brak...

tuxcnc

Uparłem się zainstalować Flatcam na Xubuntu 22.04.
Do tej pory używałem wersji dla Windows uruchamianej pod wine, ale z tym to zawsze są jakieś problemy...
Opis instalacji znalazłem kiedy już walczyłem z ostatnim problemem, najwyraźniej tym razem nie miałem szczęścia...
https://bitbucket.org/jpcgt/flatcam/iss ... t-64476836
Autor opisu trochę namieszał, brak pyserial w systemie to nie jest żaden błąd, tylko po prostu brak.
Natomiast brakuje informacji o sprawie wyjątkowo ważnej, mianowicie że program jest pisany pod Windows i ma windowsowe kodowanie końca linii. W takiej sytuacji rozwiązaniem jest wydanie w głównym folderze programu polecenia

Kod: Zaznacz cały

find . -type f -print0 | xargs -0 dos2unix

Jeśli nie ma w systemie dos2unix, to trzeba go najzwyczajniej zainstalować przez apt.
Potem jest sprawa wykonywalności FlatCAM.py
Autor co prawda nie popełnił żadnego błędu, ale wybrał metodę uruchamiania uciążliwą pod Linuksem, mianowicie przez polecenie python3 FlatCAM.py
Pod Linuksem jednak jest wygodniej dodać na początku pliku

Kod: Zaznacz cały

#!/usr/bin/python3

oraz nadać plikowi atrybut wykonywalności, co daje możliwość uruchomienia programu podając tylko jego nazwę.

No dobra, czas na pierwsze uruchomienie programu.
Kończy się to wywaleniem komunikatu o błędzie:

Kod: Zaznacz cały

AttributeError: module 'collections' has no attribute 'MutableSequence'

Typowy debilny komunikat Pythona, "moduł nie ma atrybutu" i szukaj wiatru w polu...
Na szczęście Google już o tym wie i jak ktoś sprytny to znajdzie.
Wytłumaczenie jest wyjątkowo proste i sprowadza się do mojego ulubionego powiedzenia, że "Python to nie jest zwykły burdel, to jest burdel w którym każdy klient przestawia meble po swojemu"...
O ile jeszcze można zrozumieć niekompatybilność Pythona 2,7 z 3.0, no po prostu się nie dało, to jak wytłumaczyć niekompatybilność Pythona 3.9 z 3.10 ???
Otóż tym razem jakiś kretyn sobie wymyślił, że moduł "collections" będzie się od teraz nazywał "collections.abc"...
Zmiana niewielka, ale zupełnie wystarczająca żeby mnóstwo kodu napisanego wcześniej przestało działać wyświetlając debilny komunikat "moduł nie ma atrybutu"...
Podobnie jest z ezdxf.math.vector, który od teraz nazywa się ezdxf.math a Vector nazywa się Vec3 ...
Skutek identyczny.
Powyższe błędy da się usunąć edytując odpowiednie pliki, ale z vispy namieszali już tak, że nie ma wyjścia i trzeba odinstalować najnowszą wersję (0.12) i zainstalować starą (0.7)...
No to już jest najzwyklejsze psucie systemu, bo cholera wie co nie zadziała, bo dla odmiany będzie potrzebowało wersji 0.12 a nie 0.7...
No ale wyjścia nie ma.
Po tej walce program daje się uruchomić i chyba wszystko działa jak potrzeba.
Ale Pythonowi dobrze na przyszłość nie wróżę, bo ostatnio czego bym nie próbował uruchomić, to bez dłubania w kodzie nie daje rady.
Podobne cyrki miałem z dxf2gcode, gdzie dla odmiany konwersja typów odbywała się dotychczas z automatu, a teraz jakiś debil wymyślił że musi być jawnie deklarowana, co też skutkuje wywaleniem debilnego komunikatu błędu i zamknięciem programu...

Znaleziono 4 wyniki

Re: Flatcam na Linuksie, czyli burdel zwany Python

Re: Flatcam na Linuksie, czyli burdel zwany Python

Re: Flatcam na Linuksie, czyli burdel zwany Python

Flatcam na Linuksie, czyli burdel zwany Python

TS Płytki montażowe przykręcane

Bit Standard, płaski, C 6.3, 0.8 x 5.5 WIHA

Znaleziono 4 wyniki

Re: Flatcam na Linuksie, czyli burdel zwany Python

Re: Flatcam na Linuksie, czyli burdel zwany Python

Re: Flatcam na Linuksie, czyli burdel zwany Python

Flatcam na Linuksie, czyli burdel zwany Python

TS Płytki montażowe przykręcane

Bit Standard, płaski, C 6.3, 0.8 x 5.5 WIHA

Zaloguj się • Zarejestruj się

Połącz się z kontem sieci społecznościowej