Вышел NoRT CNC Control 0.4

Окей. Тогда так. Управляющее ПО переводит программу в формат, в котором уже просчитанны все ускорения и т. д., а уже её вот заливает на устройство. После чего оно работает автономно.

В чистом виде смысла не очень много, т.к. прежде чем фрезеровать, надо подогнать шпиндель на начальную позицию, определить длину инструмента итд. Т.е. интерактивный ввод команд.

Как дополнительная опция - можно попробовать сделать. Только для этого надо будет еще прикрутить sd карточку к девборде. Напаивать flash чип не хочется, т.к. у него ограниченный ресурс, а записываться будет каждый раз

Если я правильно понял то rt-часть непереносима? Не думали сделать абстракцию например для того же FreeRTOS?

Переносима. Для переноса нужно лишь реализовать определенный набор аппаратно зависимых функций - работу с gpio, uart и таймерами. Вся логика аппаратно независима

хм, наверное не заметил. А есть где нибудь описание «определенного набора зависимых фукнций» или примеры. Пока нашел только то что в папочке arch, но там все как то сильно размыто.

Аппаратно зависимый код здесь

https://github.com/vladtcvs/cnccontrol_rt/blob/master/arch/stm32f103/stm32f103.c

`config_steppers` - работа с шаговиками

`hardware_setup` - инициализация остального

Не кажется, или общаться с каждым микроконтроллером через ethernet (кстати, наверно имеется ввиду еще и tcp/udp/ip, а не чистый ethernet) это слишком сложно?

Есть такая очень красивая штука, как EtherCAT. Имеются свободные реализации сервера, а клиенты — микросхемки за десяток баксов, с выходом на SPI.

По 100-мегабитной сети можно опрашивать 100 сервоосей с частотой 10 кГц. Не слабо, да? Очень советую провентилировать эту тему, если интересно.

спасибо!

Хм, интересно, посмотрю. Спасибо)

А может просто чистым ethernet попробую воспользоваться

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

было бы круто! На мой взгляд очень важно описать, что требуется аппаратно независимой части. Наверное какие нибудь таймеры, работа с gpio и так далее. По коду не очень понятно. :(

таймеры, UART и gpio.

Может вынести в заголовочный файл? Было бы понятно как использовать. Ну и архитектура может быть прояснилась бы (чувстувую, что uart нужет для интерпретатора, но вот почему интерпретатор в аппаратно зависимой части, не могу придумать:) )

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

предпочитают для включения/выключения света физический выключатель на стене

4.2
с 2014 использую автоматические выключатели (счетчик вошедших/вышедших + датчик движения + датчик освещенности)
на простую кнопку смотрю как на недоразумение

Интерпретатор не зависит от аппаратуры, но аппаратно независимый код интерпретатора вызывается из обработчиков событий uart

вот я как раз об этом. Как у Вас реализуется консистентность команды, ну или атомарность. по идее, нужен некоторый планировщик, который будет формировать команду для интерпретатора, а он, в свою очередь, игнорируя символы просто будет вызывать, что то типа readline().

Или у Вас вариант, getchar(). Когда по сути дела добавляется символ с буфер интерпретатора, и он анализирует можно ли передавать (обрабатывать) команду.

когда приходит символ он помещается в буфер. Когда приходит '\n', вызывается интерпретатор на том, что пришло и буфер очищается.

Аппратно зависим тут только непосредственно прием символа

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

Начали они с того, что доделали UHU до киловатта. Потом начали менять ему логику, потом топологию. В итоге от ухи ничего не осталось, а на свет появился привод для щеточных моторов до 2 квт. Потом ему добавили сигнал перегрузки. А потом can с отправкой данных по проскальзыванию, токах,температуры и положения энкодеров на валу. Степ/диры оставели. Сервацикл 1мс.

Также у них есть асинхронный генератор степдиров на кане или лане, с драйвером для linuxcnc а-ля mes, но он пока не работает. Вот скидываю им этот проект как пример. Но им нужно больше осей и быстрый цикл.

Это дремучие металообработчики. Сайта у них не будет, если я не сделаю.

В ethernet забыли collision resolver(не detectiin) завезти. Для реалтайма он не подходит. Поэтому во всех критичных областях can

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

Ну собственно про это я и говорю. Что надо предобработку g-code проводить прежде чем двигаться

Умоляю, сделай ещё и can. Или хотябы задел под него, чтобы я потом сделал. Просто привода с телеметрией по can'у и интерфейсом stepdir разработали тут мои друзья и я уде почти уговорил их открыть. Вместе с твоим поделием это будет открытый стек и для взрослых станков, чего так не хватает.

Там, павда, нужно больше осей. И вагон всякого нереалтаймного типа СОЖ, смена инструмента и пр.
И получится LinuxCNC.
При этом надо учесть, что как я ранее понял обратной связи по координатам в NoRT CNC Control нет, так как всё движение рпссчитвается заранее, а потом просто отправляется в буфер.
Это в принципе единственное с моей точки зрения достоинство этого ЧПУ, так как позволяет обойти создаваемые сервопериодом ограничение скорости движения по криволинейным участкам разбитых на кучу мелких сегментов(сервопериод).
Это по идее должно позволять улучшать скорость обработки сложных 2D кривых и 3D поверхностей на станках без обратной связи по координатам.
И всё.

А части того, что тебе хочется для NoRT ЧПУ не имеет смысла просто потому что там сервопериода нет и если он появится то у него не будет перед другими ЧПУ преимуществ.

Проект ЧПУ NoRT распыляет ресурсы с разработки на два проекта вместо одного и по этому я этот проект осуждаю.
Лучше бы он с соответствующим функционалом модуль для LinuxCNC разработал.

Ну у меня нет энкодеров на шаговиках. Будут энкодеры, тогда добавлю обратную связь

Linuxcnc по своей архитектуре подразумевает держать все на одной системе. И предварительный обсчет и дерганье шаговиков. Что требует rt ядра. И у них на форуме прямо написано, что это их принципиальная позиция. Мне она не нравится

Как ты обратную связь добавишь если она взаимосключающая с главной идеей и достоинством твоего ЧПУ?

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

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

Совершенно не вижу, как она противоречит. Вот пришло в микроконтроллер указание сдвинуться на полметра по оси x с такой то скоростью. Он и поехал, параллельно считая импульсы от энкодера. И если увидит расхождение между фактическим положением и тем, которое надо, докинет шагов.

Тем не менее, существенная часть rt остается на компьютере

У меня же весь rt в микроконтроллере

У тебя как я помню идея в том, чтобы заранее предрасчитывать массив бинарных сигналов step/dir и не RT, асинхронно посылать их блоками в буфер контролёра который будет их выдавать уже по реалтайму с некоторой частотой.

Это действительно позволит тебе двигаться быстрее, чем может двинуться LinuxCNC, но даже если ты сделаешь контроль координат то
1. RT связи с контролёром у тебя нет и по этому увязать координаты с конкретным выдаваемым контролёром шагом ты не можешь
2. Когда контроль координат себя оправдает и покажет отклонение, то он весь твой предрасчитанный массив сигналов step-dir должен перерасчитываться заново, а станок в это время видимо резко остановится.

3. Основная причина медленности LinuxCNC состоит в том, что для прохождения кривой с некоторой точностью её надо разбить не менее чем на k линейных сегментов и за один сервопериод можно пройти только один сегмент.

И как только ты введёшь контроль координат у тебя будет та же скорость, так как ты не сможешь контролировать координаты чаще, чем это делает LinuxCNC, а значит должен будешь уменьшать скорость прохождения траектории.

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

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

Но для этого не надо писать СВОЁ ЧПУ, для этого надо сделать форк linuxcnc и наверено нескольких библиотек и модулей ядра и после отработки влить свой код в основной проект.

Вот это было бы реально полезно, причём не только LinuxCNC.

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

Мой предобработчик превращает команды вида

G1 X1 F100
X2
X3

В команды вида

G1 X1 P0 L80 F80
G1 X1 P80 L80 F100
G1 X1 P80 F80 L0

Где P - начальная скорость, F - посередине и L - конечная

А в чём это если учесть пункт 3 тебе это даст преимущество перед LinuxCNC?

Я понял твой механизм, по этому можешь его не упрощать.

Это тебе надо понять что при сервоуправлении он тебе претмуществ не даст, а вот проблем с коррекцией траектории будет куча.

У меня микроконтроллер умеет самостоятельно ходить по окружностям. В него отдается команда идти по дуге с такими то скоростями и он идпт по ней. Окружность выдерживается с точностью до длины шага.

А второе преимущество по сравнению с linuxcnc, которое я уже 100500 раз упоминал - не надо городить Rt ядра на компьютере

А второе преимущество по сравнению с linuxcnc, которое я уже 100500 раз упоминал - не надо городить Rt ядра на компьютере

У тебя КАЖДЫЙ сервоцикл будет все расчёты скоростей и координат отправлять в мусорку, в этом и есть смысл сервоцикла.
То есть планировщик в компьютере с каждым сервоциклом должен будет заполнять буфер заново.
И соответсвенно без RT на компьютере твой контролёр будет то и дело вставать, ну или заниматься "додумыванием и фантазиями" о том, что от него хотят и что он должен делать.

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

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

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

Почему?
1. Люфт
2. То что станок жёсткий не значит что он под нагрузкой не деформируется.
Под нагрузкой надо понимать и усилие резки и энерцию портала.

И это не дефекты, а номальное состояние станка.

Я тут на основе нашёго обсуждения сделал предложение по улучшению LinuxCNC, если хочешь присоединяйся.

Предложение по увеличению скорости работы LinuxCNC

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

Иногда без напильника никуда. Так что не уместно.

Разве не умеет?

Ну судя по тому, что я услышал от torvn77 - нет.

Если эта деформация в пределах нескольких шагов - ее точно так же можно компенсировать без глобального пересчета.

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

То есть ты встаёшь на путь «это у вас железо плохое» и «вам это не нужно» заместо того чтобы признать что с серво твоё ЧПУ будет работать плохо.

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

Может просто вместо поддержки обратной связи сказать "пользуйтесь моим ЧПУ только на свежесобранных станках"?

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

Еще раз: если у тебя станок выгибается незначительно, то никакого глобального пересчета не требуется, компенсировать несколько шагов вполне реально и без него. Если у тебя станок выгибается так, что требуется серьезный пересчет, то у тебя скорее всего от вибраций просто фрезу поломает и на этом все.

Он хочет поместить круговую интерполяцию непосредственно в генератор шагов.

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