cnc-club.ru

Impartial писал(а):По моему, при применении внешнего контроллера движения, реалтайм вообще не нужен. Достаточно обеспечить передачу из FIFO интерполятора во внешний контроллер пакетов с координатами.

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

Impartial писал(а):Ну или перенести весь ХАЛ в микроконтроллер, а лучше в ПЛИС.

Перенести-то не проблема, нужно только придумать какой-то "конфигуратор", ибо в МК HAL-файлы не очень-то поредактируешь - много RAM для этого требуется...

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

Реальное время понятие растяжимое.Для большинства случаев(не считая движения)достаточно виндосовского (если не считать всяких подвисаний системы).Но кто мешает некоторые основные реакции на события засунуть в контроллер.Что касается данных ,то я их записываю в различные конфигурационные файла на внешнюю карточку микросд. Применение полного внешнего контроллера движения вызывает много проблем.Выдача шагов по информации зашитой в сервоцикле как раз проблемой на мой взгляд не является ,главное чтобы самая сложная часть-планировщик сидел на компе.Так как расчет ускорений иногда достаточно сложен.Тем более всяких там s образных.И если эта часть находится на компе то их разработкой могут заниматься грамотные люди (пишущие саму LINUXCNC).

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

Impartial писал(а):А следить за точностью это забота привода.

Да ну?!

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

Prav писал(а):Да ну?

Ну да!

sidor094 писал(а):А значит это касается и ускорении.

Расчет траектории, в планировщике, уже учитывает параметры максимально допустимых скоростей и ускорений.
Данные о координатах на сервоциклы идут уже с планировщика.

Impartial писал(а):Именно так все и происходит. Привод следует только заранее рассчитанным координатам.

Даже при нарезании резьбы на токарном?

sidor094 писал(а):Реальное время понятие растяжимое.

Как раз наоборот: RealTime - это гарантированное время реакции на события.

sidor094 писал(а):Что касается данных ,то я их записываю в различные конфигурационные файла на внешнюю карточку микросд.

Нет проблем с их хранением. Но их нужно "исполнять", парсинг конфигов и создание связей между компонентами HAL требует много RAM, которая в большинстве МК в дефиците.

Собственно чего спорить-то? - Берите и пишите, раз всё так просто.

UAVpilot писал(а):RealTime - это гарантированное время реакции на события.

Для каждой системы оно свое.если у мк оно вообще может составлять менее микросекунды то для компьютерных систем могут быть до нескольких секунд .Весь вопрос какое нам нужно?

UAVpilot писал(а):Берите и пишите, раз всё так просто

Я бы попробовал написать,но дело в том ,что я не знаю LINUX И LINUXCNC в частности.Что касается памяти,то я использую плату с дополнительным озу 16 мб.
На ней же организован видеоконтроллер и зпгрузка программ из микросд .
https://www.youtube.com/watch?v=VStkQ4tethQ
https://www.youtube.com/watch?v=oQoDaT1cjiI

sidor094 писал(а):Я бы попробовал написать,но дело в том ,что я не знаю LINUX И LINUXCNC в частности.

О чём мы тут говорим?..

sidor094 писал(а):Что касается памяти,то я использую плату с дополнительным озу 16 мб.
На ней же организован видеоконтроллер и зпгрузка программ из микросд .

Функционал как у LinuxCNC?..

UAVpilot писал(а):О чём мы тут говорим?..

UAVpilot писал(а):Функционал как у LinuxCNC?.

Нет конечно.Во-первых памяти для многих приложений маловато.Поэтому приходится при больших объемах программы организовывать буфер и постоянную подгрузку.При этом сокращается длина возможного перехода по goto и становится невозможным функция редантирования.Правда я не думаю ,что кто-нибудь вручную будет писать или редактировать программы более нескольких десятков килобайт ,а так как параметрические программы пишутся только вручную(без использования CAM) то и goto в больших программах вряд ли кто нибудь будет использовать.Кроме того я хоть и попытался сделать возможным программирование через макросы,но функционал явно не сравним с LINUXCNC.Именно по этим причинам использование внешнего контроллера и основной программы на компе считаю очень удобным вариантом.

UAVpilot писал(а):О чём мы тут говорим?..

Несмотря на то,что я не разбираюсь в LINUX считаю ,что для написания программы на контроллер достаточно знать интерфейс между контроллером и компьютером .Более того хотелось бы сделать этот интерфейс максимально независимым от особенностей системы(Эв частности жесткого реалтайма)С тем ,чтобы была возможность организовать взаимодействие контроллера не только с LINUXCNC но и с другими программами ,написанными даже в других системах(WINDOWS,ANDROID) так как многим проше использовать известные им системы. Поэтому я и предлагаю по возможности снять ограничения во взаимодействии с контроллером ,налагаемые LINUXCNC.Я понимаю,что здесь в основном общаются люди хорошо разбирающиеся в LINUXCNC.Но я думаю,что контроллер с более широким спектром взаимодействия с управляющими программами будет и более востребован.

sidor094 писал(а):Но я думаю,что контроллер с более широким спектром взаимодействия с управляющими программами будет и более востребован.

Китайский контроллер работает с Mach3 (:

Но здесь-то обсуждается контроллер именно для LCNC. И универсальность ему ни к чему. Она только усложнит реализацию. А "контроллер с более широким спектром" - это, к примеру, Степмастер.

UAVpilot писал(а):Даже при нарезании резьбы на токарном?

Если программа для нарезания написана в Г кодах, то да.

Кстати, в этом проекте ХАЛ перенесли в микроконтроллер.
https://github.com/rene-dev/stmbl

MX_Master писал(а):Китайский контроллер работает с Mach3

А что у MACH и LINUXCNC похожие протоколы?

Сергей Саныч писал(а):Но здесь-то обсуждается контроллер именно для LCNC. И универсальность ему ни к чему. Она только усложнит реализацию. А "контроллер с более широким спектром" - это, к примеру, Степмастер.

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

Impartial писал(а):Если программа для нарезания написана в Г кодах, то да.

Я подразумевал реализацию самой функции нарезания резьбы внутри контроллера.

Для того чтобы не было больших задержек реакции на датчики буфер не должен быть очень большим.Например при длительности сервоцикла в 1мс достаточно его сделать от 10-100 циклов.При учете того что буфер в среднем поддерживает половинное заполнения его размер должен бать в 2 раза больше.Это позволить реагировать на сигнал датчика с садержкой в 10-100мс.Что в большинстве случаев вполне приемлемо.

Попробуй игроку в КС сделать время реакции мыши в 100мс и сразу узнаешь, что в большинстве случаев это неприемлемо

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

Мы тут вообще не про буфер для хранения УП!

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

Совершенно недостаточно. Я не просто так приводил в пример процедуру нарезания резьбы на токарном.

sidor094 писал(а):Более того хотелось бы сделать этот интерфейс максимально независимым от особенностей системы

Всем хочется, дело осталось за малым...

Impartial писал(а):Если программа для нарезания написана в Г кодах, то да.

Как обеспечить синхронизацию буферов со шпинделем?..

Impartial писал(а):Кстати, в этом проекте ХАЛ перенесли в микроконтроллер.
https://github.com/rene-dev/stmbl

Хорошо знаю этот проект. Да, перенесли, но с очень большими ограничениями.

MX_Master писал(а):Попробуй игроку в КС сделать время реакции мыши в 100м

Ну ,я написал от 10 до 100 мс.Это вопрос решаемый.Что касается реакции человека то доказано,что реакция человека на зрительное событие от 100 до 400 мс .Среднее 200-300.При этом 100 мс у единиц.Это свойство врожденное его развить не возможно.

UAVpilot писал(а):Как обеспечить синхронизацию буферов со шпинделем?..

Если шпиндель использовать как сервопривод,то есть резко тормозить и разгонять его,то конечно проблематично при этом обеспечить синхронизацию координаты с ним даже с временем задержки в 10 мс.Считается ,что сервоцикл сервопривода должен быть 1мс (по госту).То есть при этом сервопривод имеет достаточную быструю реакцию обратной связи на различные воздействия.Шпиндель все-таки не сервопривод координат,и таких резких изменений скорости у него нет.В качестве примера можно привести возможность нарезания резьбы в мач всего по одной метке на оборот.Так что задержка в 10 мс будет вполне приемлема.Что касается самой задержки,то она повлияет только на начало захода резьбы.Насчет 100 мс ,я наверно не прав при нарезании резьбы. Хотя я думаю все равно при более менее равномерном вращении шпинделя все будет нормально.Сам же контроллер вмегда остается жестко синхронизированным с компьютером буфер же просто внесет небольшую задержку.Так что при отсутствии резких колебаний скорости шпинделя в течении 10мс нарезание резьбы проблем не составит

время отклика геймерского монитора - от 1мс до 5мс а ведь на него смотрит всего лишь медленный глаз человека

У меня брат оканчивал институт физкультуры.И там объясняли ,что время реакции -врожденное .Его натренировать невозможно.И время от поступления светового сигнала ,до начала ответной реакции на него у различных людей варьируется от 100-400 мс.Но речь здесь конечно не об этом.Если не считать синхронизацию со шпинделем, то надо прикидывать например время торможения сервопривода и от него отталкиваться.То есть надо сравнивать задержка в системе и время реакции сервопривода.