Пленочный фоторезист вообще то есть, а паять нужна паяльная станция, желательно с феном. Для особого кайфа еще и подогрев )

ага. понял. тоесть для изготовления платы стоимостью до 100уе мне нужно сделать/купить ИК паяльную станцию. ну и заодно метализация отверстий для домашних четырехслойных плат.
ибо озушка с тактовой выше 33мгц боюсь утюгом вы уже не сделаете. а если ниже то потеряете в производительности. зато сделаете плату.
обычная паяльная станция с феном у меня есть, фоторезист юзаю миновав стадию ЛУТ, дорожки 0.25 делаю без проблем. но вряд ли даже такое есть у большинства ЧПУшников.

кончно можно пофлудить - а вы в духовке... а вы феном... знаем проходили. человек без опыта это 100% брак.

поэтому я за минимизацию телодвижений/комплектухи в производстве внешнего контролера. тоесть на нем должен быть минимум. а все остальное в ПК.

Сплошные сомневающиеся. На чем основаны ваши сомнения? Дело же не в том, как сделана плата, а насколько грамотно спроектирована.
А больше, тех придуманных вами верхних мегагерц, и не надо, в данном случае.

Делайте плату. Хочу посмотреть результат.

ох ...
уже можно подводить итоги.
anatolvk почти исполнитель,аллигатор 75 ему наделает плат,(если в резоните религия не позволяет),
CNC_User-мотиватор,может и немного денег найдет.
найдите еще пару фанатов.
начните со степ-дир.
Oxford не мешайте им,я б с вами дел иметь не смог.

Далее формулирую последний вариант ТЗ на NC-плату (со всеми последними предложениями).


Пробежался по всему топику,
собрал более-менее полезную информацию по ТЗ.
(может чего и упустил, так поправьте)




Преамбула:

Сегодня, многие хоббисты, для управления станком используют
чисто программную систему управления + LPT-порт.

В основном есть три варианта - TurboCNC, MACH и EMC2

Под Windows работает только Mach
По этой причине он более ходовой у хоббистов.
Виду того, что Windows не является операционкой реального времени
накладываются очень жетские ограничения на настройки ОС и запуск других программ.
Иногда выскакивают сбои (это из-за того что Windows не RT-система (не Real-Time ОС)
Еще огромный минус - его нельзя запустить под Семеркой.
С этим сталкиваются все, кто активно использует MACH.


C EMC2 ситуация намного лучше.
Эта система работает намного стабильней MACH-а,
т.к. она использует операционку реального времени - RTAI.
Но периодически возникают непредолимые траблы при подборе аппаратуры,
и чем новее системы, тем чаще возникают эти траблы.


Есть еще TurboCNC,
он крайне стабильный, даже постабилней будет чем EMC2.
но он работает в текстором режиме, что не удобно и давно морально устарело.

Цель проекта:
Создание системы не критичной к RT-проблемам операционной системы Windows,
а также не критичной к RT-проблемам аппаратуры ПК.

Реалицация:
Создание полноценного NC-модуля, в котором крутится вся RT-математика
На ПК крутится только GUI и необходимая предварительная подготовка УП.

Функциональность:

Три одновременно интерполируемые оси (опция - плюсс три поворотные оси).
Точность 0,001 мм
Диапазон перемещений +/- 10 метров.
Поддержка стандартного G-кода (FANUC-совместимый формат)
Поддержка больших УП (по крайней мере, должен обрабатывать УП до 512 Мегабайт, а если получится можно и больше)
Поддержка управления STEP/DIR (либо CW/CCW).
Частота генерации шагов - до 2-ух МГц
Предпросмотр кадров (технология Look-ahead) глубиной не менее 50-100 кадров
В качестве GUI используется PC-компьютер.
Вся NC-математика делается во внешнем RT-контроллере.
Требования к компьютеру для GUI - надо сразу закладывать, мин. под "Семерку"
Интерфейс с GUI-компьютером - Ethernet (по TCP-протоколу).
несколько дополнительных цифровых входов/выходов которыми можно управлять из G-кода (берем пример с EMC2).
ШИМ выход управления скоростью шпинделя;
возможность подключение внешнего пульта управления непосредственно к RT-модулю;
Система защиты от сбоев электропитания.


Процессор RT-модуля:
Разрядность – 32.
Обязательно наличие блока FPU (float point модуль).
?Тип процессора – DSP, ARM или что то другое. Этот вопрос пока обсуждается.
?Частота процессора, думаю, мин 100 МГц.
? Возможен вариант на FPGA с поддержкой интегрируемого процессора NIOS II

? ПП – двухслойка (по возможности, - четырех-слойка)


Архитектура:


Пример данных обмена между GUI и NC-модулем:

Mx0000.000y0000.000z0000.000a0000.000s1200
Mx0100.000y0050.000z0010.000a0000.000s1200
Mx0200.000y0100.000z0060.000a0000.000s1200

где М это перемещение по осям x0200.000 y0100.000 z0060.000 a0000.000 , S1200 скорость перемещения.
команды подразумевают какие либо события - вкл/откл шпинделя, наезд на лимит и т.д.

контролер отрабатывает мгновенно любые команды "стоп" "пауза" "вознобновить" "очистка буфера" "скорость ХХ" "сработал лимит ..." "ошибка перемещения" "аварийная остановка" "нажата кнопка ..." "СОЖ несосает" "перегрев" "а тут хз что - хочу оператора"
буфер для данных может быть любым и работает по принципу фифо.

Другими словами, в NC-плату, мы передаем, теже данные, что и в исходном G-коде,
только в облегченном формате, чтобы не тратить ресурсы NC-платы
на вычленение координат каждой точки заданной в исходном G-коде.
Фактически в NC-плату передается тот-же G-код, но только в подготовленном виде,
для его скоростного анализа.

Под вопросом (Здесь не обязательная функциональность, и реализуемость этого зависит от необходимости и от требуемого уровня сложности)

модуль кинематика для создания непрерывной многоосевой обработки + RTCP;


Еще какие нюансы? Дополняйте.

По роду своей деятельности занимаюсь разработкой генераторов переменного тока сложной формы ~до 500Вт (витеевато но суть такая)
как ни странно основные задачи у меня схожи с контроллером чпу: жесткие требования к фазам и задержкам сигналов.

на мой взгляд задача должна быть разделена минимум на 2 части
1 общение с внешнем миром (+ интерпретация и буфферизация Г кода)
2 генерация управляющих сигналов.
отсюда удобным можно считать количество процессоров (или неких цифровых автоматов) ДВА!!! либо 2 ядра(автомата) на кристалле
это позволит как минимум облегчить разработку контролера.
доказательства? омапы C6 от Ti; iMOTION от IRF сферы примения у них общение с внешним миром и генерирование потоков сигналов для управления железякой в реальном масштабе времени
конечно каждый из этих контроллеров живет в своей нише но разделение задач явно.

п.1 подойдут 32разрядные (не ДСП) процессоры на которых можно запустить какую либо ОС
зачем ОС? по крайней мере в них уже реализованны протоколы, интерфесы и т.д. , что намного облегчает разработку

п.2 ДСП с заточенной под генерацию сигналов периферией или ФПГА,

такая связка в принципе подойдет и как аналог SmoothStepper - имхо задача минимум
и как самостоятельный контроллер чпу.

добавлю
имхо делать опенсорсовый проект.
минимальное требование к члену команды: 1 час в день.
платформа:
ARM9(linux, EMC2) + FPGA
практически готовая платформа для старта софтописательства. http://starterkit.ru/html/index.php?name=s...=view&id=50
хорошие возможности для дальнейшего расширения: контролеры сервы и т.д. внутри FPGA
думаю подобных связок ЕСТЬ, что внушает оптимизм

сейчас связыватся с разработкой схем, плат контролера не разумно. времени уйдет слишком много.
+проблемы надежности макетов.

такое оСЧущение что преамбула = моя вводная :)))

Возможно и такое!


Пришлось перелопатить кучу материала, в т.ч. и вашего,
так что ваши мысли тоже могут здесь проскакивать.

Когда перероешь тысячи страниц документации и разных сайтов,
и при том на разных языках (Rus, En)
то уже не помнишь, откуда взялась эта мысль!
И все генерируемые в мозгу мысли, кажутся уже своими родными!




PS/
Уважаемый Евгений, не сочтите за плагиат,
а только как за подтверждение ваших идей.

Какие мои идеи это мировое, а вот фразиологические обороты точно мои :)

Критика!


Не факт


А чего тока три ?


Крупновато


Это вообще задача компьютера, какие тут могт быть ограничения


В корне не верно если увас компьютер то он должен подсоввывать команды по мере выполнения и не грузить хуге файл!


В космос собрались ?


Круто!

А что делать тем кто восьмерку поставит ?
Не лучше ли сделать совместимым с тем же Мач и EMC


Почему


Почему


Это не вопрос ТЗ



Где тут принципиальная разница с G-Code
Где выигрыш в размере или скорости
Фигня полная копеечная операция для процессора передать G-CODE

3+3 получаем шесть интерполируемых осей.
Согласен, формулировка в ТЗ, однозначно не говорила о том, что поворотные оси тоже интерполируемые







Не вопрос.
Думаю повышение точности не влияет на расчеты, можно и повысить.







Этот момент аналогичен предыдущему.
Но ограничения (разумные) всеравно должны быть.





Так вроде и не писалось что вся УП должна загоняться в NC-плату.
Имелось ввиду весь комплекс - GUI + NC-плата должны поддерживть большие файлы.
И совсем без ограничений, думаю не получится, в том-же Маче есть ограничение (около 200 МБ).
Из практики попадалить УП и поболее чем 200 МБ, по этому и указал цифру 512 МБ,
а вообще, конечно, архитектура системы не должна накладывать ограничения на размер УП.





А вот как раз, в космосе такие частоты и не нужны
Там нужны не скорости, а сверх-надежность.
А вот нам как раз такие частоты нужны!

Для шаговика, даже в микрошаге, это не надо,
а вот для серваков с импульсным управлением,
Самое оно.
Например - частота оборотов - 3000 об/мин
Кол-во импульсов на оборот - 10000


Получаем частоту - 0,5 мгц

Если учесть, что большинство серваков допускают повышение оборотов до 5000
а дробление полного оборота на 10000 шагов, для серваков это не такая уж и редкость,
если не сказать наоборот, что это самые простые из серваков.
10000 - это для энкдера у которого до учетверения всего 2500 импульсов на оборот,
обычно такие ставят на самые дешевые сервоприводы.
Так, что цифра 2 МГц не такая уж и большая.

Конечно, если ограничиться только шаговикам, то эту цифру спокойно можно разделить на десять.
Да, в ТЗ, с этим вопросом надо определиться.







Круто - это предпросмотр на 1000 кадров (Фанук, Сименс)
А до ста кадров, это нормально, это минимум (для 3D-обработки).

Так одним машинным словом можно кодировать любое значение координаты,
что важно для быстродействия системы.
Да и сегодня 32-ух битники стоят уже копейки.










FPU - обязателен, по причине большого кол-ва динамических расчетов,
а это спошная плавающая математика.


А если переносить код EMC2, так там всё на базе флоат-поинта.



Вопрос не в передаче G-кода,
вопрос в его анализе и разложении кадра на координаты
а это уже не копеечная операция (об этом рассуждали выше).
А в предложенном варианте, сразу передаются уже пережеванные координаты,
готовые для настройки перемещений.
Формат этих данных пока не исключительно такой, и пока подлежит обсуждению.

чем проще программа в контроллере тем меньше глюков. сделайте хотя бы аналог NCStudio с ценой до 100уе. а запихивать в контролер все подряд ненужно - все что ему нужно это точно и надежно ездить с нашими параметрами.

Истина, мое мнение что нужно использовать Мач или EMC. Единственное что нужно так это сделать так чтобы контроллер сам частоту генерил. Боле ему ничего делать не надо. Это единственное слабое место современного компьютера не ориентированного на RT. Со всем остальным он справиться без проблем с огромным запасом.

Мы об этом говорили. Все равно пытаются сделать космический корабль.

MACH3 отпадает сразу, т.к. это закрытая система
там есть какой-то API, но этого недостаточно.
EMC2 в этом плане гораздо лучше,
если к нему что-то прицепить,
и возникнут какие-то нестыковки,
то можно спокойно посмотреть в код EMC
и разрбраться в чем проблема, с Мачем-же так не получится.


По сути, если использовать EMC в качестве PC-оболочки
то получится практически тоже самое решение,
о котором мы рассуждали выше.


Т.е. EMC2 по сути, будет использоваться в качестве нашего GUI.

Задача GUI (EMC2), в нашем случае сводится только к подготовке координат,
и передача их в RT-плату,
где собственно и осуществляются все RT-задачи,
а именно - интерполяция и генерация STEP-шагов.


Алгоритм интерполяции:


Так что здесь, вы правы, в том, что можно использовать готовый GUI,
но есть одно НО, может, в таком случае логичнее перекинуть
не RT-код из EMC в Windows, и не связываться с Linux-ом?
Для подавляющего большинства (для 99%) так будет намного удобнее.


PS/
Вроде вырисовывается красивая картинка

Такой проект уже есть.
http://planet-cnc.com/

Часть EMC запущена под виндой. Реалтайм сделан в железке.
Последняя версия железки может жить автономно.

Все что нужно для RT ввода-вывода там открыто.

Чел. прикрутил к Мачу плату (KFLOP+Kanalog + Мач) и получи RT http://www.chipmaker.ru/topic/41811/page__...post__p__935280

2 CNC user

признайтесь, зачем Вам это все нужно?
Стеб?

Судя по бессмысленному сочетанию терминов из чпушной терминологии, похоже на то.

Там, что-то непонятное.
Действительно интерфейс похож на EMC,
но вроде запускается на Винде.
Это скорее всего копия дизайна EMC, а не сам EMC
т.к. за лицензию на оболочку берут денег!
А раз берут за GUI деньги, значит, это точно не EMC.

Всё, да не всё

Тоже копал этот вопрос, и наткнулся на то,
что из Мача можно выдрать только текущее положение
уже после интерполяции и там нет данных по коррекции люфтов.
А для хоббистов это очень важный вопрос.
Многие наступали на эти грабли, в т.ч. и хваленный СмуфСтеппер.
Также, некоторые проблемы создает то, что интерполятор
находится не в RT-части, и возможны достаточно опасные ситуации,
когда нажимаем Аварийный стоп, то плата должна отработать 0,5-2 сек
чтобы скинуть, то, что в неё уже передано, и только потом она приступит
к остановке.
Это как езда на автомобиле с неисправными тормозами -
Ездит себе, да и ездит, ну да, немного дискомфортно, но она же ездит!


Вообщем-то после обнаружения этой информации,
в сторону Мача больше не копал.


А вот в EMC, этих проблем как раз-то и нет!

А какая стоимость этой платы KFLOP+Kanalog?

Цитата:
посчитал скока за все про все с терминалками и кабелями и в это же
время подвернулся Кфлоп. Цена взяла верх. Позже докупил Каналог. Скажу
больше.. Практически любую плату, продаваемую на том же ибее, которая
называется Motion controller и имеющую бортовую схему PLC и фирменный софт для
настройки, можно без проблем прикрутить к Мачу, подавая от LPT пакеты шагов на
PLC, которую программируем для перенаправления шагов на сервы, а фирменным
софтом в свою очередь конфигурируем лишь настройку самих серв. Метод не очень,
т.к. не раскрываются все возможности Моушин Контроллера, но вполне
работоспособный и тоже можно использовать как вариант, если очень хочется
сэкономить деньжат и управлять при этом комплектом сервоприводов. В любом
случае работа аналоговой сервы будет гораздо лучше, чем управляемой по степ/
дир.

Вот это http://planet-cnc.com/ меня заинтересовало, цена небольшая и возможностей куча. Ктонить тестировал ее? Может в инете есть отзывы?

Напиши в личку юзеру Moonglow. У него есть обе версии плат.

Ага нашел всю инфу по этому девайсу, люди собирают сами даже платы, все пишут здравая тема.

Просмотрел кучу информации по ARM-ам.

Так вот, оказывается, что есть отдельные серии для производительных задач (серия "A")
а есть отдельная серия для решения наших RT-задач! (серия "R")
И несмотря на то, что у серии "A" производительность гораздо выше чем у процессоров RT-серии,
но всеравно серия "A" непригодна для решения Реал-Таймовых задач!!!

До этого, думал, что таким страдает только архитектура IBM-PC,
Там действительно, чем новее компьютеры и чем выше их производительность,
тем больше создается проблем для RT-задач (в нашем случае, тем больше сбоев в генерации STEP/DIR-сигналов).

Но теперь, очевидно, что такие же проблемы есть и у контроллерных архитектур,
только в случае с ARM-ами, эти проблемы (вернее - особенности) декларируются производителем,
что позволяет сделать правильный выбор, еще на этапе проектирования системы.

Ниже приведен график с сайта компании ARM
На котором видно, что самые производительные чипы (серия A) непригодны для
применения во встраиваемых (embedded) приложениях:



Из графика видно, для для наших задач, можно использовать только чипы серии "M", и серии "R".

Зайдите по ссылке, на сайт компании ARM - http://arm.com/products/processors/index.php
Там найдете много полезной информации.

я думаю что пока что разговор о ниочем. потому как нет даже математики и примерного алгоритма чтобы оценить хотя бы примерно затраченые ресурсы для арм/авр/дсп.
это тыканье пальцем в яйцо - "Чье яйцо круче, правое или левое".

как то в начале темы считал для простейшего контролера.
если делать контролер чисто для степ/дир без обратной связи со следующими условиями
оборотов двигаетля до 15об/сек
микрошаг до 1/8
4 канала управления двигателями.
контролер не заниается расчетом а-неад да и вообще. (расчет только на текущий участок траектории)

то на данные условия вполне хватает платформы LPC или ATXMEGA.
если задачу упростить до 1/2 шага или полный шаг то хватит и AVR (собственно даже есть готовые реализованые проэкты).

для сервы увы я далек до алгоритмов. поэтому чтобы не разводить демагогию то варианты -
а) выбрать чип по подобию тех которые уже используются
б) накатать алгоритм на заведомо быстрый чип и посмотреть что можно упростить/удешевить или оставить как есть.

брать плату у которой все и вся на борту "типа а может пригодится" можно только на этапе оценки. в дальнейшем все должно уместится в 3-4 чипа (проц/плм/драм) для того чтобы каждый желающий мог повторить конструкцию.

Все как всегда - слышал звон, а откуда он...

Это не А серия непригодна для RT задач, это просто другие не имеют обязательного (для оси общего применения) модуля разграничения памяти. Он нужен в первую очередь для того чтобы была возможность изолировать задачу в рамках отведенных ей ресурсов железа (диапазона адресов памяти) и не допущать безобразий безопасности. Посему ядра с этим самым MMU позиционируются для осей общего применения а все остальные - для встраиваемых применений с добавкой волшебного (но ни к чему не обязывающего) слова real time.

ненадо генерировать программно сигналы степ дир ни на каком процессоре.
процессор должен сказать железяке в какое время нужно что сделать.
должен быть аппаратный таймер (идеально если он будет внутри кристалла), шим узел и пр.

для задач реального времени критичных к джитеру таких как вывод звука, видео ВСЕГДА используется аппаратная поддержка иначе получается какашка.
какашка иногда работает и даже красиво работает но всегда вылазят глюки.
что стоит для для современного писюка в винде программно выводить звук с частотой дискретизации 96кГц? думаю ничего, индикатор загрузки ЦП наверно даже не заметит разницы
но звука нормального не будет.
Чтобы было нормально используют буфера, дма каналы и пр. аппаратные решения.

Когда писал пост подумал что можно сделать 3 канала степ/дир с хорошей буферизацией на 6 канальной аудиокарточке (сейчас они почти все такие)
достаточно бюджетно и джиттер будет раз в 100 ниже чем на лпт порту
из минусов управление вслепую.

В качестве занудства: джиттер в данном случае может быть даже полезен - в рамках борьбы с резонансом шаговиков.

лучше с ним бороться микрошагом.
а внешняя усб звуковая карточка имхо годное решение.
оно работает даже на самых "тупых" ноутах. 3 оси для абсолютного большинства хоббистов начального уровня достаточно.

Дожили.
может давайте сразу управление ШД реализуем на звуковухе?
а чо
по сути - шаг это смещеный меандр.
микрошаг выглядит как ступенчатая синусоида на обмотках ШД.

только наверно ничерта неполучится. в звуковухе есть переходные емкостя которые недадут работать на низких скоростях или около нулевых. это если бы выход звуковухи был по постоянному напряжению то ради спорта можно бы было реализовать.

только кто такое воспримет всерьез?

кстати идея с времеными метками для подачи импульсов степ/дир здравая. даже очень.
в начале я думал что каждой осью управляется собсвтенным таймером времени. из достоинств - простота апаратного решения.
если давать метку времени то требуется проц пошустрее (с учетом стоимости можно не обращать внимание). но зато большой + то что диапазон изменения скорости практически неограничен в рамках задачи.
это мы говорим о степ/дир.

да и вообще пора бы ветку разделить на две. контролер для сервы. контролер для степ/дир.

это решается закорачиванием разделительных емкостей на выходе звуковушки.
но думаю микрошаг на звуковухе стоит делать разве что на самых малых мощностях.

Я тут недавно приобрел то, о чем автор топика размышляет.
Начинаю изучение, тестирование и эксплуатацию.
В данном случае работает под XP, при этом я c этого же компа общаюсь с Вами коллеги в Интернете.
Также на нем запущена терминалка на которую выводятся параметры сервы. Кстати не только выводятся, но могут и изменятся во время выполнения управляющей программы приводом.
Думаю, чтобы еще до кучи запустить на этом компе.
Пожалуй запущу еще 3DMax, может тогда все рухнет.

Вот такой вот реал-тайм.

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла


Да, к чему я это все, чуть не забыл.
Все работает, можно приступать делать контроллер.

пардон. на внешней усб карточке не получится, там если не изменяет память изохронный протокол
быстрый но с негарантированной доставкой
но внутренние карточки вполне работоспособны.

А с шаговиками как себя ведет?

Сервы не показатель,
они спокойно вытягивают все RT-проблемы с джиттерами, латентностями и т.п.
На то они и сервы .

Если будете гонять реальные 3D-файлы на шаговиках,
не забудьте сообщить о результатах.
Очень интересно.

Ну и....?

что и?
"Мопед не мой, я просто выбирал процессор"

Всем добрый день!
Лето, август, отпуска - и как результат тема немного застопорилась.

Много думал над вопросом, правильного процессора для RT-платы.

Много перелопатил материала.

И начал склоняться к мысли, что сам контроллер, имеет далеко-далеко второстепенное значение,
а вся сложность проекта упирается исключительно в софт, а хардварная часть - это мелочи.
По сути, корректно написанный софт, практически не зависит от выбранного контроллера,
и если софт запустить и отладить под один контроллер, то не составит особого труда
перенести его на другой контроллер.


Поэтому, может действительно, пора уже остановиться с выбором контроллера,
и взять готовую плату с чипом поддерживающим float-point, и двигаться дальше.


Почему флоат-поинт?
Да потому что нормальные траекторные расчеты, это сплошная плавучка.
В том же EMC2 практически все траекторные расчеты во флоат-поинте.


Думаю, сейчас стоит перевести ветку в немного другую плоскость -
"выбор КИТ-а для запуска и отработки программных алгоритмов RT-платы"

Плату надо брать с гарантированным запасом по производительности.
Потому, что, реально требуемую производительность
можно определить исключительно после запуска проекта,
и никакие умозаключения здесь не помогут, нужна только практика.



А уже после запуска проекта, можно соптимизировать аппартную часть, и выбрать
процессор с производительностью достаточной для наших задач.


И огромная просьба, пожалуйста не засоряйте тему сообщениями типа - "EMC2 уже запущен на PC, что вам еще нужно?"
т.к. об этом уже необнократно писалось и обсуждалось.
А если, сильно уж хочется обсудить этот вопрос, то открывайте отдельные ветки.
А вот по поводу кода EMC2, его конечно можно (и нужно) использовать в нашем проекте!


Моё предложение по киту:

Обязательно:

* частота не менее 400 МГц
* наличие FPU-модуля

Желательно:

* Ethernet (для тестового варианта пойдет и USB, а в конечном рабочем варианте, конечно уже нужен будет только Ethernet)

Под заявленные требования вполне подходит FriendlyARM Mini6410




PS/

почему такая большая частота?
За основу был взят FriendlyARM Mini2440 (см. здесь - http://www.cnczone.ru/forums/index.php?showtopic=1727)
даже при частоте 400МГц у него все равно были проблемы.
Конечно, там проблемы были из-за отсутсвия портирования RTAI под ARM,
но думаю, лучше перестраховаться и за основу,
взять частоту не менее, чем в этой попытке переноса кода,
и как говорилось выше, затем если получится, то урежем её.


А по поводу float-поинта писал выше.

Что-то тема совсем застопорилась

Каникулы что ли окончились?

Или еще чего?

Движухи нет. Одни лозунги Создавайте новую тему - "алгоритмы для CNC"

вот случайно наткнулся - CNC контроллер на AVR, может кому интересно будет.
вообще, если хорошо поискать, то обнаружится уйма начатых проектов по этой теме.

Обнаружил там, в документации, интересную картинку:

  _____________________
  /|     | __________ ^
 / | | /| | |
  / | | / | |   s
 / | | | | | p
/ | | | | | e
+-----+------------------------+--+-+-----------+--+ e
| BLOCK 1 | BLOCK 2 | d

time ----->

(при сохранении, у меня картинка почему-то исказилась :( )

Другими словами, там не реализован предпросмотр,
а есть только примитивная проверка угла на стыке двух кадров.

Такое прокатит только для простейшего применения.


Немного пробежался по проекту.
Это похоже на другие примитивные проекты, которые обычно делаются как дипломные проекты, а затем просто кидаются и всё.

Там даже G-код из 100 строк считается уже большим файлом
см. здесь - https://github.com/simen/grbl/issues/36

Также, пока есть проблемы с паразитными задержками (см. https://github.com/simen/grbl/issues/21)

Думаю, это всё результат попытки решать задачи движения, на простейших контроллерах
в данном случае на AVR-ке, и это самые первые грабли, на которые наступаю все
начинающие писать код для управления движением.

Никакой практической пользы, скорее всего данный проект не имеет,
а вот для программистов будет полезен, т.к. там предоставлен исходный код прошивки.
может чего-то подчерпнут для нашего проекта.

Как вы думаете, имеет-ли EMC2 это ваш lookahead? И на сколько кадров вперед?