LinuxCNC + Orange Pi (allwincnc)

[Serg]

Интересно, чтобы мы сейчас обсуждали, если б никто не написал Linux и не придумал LCNC..

Не путай интересное занятие по созданию чего-то нового и изготовление копии непонятно для чего.
Я например не раз говорил, что не берусь за ЧПУ проекты ради зарабатывания денег, а берусь только за интересные мне проекты, и нередко практически бесплатно.

144 ноги не раскидать по 2 слоям, вроде 144, но GPIO у 7I90HD "всего" 72шт ? это ж плисина, переназначай ноги в проекте и всё. китайцы свои доски на е2р5 не на 4 слоях делают, оно ж иначе в ценник не влезет.

Это какой-нибудь светодиодноморгальный ногодрыг так можно разводить, а в месах частоты 5-10МГц - там уже длины проодников начинают влиять и их взаимное пасположение.
Я вот смотрю на 7i92 и вижу. что она 4-х слойная, наверно потому, что её не китайцы разводили...

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

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

А уж от этого хост_а каждый сам может в меру своей испорченности сделать

Меса - конструктор. из компонентов которого собирается нужная конфигурация только отвёрткой, без паялников и травления плат. Возьмём к примеру этот форум - тут десятки станков на Меса и подавляющее большинство их создателей почему-то решили купить совсем недешёвые 7i76/7i77 вместо того, чтобы взять в руки паяльник и спаять то, что каждый сам хочет...

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

Большинство конечных потребителей не будет с этим заморачиваться и предпочтёт что-то готовое, где паять не надо. И никому не нужный проект потихоньку угаснет на задворках форумов.
Кстати, понится ТС задумал этот проект, как конструктор из готовых модулей...

[MX_Master]

Не путай интересное занятие по созданию чего-то нового и изготовление копии непонятно для чего.
Я например не раз говорил, что не берусь за ЧПУ проекты ради зарабатывания денег, а берусь только за интересные мне проекты, и нередко практически бесплатно.

С этим я полностью согласен. За копирование плат МЕСы я бы тоже не взялся. Они уже есть и сделаны отлично.

Кстати, понится ТС задумал этот проект, как конструктор из готовых модулей...

Так и есть. Будем придерживаться этого плана и дальше.

--- --- ---
Сборка ядра с RT патчем немного затянулась. Причём, еще на ранней стадии. Нахожусь за городом, в наличии только медленный мобильный интернет. А для сборки надо вытянуть из сети кучу доп. пакетов. Вощем, ползёт всё потихоньку К выходным может и соберётся. Очень интересно будет сравнить тайминги с обычным ядром..

[arkhnchul]

на всякий случай - не обижайтесь, если выскажу уже известное и кажущуееся от этого очевидным положение:

With software step generation, the maximum step rate is one step per two BASE_PERIOD

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

[MX_Master]

Скоро мы до этого BASE_PERIOD доберёмся. Но кроме него есть еще и DMA копирование в регистр порта, которое может повлиять на итоговый результат.

[arkhnchul]

а как?
понятно про шим с нужным порядком битов, но сие для меня из разряда любопытных кунштюков - так-то покрутить шаговик можно хоть светодиодами на клавиатуре (срсли, особые извращенцы так и по spi цеплялись - трех сигналов с num/caps/scroll хватает на mosi/miso/медленный_и_печальный_clk). Как оно увязать со скоординированным движением и ускорениями? Пока как я это видю - либо упираемся в BASE_PERIOD, которого едва хватает на ногодрыг LPT, либо, при собственноручной отвязанной от него генерации шагов, в необходимость обратной связи "мы уже прошагали вот столько".

[sidor094]

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

Драйвера для ARM?

[sidor094]

Для интерполятора нужно,чтобы он вызывался строго через определенные промежутки времени.Желательно как можно с более высокой частотой.От неё зависит максимально возможная скорость выдачи шагов.Далее в нем в результате расчетов формируются ,или не формируется шаг по каждой координате.Здесь DMA никак не поможет.Только прерывания таймера.Кроме того желательно иметь вход энкодера(которого нет)или,в крайнем случае таймера для нарезания резьбы.Иначе нужно программно считывать энкодер.Я не уверен,что многозадачная система может нормально с этим справиться.Но Шим здесь вроде есть.Если посчитать,нужно 10 выходов для 5 координатного стап.дир и
5 входов для нулей.Т.е 15 портов для координат.Один выход для ШИМ шпинделя,1(или 2) входа для энкодера шпинделя,2 порта для 485 а лучше 4 для двух(чтобы можно было расширить число портов и других возможностей) .Т.е минимально нужно 22 порта.Здесь 27.Вроде со скрипом хватает(даже небольшой запас).

[MX_Master]

Как оно увязать со скоординированным движением и ускорениями?

Т.к. мы разбираем G код заранее до вывода, то всю синхронизацию и ускорения можно закладывать прямо в байтовый массив для записи в порт. После этого надо писать байты из массива в порт с одинаковой частотой, не задумываясь ни об ускорениях, ни о синхре осей. Переносить байты можно как программно, так и аппаратно (DMA). Какой способ будет удобнее и стабильнее, тем и будем пользоваться. С этим уже все понятно.

Но меня волнует другое. Надо будет накатать нереально быстрый парсер G кода в вышеуказанный байт код. Под это дело можно будет выделить отдельное ядро проца, как и для генератора. А всё остальное будет робить на оставшихся двух ядрах.

Кроме того желательно иметь вход энкодера(которого нет)или,в крайнем случае таймера для нарезания резьбы.Иначе нужно программно считывать энкодер.Я не уверен,что многозадачная система может нормально с этим справиться.Но Шим здесь вроде есть.Если посчитать,нужно 10 выходов для 5 координатного стап.дир и
5 входов для нулей.Т.е 15 портов для координат.Один выход для ШИМ шпинделя,1(или 2) входа для энкодера шпинделя,2 порта для 485 а лучше 4 для двух(чтобы можно было расширить число портов и других возможностей) .Т.е минимально нужно 22 порта.Здесь 27.Вроде со скрипом хватает(даже небольшой запас).

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

[sidor094]

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

Не очень понятно.
1)Какой тогда должен быть размер массива?Если длина например метр,а точность микрон .По одной координате тогда длина массива равна миллиону байт.По пяти соответственно.
2)Сколько времени вы затратите на подготовку и запись пяти таких массивов?Даже с участием ДМА.

[Сергей Саныч]

Это какой-нибудь светодиодноморгальный ногодрыг так можно разводить, а в месах частоты 5-10МГц - там уже длины проодников начинают влиять и их взаимное пасположение.

Вот поэтому я достаточно скептически отношусь к перспективе создать реально работающую СЧПУ на базе китайских "кубиков".
"В принципе", конечно, она работать сможет, но станет ли работать "в кожухе", как говорил Сергей Павлович

[Сергей Саныч]

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

я так понял, что это сделано с целью снизить требования к реалтайму. Такие огромные массивы не требуются. Достаточно готовить в расчете на один сервоцикл, скажем, на 1 мсек. Тогда, если принять максимальную частоту импульсов шага 200 кГц, то это 400 бит на Step и столько же (для простоты) на Dir. Итого скромных 100 байт на канал. Сгенерить столько, при разумном кодировании на МК с тактовой частотой десятки МГц, думаю, не проблема.

[sidor094]

Тогда получается,что каждые 5 мксек надо готовить около 4 килобайт массива,и при этом даже имея 2 набора массивов для переключения или заполнения, или один кольцевой ,надо еще следить за состоянием текущего массива для своевременного заполнения нового.Не уверен ,что это лучше ,чем отдельная подготовка и выполнение каждого шага.У меня на процессоре с тактовой 120 мгц получается около 80-90 мгц шагов по пяти координатам.При этом еще параллельно рисуется экран 640ч480.

[Сергей Саныч]

каждые 5 мксек надо готовить около 4 килобайт массива

мсек, не мксек.

получается около 80-90 мгц шагов

кГц, наверно, все-таки
Нагенерить можно, с запасом. Вопрос в том, можно ли их стабильно выдать при работе с ОС. При использовании DMA как раз и решается вопрос стабильной выдачи.

[MX_Master]

sidor094, 1 байт это синхронизированное состояние 8-ми пинов в текущий момент времени. Половина пинов - это DIR. 1 синхронный шаг всех 4-х осей занимает минимум 2 байта. Если 1 мм у нас это 1000 шагов, то 1 мм - это 2000 байт. А 1 метр - это 2000000 байт, т.е. чуть меньше 2 Мб, а при 512 Мб ОЗУ этот объем практически незаметен. Заполнять массив получается со скоростью примерно 1 МГц, а это 1000000 байт/с. Это означает, что максимальная подача при такой настройке будет пол метра в сек или 30000 мм/мин. Вряд ли кто-то такое будет выжимать.

Так что замысел имеет право на жись.

[sidor094]

Заполнять массив получается со скоростью примерно 1 МГц, а это 1000000 байт/с. Это означает, что максимальная подача при такой настройке будет пол метра в сек или 30000 мм/мин. Вряд ли кто-то такое будет выжимать.

Заполнить пол дела .А подготовить?Согласен каждый байт может содержать информацию о пяти координатах.Но подготовка и объединение в один байт -это не так быстро .

[MX_Master]

1 байт это step/dir для 4х осей. И я выше уже писал, что нужно будет создать реально быстрый парсер G кода. Без разбора не одно ЧПУ не работает.

[sidor094]

Для подготовки надо выполнить те же действия,которые вы выполняете без подготовки ,а при расчете каждого шага.Экономия времени только за счет того,что вам не надо входить и выходить в прерывание или подпрограмму при каждом шаге.Но если там это происходит при каждом шаге и время,соответственно затрачивантся только на расчет одного шага,то при подготовке вам надо рассчитать сразу все шаги при подготовке каждой команды,что может привести к слишком большим паузам между командами.
Что выбрать быстрое движение с паузами между командами,или более медленное,но без пауз?Единственное,что можно сделать это рассчитывать следующую команду во время движения нынешней,и сделать два переключающихся массива.Тут может быть только проблема с короткими командами,но это проблема присутствует всегда т.к. надо разобрать код перед движением.Но я думаю,что при 120 мгц процессоре 80 кгц даст при 1.2 ггц процессоре прирост достаточный ,чтобы получить около 300кгц.Я не множу на 10 т.к наверное будут потери за счет операционки.

[MX_Master]

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

Т.к. ОЗУ позволяет, я планирую только 1 длинный круговой массив. Заполнять, да, по ходу вывода. Желательно, перед стартом УП рассчитать кое-что на будущее, чтобы в процессе пыхтелось поменьше (:

[Serg]

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

Интерпретатор G-кода? Этой задаче вообще RT не нужен, например в LinuxCNC он полностью отрабатывает на этапе загрузки файла с УП.

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

Зачем? Он может сразу всё расчитать и результат положить в некий буфер, из которого в каждый сервоцикл будет передаваться генераторам данные по перемещениям, которые нужно сделать в очередном сервоцикле. Именно тут только и начинается RT. Вот хорошая картинка, поглядывайте на неё: http://linuxcnc.org/docs/devel/html/cod ... e_overview

При использовании DMA как раз и решается вопрос стабильной выдачи.

Увы, при использовании DMA решается вопрос скорости выдачи, но никак не стабильности - DMA перекачивает данные из RAM в GPIO, но засада в том, что RAM он не может занимать эксклюзивно, ибо на работу с ней хватает желающих (CPU, GPU, etc.), и если система не RT, то нет никаких гарантий, что к нужному моменту ресурс окажется свободным.

1 байт это step/dir для 4х осей. И я выше уже писал, что нужно будет создать реально быстрый парсер G кода. Без разбора не одно ЧПУ не работает.

G-код незачем "парсить" с точностью до каждого шага (микрона), на его выходе (точнее на выходе планировщика) достаточно получать команды/данные типа "сделать в ту сторону N шагов со скоростью S", а превратить такое задание в массив состояний пинов сможет сам генератор.

P.S. IMHO тут не стоит "изобретать велосипед" - супротив тысяч изобретателей/конструкторов/разработчиков с их десятками лет работы по этой теме и миллионами финансирования у вас нет никаких шансов. Лучше воспользоваться отработанной концепцией построения таких систем, которой пользуются все именитые производители.

[Сергей Саныч]

Увы, при использовании DMA решается вопрос скорости выдачи, но никак не стабильности - DMA перекачивает данные из RAM в GPIO, но засада в том, что RAM он не может занимать эксклюзивно, ибо на работу с ней хватает желающих (CPU, GPU, etc.), и если система не RT, то нет никаких гарантий, что к нужному моменту ресурс окажется свободным.

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