Re: G code изпълнение на C
За кои алгоритми точно става на въпрос -тея за парсване на G-кода или тея за изчисляване на траекторията. G-кода си е език, целта е ясна - да се поддържа 'сключаемост' (closure properties under union, concatenation...etc) Т.е. -като конкатнеш G-код А с G-код Б пак да получиш като цяло G-код който да е работещ без необходимост от преработка.
При това механично събиране на по-прости структури за да се получи по-сложна , трябва да има механизъм за проверка на получената нова структура дали е реална или е нерална (примерно дали ЦНЦ-крана защипва контейнера, дига го, придвижва го до крайната точка над тира , сваля , отваря щипките) или ( защипва, дига , стига до средата, отваря щипките и пуска на главите, продължава към тира, снижава и го затоварва с въздух)... За разпознаване на правилни структури си трябва парсер, граматика която да описва шаблона на правилните структири без да се фиксира на конкретиката, стек който да се пълни с тая граматика(шаблон) и после да се изпразва срещу конкретно зададената уникална структура. С уговорката че хич не съм разбирач по темата, но толкова ли е лесно да се синтезира на FPGA секвенциална логика която
не е от класическия тип FSM (Mealy; Moore) a e тип PDA със стек ? По-рано си направих устата да задавам тоя въпрос тука (но хората не хукнаха да отговарят) понеже или не го зададох както трябва, или въпроса и отговора хич не са популярни. Може ли и ако да -как ще се симулира стека на PDA-то на FPGA ( с шифт регистър? ).
На Sub-routines (примитивите от действия) от които е изградена дадена дадена G-команда може да се гледа като на хомоморф на целия G-code, т.е.- ако той се парсва като правилна структура, това гарантира съб-рутините(изчисляване на собствените текущи координати , новите желани координати и траекторията) и те да са в правилната последователност.
...До колко и как въобще съществува целия тоя процес... от реализация на конкретна машина... до конкретна смешко-машина...
Навигационните алгоритми вътре в съб-рутините (на не-ЦНЦ автопилот) (реално не виждам защо на ЦНЦ-автопилота трябва да се различават):
вариант 1: изчисляване на всички точки по кривата и траектория по права линия директно м/у текущата Т1 и следващата желана точка Т2( която траектория резултира в конкретно съотношение на стъпки по координати X спрямо Y) . Това съотношение се запазва постоянно по време на придвижването (движение по азимут). Тоя подход изисква определена идеализация условията на околната среда (известна доза пожелателно мислене, идеално хомогенен материал който се работи или ЦНЦ-кран действащ в идеални условия на безветрие). При такива условия ако тръгнем от точка Т1 и се движим по права линия ще стигнем точно над точка Т2. Ако обаче 'подухва вятър' ще дрифтираме малко вляво или вдясно от Т2.
вариант 2: (вдъхновен от механиката на реактивния полет на голяма височина при липса на въздух под крилете - което си е съчетание от две отделни движения -падане надолу към повърхността на извит обект и движение напред (двете в баланс).
И вариант 2 при ЦНЦ-то (пак с уговорките че работим по метода на 'търговеца който знаел нищо за всичко')
-изчисляване на желаната идеална траектория по крива от Т1 до крайната Тn
-изчисляване на траекторията директно по права от T1 до Tn (което резултира в определено съотношение стъпки по X спрямо стъпки по Y )
-тръгване на инструмента директно към Тn
-следене на отклонението вляво/вдясно на текущата позиция от идеалната траектория(по два три под-метода дрифт ъгъл, дрифт дистанция...) и постоянна корекция на съотношението стъпки по X и по Y, така че докато уж е тръгнало директно към Tn, да вземе на практика да мине през кривата.
Такиви ми ти работи -машини и машинки. Я кажете по-добре може ли да се синтезира G-code parser и др. парсери (PDA със стек) на FPGA
За другите работи е ясно че може - драйвер за стъпкови( да не се прави МЦУ-то на телефонистка от миналия век) , тру sine wave генератор и т.н.
може да има отношение към изпълнението на заданието но не и самото изчисляване на заданието.
