Ja na początku też używałem komputera stacjonarnego do sterowania plazmy, co niestety nie zdawało egzaminu - po zajarzeniu łuku spadki napięcia były tak duże że mi resetowało komputer. Rozwiązaniem w moim przypadku był laptop z dobrą baterią (IBM Thinkpad - z tego co pamiętam T43). Myślę, że UPS mógłby pomóc, ale to niech się wypowiadają ci, co mają na ten temat większe pojęcie.1. Czy popełniłem duży błąd stawiając komputer na podstawie ruchomej połączonej z ramą albowiem zawiesza mi się przy odpalaniu łuku?
W machu rozwiązałem to tak, że do pliku z poleceniem dopisałem wiersz "g31 z0". Chodzi o to, że palnik schodzi do z0, dopóki nie będzie sygnału "probe". W moim przypadku sygnałem "probe" był sygnał zajarzania łuku z czujnika THC (widzę że masz taki sam). Wykorzystałem tutaj zajarzanie łuku podczas zbliżania palnika do materiału. Czyli wyglądało to tak: polecenie M3 -> załączenie palnika -> zjazd palnika do materiału -> jeżeli łuk się zajarzał to wykonywało kod dalej, a jeżeli nie to palnik stawał w pozycji z0 i (niestety) kod wykonywał się dalej. Jakby coś podobnego zrobić w LinuxCNC to myślę, że też zdałoby egzamin.2. Jak rozwiązać wykrywanie materiału i jakim g-kodem to podpisać?
Pewnie już znasz ten wątek: https://www.cnc.info.pl/topics54/thc-w- ... t37495.htm. Ja niestety na tym poległem. Z tego co kojarzę to oś Z nawet się poruszała z THC, ale nie aktualizowało współrzędnych, co zadecydowało o zrezygnowaniu z THC. Poza tym nie miałem mojego "magicznego" g31.Jak zmusić LinuxCNC do współpracy z THC?
A czy to ważne że koloruje?4. Jakiego płynu używacie w stołach wodnych albowiem u mnie woda mocno koloruje![]()


A co do macha, to fakt, wygląda bardzo skomplikowanie, ale 1 dzień pracy i wszystko staje się prostsze. O wiele prostsze jak Linux, nad którym straciłem kilka dni a i tak nie doszedłem do porozumienia. Ale to już kwestia gustu.