cnc-club.ru

MX_Master писал(а):Опыт плат mesa показывает, что усё успевается.

Само успевается или специальными драйверами/патчами?

Сергей Саныч писал(а): а не придется ли нам иногда "подождать", пока ядро чего-то там делает, например, картинку там выводит или обменивается с диском. И не превысит ли это время сервопериод?

А почему Надо обязательно передавать данные каждый сервоцикл?Нельзя разве организовать буфер?

Сергей Саныч писал(а):

MX_Master писал(а):Опыт плат mesa показывает, что усё успевается.

Само успевается или специальными драйверами/патчами?

Лично я тестировал общение STM32 c Orange Pi PC на обычном RT ядре 4.х. Всё успевается. Владельцы плат меса могут поделиться своим опытом

sidor094 писал(а): А почему Надо обязательно передавать данные каждый сервоцикл?Нельзя разве организовать буфер?

Это будет уже не RT

sidor094 писал(а):А почему Надо обязательно передавать данные каждый сервоцикл?Нельзя разве организовать буфер?

Потому, что надо считывать фактически выданное количество STEPов и делать это каждый сервоцикл. LCNC учитывает эти данные при выдаче следующего пакета. Так уж он устроен.
За счет этой обратной связи упрощается периферийное оборудование - все серьезные вычисления переносятся на сторону ПК.

MX_Master писал(а):Это будет уже не RT

Так это наоборот плюс .Возможность работать с операционкой которая не поддерживает RT. Как это ухудшит параметры системы?Естественно если не делать буфер на десятки секунд.

Сергей Саныч писал(а):Потому, что надо считывать фактически выданное количество STEPов и делать это каждый сервоцикл. LCNC учитывает эти данные при выдаче следующего пакета.

Может я чего-то не понимаю,я не знаю LINUXCNC.А нельзя фактически выданное число сделать равным фактически заданному?И завернуть обратную связь внутри LINUX а не снаружи?

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

Обратная связь уже есть, именно поэтому нужен RT - нужно вовремя вычислить и выдать задание в нынешнем сервоцикле учитывая то, что было исполнено в предыдущем.
Пример: В каждом сервоцикле надо генерить 1000 шагов. Система у нас показывает джиттер (latency) максимум 10000 (нс). Таким образом в реальности в каждом сервоцикле будет генерится от 990 до 1010 шагов. Т.к. в LinuxCNC есть обратная связь (по дефолту), то к началу каждого следующего сервоцикла LinuxCNC будет вычислять поправку к запланированному заданию. Поэтому никакие буферы тут никаким боком не годятся.

Сергей Саныч писал(а):Кроме того, есть сигналы от физических датчиков, которые тоже требуют своевременной обработки.

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

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

АнтиСтепмастер?

UAVpilot писал(а):АнтиСтепмастер?

Буфер наоборот позволяет выравнивать переходы между сервоциклами.Так как в буфере хранится информация для нескольких сервоциклах,то поступление очередного информационного цикла позволяет чуть чуть подстроить время выдачи шагов.Как в синтезаторе частоты.Так что среднее время будет плавать вокруг сервоцикла.И ,в итоге за все время работы станка будет отличаться от образцового (задаваемого LINUXOM)всего на 10000 нс.

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

К примеру, сигналы STEP осей X/B/C попадут на выходы трёх разных таймеров. Это значит, что на осях X/B/C можно получить частоту шагов до 2 МГц. А вот сигналы STEP осей Y/Z/A попадают на разные каналы одного аппаратного таймера. В самом простом случае, это значит, что только одна из осей Y/Z/A сможет иметь аппаратный вывод шагов до 2 МГц, а две оставшиеся будут сидеть на софт выводе до 200 КГц. Но это ещё не точно. Как-то давно я проводил эксперименты с аппаратным выводом шагов с разных каналов одного таймера для разных осей. Сложность исполнения при этом высокая, но это возможно. Надо стряхнуть пыль в голове на этот предмет, чтобы сказать точнее.

Основным плюсом во всей этой истории является факт, что мы юзаем LinuxCNC. Мы можем перенаправить в HAL файле вывод степ/дир какой-то оси на другой канал stepgen'a. Например, на тот, который полностью аппаратный И после этого просто подключить проводки к другому выходу контроллера.

sidor094 писал(а):Буфер наоборот позволяет выравнивать переходы между сервоциклами.

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

UAVpilot писал(а):Расхождения надо компенсировать как можно быстрее

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

sidor094 писал(а):

UAVpilot писал(а):Расхождения надо компенсировать как можно быстрее

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

Мне кажется ты пытаешься смотреть на сервоциклы, так-же как и на обычные команды которые посылаются например в те-же ардуино подобные контроллеры.
Но концепция систем управления тут кардинально отличается, наличие буфера для сервоциклов в принципе невозможно.

Буфера хороши на женской фигуре, но никак не в LinuxCNC (:

Кстати, у производителя оригинального китайского контроллера NVEM есть в линейке ещё парочка контроллеров на STM32 + Ethernet

https://www.nvcnc.net/
EC300, EC500, NVEC 400

selenur писал(а):Но концепция систем управления тут кардинально отличается, наличие буфера для сервоциклов в принципе невозможно

Почему?Какая разница между буфером команд и буфером сервоциклов?В чем при этом принципиально отличается работа с буфером?По сути и там и там буфер заданий.Разница только в том ,что в Ардуино ,наверное(с Ардуиной не работал) синхронизируется компьютер по готовности процессора,а здесь надо синхронизировать процессор с компьютером.Если кто делал программу для нарезания резьбы тот поймет ,это как синхронизировать скорость выполнения движения ,например с оборотами шпинделя.Это конечно не относится к самодельным системам типа "электронной гитары" где выполняется просто деление тиков и шагов двигателя(это требует очень блольшого числа точек энкодера для получения деления).А нормальная синхронизация ,которая может работать даже с одним тиком на оборот шпинделя и при этом получать резьбы с достаточно большим шагом.Можно так же привести в пример работу синтезатора частоты или привода ,где в зависимости от ошибки по времени между собственным и внешним сигналом увеличивается или уменьшается частота собственного сигнала.

Система с выдачей перемещений по сервоциклам без обратной связи в принципе возможна, но она потребует гораздо более сложного программирования. И это уже будет не LinuxCNC, где ОС - одна из его базовых концепций. Даже когда система работает через LPT, все равно для коррекции накапливаемой ошибки (скажем, по причине округления при переводе в целые) используется обратная связь внутри программы генерации шагов.

Когда то копаясь в кишках кода ЕМС я увидел, что параметр сервоцикла используется в двух разных частях.
Первый раз в пространстве пользователя при расчете интерполяции траектории перемещения и второй раз в HALe при обработке компонентов.
По моему, при применении внешнего контроллера движения, реалтайм вообще не нужен. Достаточно обеспечить передачу из FIFO интерполятора во внешний контроллер пакетов с координатами.
А во внешнем контроллере организовать хал компонент со своим сервоциклом идентичным интерполятору.
Обратные связи существуют только в ХАЛе. На уровень интерпретатора Г кода приходит только признак ошибки компонента ХАЛ.
Ну или перенести весь ХАЛ в микроконтроллер, а лучше в ПЛИС.

И тот, кто это сделает может взять с полки пирожок