Ja zamieściłem Gkod który realizuje Mach. Ze zrzutami z ekranu i trajektorią po zastosowaniu kompensacji.
Ty zamieszczasz inwektywy.
Wiesz w rodzinie jest psychiatra to i mam zwiększoną tolerancję dla odmieńców. Wszak to też ludzie.
Ale może puścisz sobie ten pliczek.
Potrafisz skopiować na swoją maszynkę?
A w ogóle to masz jakąś aby sprawdzić? Czy temat tylko rozumiesz, ale tak teoretycznie.
Taki jednonogi teoretyk trójskoku.???

TOP67 pisze: ↑

03 maja 2022, 20:04

On wysyła tylko kontur i chce przy pomocy korekcji odsunąć ścieżkę o promień narzędzia.
Ty generujesz ścieżkę narzędzia i nie potrzebujesz używać korekcji

sześciopak temu kto rozróżni czy Gkod przedstawia ścieżkę narzędzia czy kontur.
Interpreter też tego nie wie.
Przecież to sekwencja współrzędnych kolejnych wektorów. I dodatki porządkujące skrawanie.
System reaguje tylko na polecenie G41/42 wg którego zmienia współrzędne ruchu narzędzia. No i liczy na bieżąco poprawki jeżeli potrafi a że czasem nie potrafi to patrz wyżej.

TOP67 pisze: ↑

03 maja 2022, 20:04

A jak używasz, to właśnie w celu dla którego to zostało stworzone, czyli kompensacji rzeczywistej średnicy narzędzia od wartości nominalnej.

Niezupełnie. Używasz bo w trakcie obróbki chcesz mieć wpływ na wynik.
Ciaśniej, luźniej a i czasem frez za mały też. Ale to powody są różne. Podstawowym jest chęć zmiany na maszynie.

TOP67 pisze: ↑

03 maja 2022, 20:04

A autor właśnie potrzebuje korekty ujemnej. Jak widać w LinuxCNC jest możliwa, ale nie w narożach.

czyli nie jest możliwa.
A jeżeli traktować to że korekcję wykonuje to tak nieudolnie że wstyd się przyznawać. Jakieś łuczki, poprawki, dodatki dla pliku np z krzywymi realizowanymi interpolacją odcinkową.
Wyobrażasz sobie? 2 miesiące grzebania palcem w tyłku. Dobrze że jesteś niepalący bo byś wtedy palenie ze wstrętem rzucił.
Zrób takie poprawki dla jakiegoś reliefu który trzeba ofsetować na wybranych obszarach.
Bo taka jest potrzeba. I co nie da się?

A korekcja o ujemnych wartościach to zwykła sprawa. Wprawdzie Mach nie robi , Linux też nie( bo nie robi żadnej oprócz figur wypukłych !!!TYLKO!!!) ale w poważniejszych sterowaniach jest.
Tyle że wyznacznikiem standardów dla Tuska jest znajomość jego okrojonej w funkcjonalności wersji Linuxa. Który ledwo kulawo nadąża za tymi przywoływanymi standardami obowiązkowo do stosowania.
No Mach akurat tu jest lepszy.

tuxcnc pisze:Nie ma korekcji dodatniej i ujemnej.
Jest korekcja po prawej i po lewej stronie konturu

Masz zaskakującą zdolność potykania się o własne kapcie
G41 to tak jakby ujemna G42. I odwrotnie.
Sądzisz że ludzie tego nie potrafią wyliczyć i wstawić algorytm do stosowania?
To że tego nie masz świadczy tylko to że tego nie masz a nie że nie istnieje.

P.S. nudzisz z tymi idiotami. Takie puszczanie wiatrów przy stole.

Dodane 6 minuty 29 sekundy:

drzasiek90 pisze:A co w takiej sytuacji zrobi sterownik stosując korekcję średnicy narzędzia?

Przeczytj co napisałem wcześnie, z rysunkami.
A tu skoryguje żsieżkę narzędzia o podane wartości korektora i będzie pruł jak współrzędne wektorów każą.
Mylisz pojęcia "program" z generowaniem Gkodu.
Sterowanie maszyny zajmuje się tylko zgodnością ścieżki z narzuconym parametrem korektora. Nic mu do tego że narzędzie się nie mieści w konturze rysunkowym.
Tym zajmuje się CAM a nie interpreter sterownika.
A gdy wstawisz wariackie wartości korekcji to się wpakujesz. A następnie poprawisz.
A po kilku razach się nauczysz.
I tyle.

Mi korekcja działa ,Tobie nie

Tusku, zachowujesz się jakby każdy chciał Ci jakoś w poprzek zrobić. Bo Ty masz rację a reszta to debile.
Ale dowiodłeś rysunkami swojego wyobrażenia problemu więc ja też coś pokażę.


rysunek z CAMa. Dwa kontury o podstawie 20mm i oba frezowane frezem 10mm z korekcją na ścieżkę narzędzia.
Prawy kwadrat to prosta sprawa, ściezka też jest kwadratem.
Lewy profil celowo ścięty aby frez nie mógł się zmieścić i CAM musiał zdeformować ścieżkę.

Tutaj wygenerowany plik NC z kodami i korekcją.

%

()
N10 G21 G90 G40

N40 G00 G53 Z0
N50 G91 G28 Z0 H0

N70 G90
N80 G54 M05 M9 M06

N90 T00 M01 (OKREŚLA PROGRAMISTA)
N100 S2000 M4 M41 M7

N110 G0 X1.5 Y-4.0
N120 G43 Z5.0 H00 M7
N130 G1 Z-3.0 F150.0
N140 G42 X-1.0 D01 F250.0
N150 G17 G3 X0.0 Y-5.0 R1.0 F187.5
N160 G1 X5.0 F250.0
N170 Y5.0
N180 X-5.0
N190 Y-5.0
N200 X-2.0
N210 X0.0
N220 G3 X1.0 Y-4.0 R1.0 F187.5
N230 G40 G1 X-1.5 F250.0
N240 G0 Z5.0

N250 X-38.055 Y-2.462
N260 G1 Z-3.0 F150.0
N270 G42 X-36.177 Y-4.112 D02 F250.0
N280 G3 X-36.269 Y-2.7 R1.0 F187.5
N290 G1 X-39.167 Y-0.154 F250.0
N300 Y-5.0
N310 X-33.651
N320 X-34.766 Y-4.02
N330 X-36.269 Y-2.7
N340 G3 X-37.68 Y-2.792 R1.0 F187.5
N350 G40 G1 X-35.802 Y-4.442 F250.0
N360 G0 Z5.0

N370 M5 M9
N380 G00 G53 Z0
N390 G91 G28 Z0 H0
N400 G54 G90
N410 M30
%


Jak na razie jest co miało być i o żadnych błędach nic nie krzyczy.
Po wczytaniu do MACH plik przyjęty, wszystko pasuje


tutaj ścieżka obróbki gdy korekcje mają wartość zero. Po prostu aby było widać że MACH to wykonuje.


Tutaj wprowadziłem wartości
dla rejestru 1 wartość korekcji =1
dla rejestru 2 wartość = 10
Narzędzie z korekcją 1=1 obrabia prawy kwadrat i ścieżka jest odsunięta o +1mm od zarysu
Narzędzie z korekcją 2=10 obrabia lewy kontur. Widać że zarys jest powiększony o wpisane +10mm/str.



Te rysunki i plik Gkodu są dowodem na to co pisałem
To co Ty przedstawiasz to jakieś małe kazie z Pitutkowa (bez obrazy dla Pitutkowiczan)
Doucz się facet.

Dla poprawności
W MACH trzeba zaptaszczyć opcję "zaawansowana kontrola korekcj"i czy tak jakoś.
Wartość korektorów w tablicy jest dodatnia gdyż Mach traktuje to jako korekcja ubytku średnicy freza. Nie wykona korekcji na wartościach ujemnych. Czyli frezowaną kieszeń można tylko powiększyć. A stempel pomniejszyć. Tak jakby dostępne było wykonanie detali w tolerancjach H/h.
Ale gdy ma być obróbka na ciasno czyli kieszeń na Js lub dalej to oszukuję system.
Generuje ścieżkę deklarując średnicę freza większą np o 1 mm a w tablicy korekcj wpisuję tą róznicę. W efekcie kontur frezowany jest mniejszym frezem ale tak jakby średnicą nominalną ewentualnie skorygowaną jak jest potrzebne.

I działa. I w du*** mam czy jest zgodne z normą.
Jest zgodne z moją potrzebą.

Tusku, skoro w Linux to nie idzie to TY idź ze swoim Linuxem.

tuxcnc pisze: ↑

03 maja 2022, 10:10

No to jak analfabecie.
Obrazkami.

no dobrze, obrazkami
ta fobia ptaszków zasłania Ci ogląd reszty. Masz bardzo wybiórcze postrzeganie. Z PISem też tak samo bo coś tam zrobił dobrze to już cały jest cacy.

Te Twoje obrazki nie mają nic wspólnego ze ścieżką po korekcji.
Narysowałeś odrębne odcinki i się dziwisz że w narożniku ślad freza zachodzi na ściankę. Bo złożyłeś to ręcznie jak przywoływany tu debil.
Chyba w życiu nie uruchomiłeś korekcji Zaden CAM takich bobków nie generuje tylko odpowiednio skraca ścieżki.
Takie bobki wypisuje taki debil.

Pierwsze lepsze tutoriale pokażą bzdurę tu prezentowaną. Żadnych dodatkowych łuczków nie będzie generowanych

tuxcnc pisze: ↑

03 maja 2022, 10:10

3. Jak prawidłowo wykonać korekcję w takim przypadku, skoro obie zaznaczone korekcje są prawidłowe, co udowodniono wcześniej?

Gdzie udowodniono?
Bo sobie kreski postawiłeś.?
Gdyby OBIE były korekcjami to by były wejścia/wyjścia dla każdej
Jeżeli te kreski są obie Twoimi korekcjami to mogę Ci zaproponować pudełko nieprzydatnych mi frezów. Poćwiczysz.

tak to jest gdy Tuskowi zamachać ptaszkiem przed oczami. Ogon w górę i szarża.
Ale w całych tych wypocinach i tych wcześniejszych jak zawsze sens jest taki że:

Zepsuło się to napraw bo gdy jest dobre to zawsze działa.

Świnto prawda tylko co to wnosi. Każdy pytający sam wie ze się zepsuło.
Ale jakoś nigdy (bardzo rzadko) nie napisze - zrób tak albo tak.Bo nie wie?
Taki erotoman, gawędziarz, ptaszki i ptaszki.

tuxcnc pisze: ↑

03 maja 2022, 07:24

Natomiast przy kompensacji narzędzia NIE nie rysujesz w CAD ścieżki narzędzia tylko kontur który chcesz otrzymać.

Swięta prawda. W CAD masz rysunek konturu i tyle. Żadnych pomysłów o kompensacji. Jak będzie obrabiany to późniejsza sprawa

tuxcnc pisze: ↑

03 maja 2022, 07:24

Projekt tworzony pod kompensację narzędzia powinien mieć zaokrąglone wewnętrzne naroża, promieniem większym niż promień używanego narzędzia.

Taka góralska prawda. co więcej Całkowite zaprzeczenie ortodoksyjnego trzymania się prawdy materialnej że rysunek jest swięty a za nim Gkod powinien być odpowiedni.
Żaden programista nie poprawia żadnych łuczków na rysunku tylko stosuje właściwą strategię, metodę czy sposób - nazwij to jak chcesz.
Natomiast stosowanie automatycznych w całości programów skutkuje bzdurami w genrowanych kodach.
Zwyczajnie - generując kod trzeba wiedzieć na jaką maszynę i co ona potrafi

tuxcnc pisze: ↑

03 maja 2022, 07:24

Bez poprawienia rysunku w CAD nie usuniesz błędu

ortodoks ograniczony zachwytem o swojej ortodoksji.

Gdyby te Twoje poprawne kody zawsze działały bez uwzględniania różnic specyficznych dla poszczególnych maszyn to nie byłoby takiej ilości postprocesorów które te różnice uwzględniają

Tusek ty cienias jesteś i tyle. Bez ptaszka.

A teraz co zrobić
Komunikat pojawia się bo frez pobrany z tabeli narzędzi w maszynie nie mieści się na ścieżce wygenerowanej "na kontur"
I tyle.
Prawdłowo powinien zatrzymać się wcześniej pozostawiając resztki. Większe, mniejsze , czasem tylko wypełnienia kąta
a czasem spore fragmenty wewnętrznego pola w ramionach kąta.
Wprowadzona korekcja powoduje że kolejna, 3 ścieżka następująca po 2, tej która ma być właśnie rozpoczęta już zahacza o kontur.
I tu Tusk ma rację - jest żle. Bo problem dotyczy tego trzeciego ruchu.
Dlatego bezpieczniejsze jest generowanie kodu wg narzędzia (z uwzglednionym przesunięciem dla narzędzia).
Bo gdy bedzie:
frez za mały - to korekcja dodatnia zawsze się zmieści.
frez za duży - to nie jest błędem korekcja ujemna która teoretycznie wchodzi w zarys konturu (tylko nie w Linuksie)
Albo gdy korekcją trzeba podczas obróbki wyluzować kontur. ( czyli teoretycznie wejść średnicą nominalną w krawędź konturu).
Tyle ze funkcje modalne - a taką funkcją jest korekcja - są napisane różnie, zależnie od sterowania wstawionego do maszyny.
W jednej coś obsługują, w innej nie i zgłaszają błąd.
Tu widać korekcja ujemna jest nieobsługiwana.

wybrałeś Linuxa z oczywistych powodów jego wyższości nad innymi. Ja nie godny aby go ogarniać, ja tylko MACH I TO TEŻ ZALEDWIE TO CO POTRZEBUJĘ.
wygeneruj program z korekcją jak napisałem - wg ścieżki osi narzędzia a nie konturu.

Dodane 4 minuty 22 sekundy:

atom1477 pisze:Oczywiście 1) jest wygodniejsze, tylko trzeba to jedno ustawienie zmienić żeby nie wywalało błędów.

wygodne są oba jednakowo. Bez różnicy czy podasz średnicę/promień narzędzia czy wartość poprawki dla danego narzędzia.

tuxcnc pisze: ↑

02 maja 2022, 20:53

LinuxCNC wykonuje program tak, jak jest on napisany, czyli jak chcesz osiągnąć inny rezultat, to napisz inny program.
I żadnych ptaszków NIE MA.

masz ewidentnie jakiś problem z ptaszkiem który coś ma robić. Zostań ornitologiem.

atom1477 pisze: ↑

02 maja 2022, 19:59

Coś pewnie trzeba przestawić w ustawieniach, bo u mnie nie tylko informuje, ale też blokuje wczytanie pliku i obróbkę.

Jak widać tusk nie pomoże.
Ale zwróć uwagę że trajektorię z korekcją można generować na dwa sposoby:
1) wg geometrii gdzie Gkod prowadzi oś narzędzia dokładnie po konturze a korekcja powoduje wyliczenie przez maszynę ścieżki odpowiednio do parametrów (średnicy) narzędzia wyciąganych z tabelki w jej pamięci .
2) wg ścieżki - Gkod podaje trajektorię osi narzędzia już z uwzględnieniem średnicy zastosowanego narzędzia.

Dla sposobu 2) wszelkie dojścia i odpowiednie skróty są już uwzględnione i frez jest prowadzony tak aby nie wbijał się w wewnętrzne ścianki konturu. Korekcja jest wtedy jedynie poprawką ułamkową względem faktycznego wymiaru w obrabianym detalu. Najczęściej jako różnica do narzędzia teoretycznego.

Dla sposobu 1) planar, kernel czy inny dziwoląg który w środku frezarki liczy co trzeba nagle nie potrafi przewidzieć że wcześniej trzeba ścieżkę skrócić aby na zakręcie nie wylecieć poz kontur. I oczywiście gdy średnica narzędzia zapisana w tabeli maszyny jest zgodna z tą od Gkodu.
I tu jest Twój problem (o ile nie wiadomo gdzie w Linuxie wprowadzić zmianę bitową ( w Machu ptaszka) odblokowującą dopuszczalność resztek)
Zmień sposób generowania Gkodu podczas korekcji.

I jeszcze jedno.
W jaki sposób jest realizowana korekcja (ścieżka/kontur) to jest cecha sterowania maszyny i do tego trzeba się dostosować. Chyba że jest możliwość wyboru - w Machu nie ma.

Dodane 7 minuty 42 sekundy:

tuxcnc pisze: ↑

02 maja 2022, 20:53

Mach ma ptaszki, które powodują że ten sam g-kod może być wykonany na sto różnych sposobów i dać sto różnych rezultatów, co jest jawnym debilizmem, choć może się wydawać wygodne.

debilizmem jest posługiwanie się programem mniej wygodnym, wręcz ortodoksyjnie sztywnym bo tak trzeba.
Wyobraź sobie że jednak nic nie trzeba a większość użytkowników ma taką wprawę w obsłudze ptaszka że nie stanowi to żadnego problemu

atom1477 pisze: ↑

02 maja 2022, 15:21

Po to chyba jest G41/G42 żeby maszyna sama już to robiła.

no i robi tylko trzeba wyłączyć/ dopuścić resztki ( jak w Machu)

Najbardziej fenomenalny program, nawet dedykowany tylko pod Linuxa a nie jakieś tam windy,
nie rozwiąże problemu resztek po frezie we wnętrzach kąta wewnętrznego występującego w obrabianym konturze.
A komunikat informuje właśnie o tej niedogodności.
Czyżby linux obrabiał korekcją tylko zarysy wypukłe?