Tym, że ma jedną nóżkę od drugiej

I tym się właśnie różni podejście użytkowników oprogramowania z zamkniętym kodem źródłowym od tych, którzy sobie mogą dowolnie w swoim programie pogrzebać.

W życiu by mi nie przyszło do głowy tworzenie maszyny, którą sterować można tylko przez skomplikowane makro, usuwające skutki działania wbudowanego w program planera.

Można używać mikroskopu do tłuczenia orzechów. Jednak młotek jest skuteczniejszy. I się przy tej robocie nie psuje...

Nie trzeba być programistą - za takie usługi się po prostu programiście płaci. Sterowanie maszyną ma być proste jak budowa cepa.

ezbig - mylisz się. Silniki, powyciągane z maszyny, nadal będą się kręcić według założeń dla maszyny z jednym narzędziem, poruszającym się w wielu płaszczyznach. Żeby nimi zarządzać g-codem w czasie rzeczywistym i w realnych wymiarach, trzeba z planera wywalić wzory, określające zależności między osiami.

I nadal nie wiem, czy konstrukcja polecenia uruchomi je wszystkie z podanymi szybkościami, czy też zostanie zastosowana pierwsza albo ostatnia dla wszystkich odpalonych osi.

Z tego, co autor wątku napisał wynika, że on chce obsługiwać w czasie realnym kilka niezależnych narzędzi pracujących na pojedynczych osiach, a nie jedno, pracujące w kilku osiach. G-code do tego nadaje się kiepsko, bo nie do tego zostało stworzone.

HAL pozwala na pisanie modułów do obsługi niekonwencjonalnego sprzętu - i być może trzeba by było zaingerować również w interpreter g-code, żeby osiągnąć niezależną pracę osi.

Co konkretnie potrzeba by zrobić, okazałoby się po ujawnieniu dokładnej specyfikacji potrzebnych ruchów osi.

Na Linuxa na stałe przesiadłem się gdzieś w 1997 albo 98. Używałem go na serwerze od kilku lat wcześniej, wersje z nakładką graficzną wymagały wtedy bardzo mocnego sprzętu. Mój katalog domowy zawiera pliki właśnie od tamtej daty. W międzyczasie wielokrotnie zmieniała się dystrybucja i wersja używanego Linuxa - RedHat, Slackware, Mandriva, Mint Ubuntu, ale pliki, poczta, etc wciąż są ze mną.

Dysk z Linuxem można podpiąć do dowolnego komputera, i po prostu będzie działał. Shit nie ruszy. Shit podpięty do sieci bez antywirusa jest zainfekowany wirusami niemal natychmiast - często już w trakcie instalacji. 90% komputerów z Windows podpiętych do sieci to zombie, rozsyłające spam, wirusy i dokonujące ataków DDOS.

Jedyną zaletą Windows jest jego popularność, powodująca powstawanie oprogramowania użytkowego głównie na tą platformę.

Nie jest łatwiej, jeżeli czasy zachodzą na siebie.

Z g-codem jest tak, że komendy wydane w jednej linii wykonują się wspólnie, ze wspólną szybkością, a raczej z szybkością wynikającą z wyliczeń programu, inną dla każdej z osi, ale taką, by wszystkie wektory spotkały się w punkcie docelowym jednocześnie.
Komenda podana w kolejnej linii wykona się dopiero po zakończeniu ruchów zapodanych wcześniej.

Tymczasem mamy sytuację, gdy oś X startuje z prędkością V1, sekundę potem startuje Y z prędkością V2, jeszcze pół sekundy później ma wystartować Z z prędkością V3. Z tym, że Y ma wykonać trzy nawroty i zakończyć sekundę przed X, a Z ma zrobić dwa nawroty i zakończyć dwie sekundy po wszystkich innych.

Napisanie tego w g-codzie jest realne, ale prościej zaprogramować to w PLC.

Jeżeli wszystkie osie mają startować i stawać jednocześnie, tylko drogi i prędkości mają być różne, to da się to załatwić g-codem, albo przez odpowiednie przeskalowanie osi. Schody się zaczynają, gdy czasy startów i stopów mają być różne dla każdej z osi.

Tutaj wszyscy są zaprogramowani monotematycznie

W każdym razie nie osiągniesz tego, co potrzebujesz, przez prosty g-code zinterpretowany przez Macha, czy LinuxCNC. Jeżeli nie boisz się wyzwań, i łatwo się uczysz, HAL z LinuxCNC jest rozwiązaniem. Tomcat sporo przesadza z tym straszeniem - Linux wcale nie jest ani taki trudny, ani się nie psuje tak łatwo.

Z wypowiedzi autora wynika, że chce jednocześnie sterować w czasie realnym trzema niezależnymi narzędziami, czy też osiami. Tymczasem program typu Mach steruje zawsze jednym narzędziem na raz, wszystkie osie są na sztywno dowiązane do wierzchołka narzędzia. Program przelicza, o ile każda z nich ma się przesunąć, by ten wierzchołek poruszał się zaprogramowaną trasą.

W LinuxCNC jest HAL, czyli warstwa pośrednia między interpreterem g-codu a sterownikami, którą można wykorzystać do zaprogramowania sterowników z pominięciem interpretera g-code. Wtedy każdy ze sterowników działa osobno według własnego rozkładu jazdy, i wszystkie robią to równocześnie.

Coś mi się widzi, że nie rozumiesz idei działania g-code. Tu wszystkie osie są powiązane, i polecenie g-code, odnoszące się do trzech osi przemieszcza zawsze jeden punkt w przestrzeni. Ewentualnie można temu punktowi jeszcze ową przestrzeń obracać osią obrotową, czy tworzyć inną kinematykę, ale zawsze program koncentruje się na jednym punkcie, jakim jest ostrze narzędzia.

A ty potrzebujesz przemieszczać trzy punkty na raz.