Здравейте! Някой има ли представа какъв е подходът при изпълнение на G2(arc movement) или G81(boring circle) на Ц? Дали предварително се изчислява траекторията, запомня се с РАМ-а и се изпълнява? Или се изчислява точка по точка? Ако е точка по точка няма ли движението да е накъсано, а не плавно? Или се тръгва по някаква траектория и се отклонява в дадена посока, за да се получи арка примерно? Никъде не намирам инфо за самата реализация. Само обясняват как да се сметнат числата в самата команда...
Благодаря!

Github е теоя човек, търси GRBL.
Например https://github.com/grbl/grbl

Мисля, че му хванах цаката! Явно се работи на линеен принцип - разделя се окръжността на малки отсечки и се изчисляват всяка по отделно. То не е сложно така че предполагам при ниска скорост въобще няма да личи. По принцип пише също, че забиват скоростта на някаква ниска стойност и няма acc профил.
Поздрави!

хммм не виждам какво е отношението на скоростта към апроксимацията може да има отношение към изпълнението на заданието но не и самото изчисляване на заданието.

Вероятно за да няма ускорение в началото на всеки сегмент и забавяне в края му.
Когато мача с подходящи настройки оглупее достатъчно, прави такива неща. И ги прави толкова смотано, че чак е трогателен...

самата идея да натикаш FP в мега на 16MHz си е малко....
и след това смело да използваш sin(), cos(), че и atan() даже ?!

реализацията си е чисто учебникарска, без особен практически елемент.
интерполация до дивайс-координати, дори на криви от по-висок порядък като безие, се разписва на 2 странички с целочислена аритметика само. със сплайновете има малко врътка, но принципно не внася кой знае каква допълнителна сложност. и особено, ако предположим, че резолюцията не е особено голяма (да кажем 50-100 микрона), такъв алгоритъм може да фърчи дори на въпросната мега в онлайн-режим и с доста голяма скорост.

отделен е въпроса този проект какво е предназначен да замести - мач3/4/5, лайнукс-CNC или ? на едно място PLC, G-парсер и моушън, в едно чипле за $2?
теглих му един диагонал. да, на ниво ардуино и 2-3 стъпкови моторчета (може би) е ОК. демек -> играчка.
добре е да схванеш принципа и (ако можеш) да си направиш изводите как не трябва да се прави по-сериозно управление.

Познат е използвал GRBL и твърди, че работи без забележки.
Имаше и по-наточена версия - с някакъв ARM.
https://github.com/Schildkroet/GRBL-Advanced

Точно! При сложни калкулации си трябват MIPs. За момента това, което съм подготвил, ще свърши работа. А и ще направя sin и cos като търсене в масив. Не мога да преценя за голяма машина. Дали някоя по-намазана серия uC(примерно някое Delfino на TI) ще свърши работа или директно трябва да се ходи на FPGA. А и не съм наясно с всички команди, които могат да се подадът и какви са алгоритмите, по които работят. Да не говорим, че има случаи, когато по време на изпълнение на командата, операторът може да коригира разни работи...

Какво ще коригира по време на движение? Ами ако сбърка?
Виж на cnc-club.ru
http://www.cnc-club.ru/forum/viewtopic.php?t=7628
http://www.cnc-club.ru/forum/viewtopic.php?p=482699

Може да ти е полезно.

скорост, обороти ..

Имам някъде сорсовете на tcnc (Turbo CNC). Ако ще свършат работа, да ги потърся!?

За кои алгоритми точно става на въпрос -тея за парсване на 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 генератор и т.н.

много глупости се изписаха по тая тема ....

G2/G3 се реализира целочислено дори по-елементарно от G0/G1: на всяка стъпка се прави оценка на грешката и се добявя 0/1 към резултата (Y=f(X)) ... а самата "грешка" се изчислява с 2 операции (* и +)

ако не е пълна окръжност: "най-сложното" е да се определят началната и крайната позиция и да се раздели на квадранти!

Т.е. - при тоя тип корекция (хоминг) точките Т1 , Т2...Тn по окръжността ще са на правилните места, но правите м/у тях ще са... с форма на охлювчета. Това може да е проблем при определени ЦНЦ-та с дебелина на инструмента -косъм (Hairline). (Ако е автопилот на самальот-така минава през небостъргача, вместо по чистия от препятствия път, а ЦНЦ-крана -през кумина на кораба) Ако пък не се коригира траекторията при движение по правата м/у отделните точки(азимут), правите са си прави, но точките са разместени. И двете не са проблем, ако на 'инструмента' не действат силно изразени външни фактори, както не е проблем терморегулатор, който цъка при достигане на желаната температура в камера с постоянна такава. И е проблем, ако поривен вятър засилва контейнера дибидюс с матора на ЦНЦ-то в желаната от него (вятъра) посока, т.е. -дрифта не е резултат от изначално некадърен моушън контрол, а от външни фактори.
Но смисъла на моята тирада по-горе беше максимално да избягам точно от тая част коя баба как си бае навигацията и да попитам -има ли почва 'сеене-то' на G- код директно в/у FPGA.
Щото човека спомена и нещо такова - дали да ползва 'наточен' МЦУ, дали ФПГА, или комбинация -да интерпретира Г-кода на МЦУ и после да праща резултата към драйвер на ФПГА.
Поне аз така съм го разбрал, може и да греша.

чак пък FPGA, тоя G код е мислен за три, четири MHz процесори...
е бат Gogo е трошил Фануци, да каже