Michael_K писал(а):
Почему же? Можно и дуги интерполировать прямыми с точностью
до шага (то есть нисколько не хуже чем шагами, как вы делаете).
При этом команд все равно ЗНАЧИТЕЛЬНО меньше.
Здесь я с вами согласен, но моя задача изначально была ориентирована на шаговые привода. Так что для серв в этом случае либо использовать элементарные приращения в виде таких шагов, либо менять алгоритм интерполяции. Первый вариант по, утверждению некоторых специалистов, сам по себе всем не плох, кроме необходимости в передаче большого объема информации. Второй вариант для серв хорош, но не совместим с шаговыми приводами.
Вы умеете делать такую интерполяцию? Научите?
Michael_K писал(а):
Это вообще непонятно, какая разница? Мы задаем новое положение и время...
Куда и каким боком прикручена ось - контроллеру мотора вообще неведомо.
Приводу конечно-же глубоко пофиг, а вот интерполятору совсем даже нет: прямая в декартовых координатах станка и детали в координатах приводов некартезианских машин превращается в кренделя и, соответственно, наоборот.
Опять же, если научите интерполяции с переменной длиной интерполирующего отрезка - можно будет подумать как его применить и здесь.
Michael_K писал(а):
1. "Шаг/направление" вообще нереально сложить обратно в высокоуровневые команды,а готовые высокоуровневые команды у вас уже есть (из G-кода получены).
2. Ваши команды (шаг-направление) подразумевают использование шаговиков,а приводы могут быть и другие (например сервоприводы с энкодерами) - им лучше давать интегральные оценки,так как конкретно по шагам они не ходят, а вот регулировать скорость и выйти к заданному времени в определенную точку как раз могут.
3. Кроме того, я уже писал, винды - ДАЛЕКО не реалтаймовая система, а уж тем более,если речь идет об интервалах в несколько (или несколько десятков) микросекунд.
1. Вы хотите чтобы программа GIGAMESH транслировала команды из G-кода в какой-то другой код (команды) и передавала в железку? Не могу понять зачем это вам, да и мне... Вся суть и соль программы именно в интерполяторе - он умеет готовить траектории, и не только для картезианских станков, но и для любых других стационарных роботов (конечно же после описания кинематики). Если вам нужен транслятор, его проще написать заново, чем выковыривать из GIGAMESH`а. Шаг-направление довольно просто сложить обратно, но только не в прямые, а в специально предназначенные для этого функции. Конечно делать это лучше не с шагами-направлениями, а именно с точками траектории (они есть в интерполяторе).
2. Под интегральными оценками вы подразумеваете отрезки прямых? - это плохая интегральная оценка. Если уж по этому пути идти - то, как я писал ранее, использовать полиномы. Но см. постскриптум.
Да и как привязывать время к полиномам пока тоже совершенно не ясно.
3. Про реалтаймовость винды - готов с вами поспорить
(но лучше не здесь, а, например
здесь) - я утверждаю что все не так плохо, как говорят многие. Даже если речь идет о точности в микросекунды и, даже если речь не о драйверах уровня ядра.
Michael_K писал(а):
Перекладывание низкого уровня, где нужен временной детерминизм, на железосильно упрощает требования к софту.
Если вы еще не поняли - это одно из первейших и приоритетнейших направлений развития GIGAMESH. Но не потому что винда не детерминирована по времени, а потому что когда она такой становится, пользователю работать с ней становится невозможно.
Michael_K писал(а):
Ну, это как сказать...Что очень много в секунду - хоть и с трудом, но верю, а вот, что эти вызовы будут детерминированы- равномерно распределены во времени - нет.
Если что, я имею ввиду функцию:
Код:
unsigned int __stdcall CncCmd(char *uType, unsigned long int Val1, unsigned long int Val2)
boez писал(а):
Так это просто значит, что буфер должен быть в контроллере! И детерминированность тут совершенно не нужна. Интерфейс вполне достаточен для преобразования в скорости и координаты: у нас есть траектория, заданная шагами, и период импульсов, который привязывает эти шаги ко времени. Все, это уже готовая точная информация о траектории и скорости. Сделать буфер на 2 секунды, программа будет держать его полузаполненным, если комп даже на секунду "задумается" - контроллер будет продолжать отрабатывать траекторию, он же ее уже знает.
Именно! Спасибо
boez!
boez писал(а):
Второй вариант - когда временем заведует компьютер, передавая команды на контроллер - хуже, но если сильно захотеть - тоже может быть буферизован. Просто контроллер получает последовательность сигналов step+dir и формирует на ее основе команды позиционирования, сглаживая колебания скоростей. То есть он гарантирует, что траектория инструмента будет точно такая как задана - а вот скорость может отличаться. При этом контроллер, основываясь на заполненности буфера, подстраивает скорость движения по траектории (умножая вычисленное по step/dir на коэффициент) и таким образом не допускает опустошения или переполнения буфера. Но это уже ИМХО танцы с бубном и делать такое есть смысл только если у нас есть любимая и самая луччая управляющая прога, но она кроме ЛПТ ничего не умеет.
Именно это - идея LPT-bridge. Спасибо
boez! Этот подход хорош тем, что такая система будет работать не только с моим любимым GIGAMESH`/ем
, но и с любой другой программой, работающей с LPT-портом. Другое дело что GIGAMESH дает такому контроллеру дополнительную информацию о
точном времени шага, т.е. контроллеру не надо его мерять.
boez писал(а):
Или же это может быть процент заполненности буфера, как в вышеприведенном примере. Такая архитектура предпочтительнее - но управляющая программа должна быть под нее заточена - она не должна пытаться сама считать какие-либо временные интервалы, иначе потом окажется что контроллер выполняет их чуть-чуть медленнее или быстрее - и пойдет рассинхронизация.
И этот вариант планируется реализовать в GIGAMESH`е, в итоге это три варианта:
- Подмена драйвера LPT и обработка функций подобных Inp32 и Out32 в inpout32.dll и измерение интервалов между вызовами
- #1 без измерения интервалов, но с дополнительной функцией PulseTimes - передающей период импульса шага
- Функция CNCCmd, с контролем заполненности буффера
Варианты 1 и 2 в GIGAMESH реализованы.
boez писал(а):
...она не должна пытаться сама считать какие-либо временные интервалы, иначе потом окажется что контроллер выполняет их чуть-чуть медленнее или быстрее - и пойдет рассинхронизация.
Программа
должна рассчитывать временные интервалы - контроль скорости инструмента, разгон-торможение, LookAhead - это все задачи программы, а задача контроллера - как можно более точно их выполнить. Проблема рассинхронизации решается контролем заполненности буффера, ну или другой обратной связью, как вы и говорили.
З.Ы.: Уважаемые собеседники, большая просьба внимательно читайте, не хочется тратить время на повторения и спор ниочем.
Вход
Регистрация
FAQ
Поиск
, но я их не публикую целиком, отвечу на конкретные вопросы, и кусок кода, если надо покажу. Мне кажется так лучше. А вот если заброшу проект (что врядли) - вот тогда исходники будут опенсорс...