Давай смотреть правде в глаза. Из тех 99% народа, о которых ты говоришь, 75% вообще не знает для чего им нужен станок и вообще никакого станка нет или есть такой, на котором максимум что художественная гравировка по пластилину получается, другим 20% станок нужен для сверления печатных плат. Думаю что такие товарищи, не ориентир.
Ничего удивительного. Большенство ПО по формированию g-кода вобще умалчивают, что есть такие штуки как G02,G03. И хоть ты трижды идеальный круг нарисуй, всё-равно по умолчанию в полученном g-коде этих комманд не обнаружить (если только намерянно не ткнуть носом ПО, что бы использовало круговую). А конкурентоспособные коммерческие разработки (типа CNC-USB, DeskCNC board) так же от рождения не признают круговую интерполяцию. Не скажу, что им с ихней колокольни виднее.. ладно, ты несомненно прав. В любом случае, в жизни всё бываить, и никогда не знаешь на перёд, что пригодится, а что нет.
Когда нет разгона с торможением, его хочется, когда он есть - хочется lookahead
Да, но опять же, lookahead в любом случае делается на стороне компа, и к контроллеру никакого отношения не имеет. Мя ж изначально не делаить просто прямую трансляцию строк G-кода в контроллер... с траектории можно вертеть как захочется, перед тем, как отправить на выполнение в порт.
То, что инструмент должен двигаться с определенной скоростью, в G-коде задается после литеры F (Feedrate).
Есть такое. В проге и параметр такой в настройках есть (типа, брать скорость из файла, или игнорировать и работать от установленных скоростей в настройках самой управляющей проги). Пока не докрутил (оставил на потом, просто настройка неактивна), но и мне понятно было изначально, что вещь нужная.
Управляющая программа обрабатывается в РС, в результате генерится траектория приводов во времени, она разбивается на линейные участки и информация об этих линейных участках передается в контроллер. Контроллер должен иметь некий буффер этих кусочков, чтобы не задерживаясь переходить к выполнению следующего. "Кусочки" могут иметь предложенный тобой формат.
Если могут иметь предложенный мной формат и при этом приходят линейные данные на перемещение, то чем это вобще отличается от того, что предложил мя в первом посте? Ню, если не брать в расчёт буфер, а то, что траектории обрабатываются на ПК по каким-то своим произвольным алгоритмам мы и так знаем. Вроде то же самое и получается.. просто линейные траектории со скоростью...
Про буфер. Прощитай задержки. Не актуально. Лучше память поберечь (и так в ОЗУ цифры километровые прокручиваются). Допустим, у нас 1000 строк g-кода. Пакет = 40 байт. На 115кБит\с это ~3мс. Пусть время реакции компа на подтверждение контроллера = 1мс (ничего нереального, стоит рассчитывать на гораздо меньшее время). И того, ~4мс паузы между каждым линейным кусочком траектории. Примерно 4сек. задержек на весь может быть многочасовой файл обработки. Много ли это? А 4мс паузу заметит ли кто-нить между командами? Мы ж всё-равно не избавимся от этих 4сек., т.к. в случае буферизации мы просто запихаем сколько-то там строк, потратив, скажем, половину от 4сек. сразу (и так, допустим, дважды за полный цикл работы станка), а без буфера мы просто размажем эти 4сек. равномерно по всему циклу.
Кстати, а как насчет USB? Будет контроллер работать через переходник USB-COM?
Проверено - работает. Вобщем-то, USB и был целью. Но зашить его в тот же МК пока руки-крюки, а положить на плату конвертер типа FTxxx - дорого. Вот и взял за основу RS-232 (причём, для удешевления - именно на бросовых транзисторах, а не на MAX). А там уже хоть в COM втыкай, хоть через любой USB-COM конвертер.
Кстати да, разумеется думал над тем, что в контроллере можно реализовать какой-нить уже используемый последовательный протокол. Но тот же DeskCNC хранит тайну протокола под страхом смерти
MaxStepper от KCam слишком мутный и запутанный сам по себе. Вот нашёл приличный и простой протакол, с уже написанным ПО - cncdudez.. вшил бы его для опытов, но там контроллер на USB, и родное ПО общается с ним через хид-устройство, а не через RS.. т.е. никак не заюзать.
