roboforum.ru

Вышла стабильная версия программы GIGAMESH для управления 3-координатным картезианским станком (портальный, консольный).

Возможности:
- управление станком с ЧПУ классической схемы (системой трех ортогональных приводов) по протоколу step/dir;
- 3D - линейная интерполяция G00, G01;
- круговая интерполяция G02, G03 в заданной плоскости;
- выбор плоскости круговой интерполяции G17, G18, G19;
- ручное управление приводами с помощью колеса мыши;
- ускоренное движение приводов;
- поддержка LPT-моста;
Здесь можно подробнее почитать о программе, а также скачать полную рабочую версию и краткую инструкцию к ней .

Программа GIGAMESH2 H бесплатна для любого применения.

С уважением, spike.

Эт наверное в наши достижения надо, не?

А можно встречный вопрос?...

У меня есть станок с ЧПУ, который управляется через USB
командами типа "шагов по оси 1, шагов по оси 2... шагов по оси N, время" (ну это упрощенно).
Можно ли (если да, то как) заставить вашу программу взять готовый G-код,
преобразовать его в такие команды, отправить в порт, дождаться выполнения и т.д.?
Или LPT - и все?

Исходники есть?
Поддерживается ли скажем смена инструмента и калибровка после смены,
контроль концевиков и т.д.?

Вообще, расскажите о программе и возможностях поподробнее.

Ну и общий вопрос: может быть кто-то подскажет
CAM-программу, к которой можно было бы (без сильных извращений)
прикрутить драйвер для такого станка.
(OpenSource или c открытым API для железа)?

Michael_K
Этот драйвер сами делали?

Michael_K писал(а):У меня есть станок с ЧПУ, который управляется через USBкомандами типа "шагов по оси 1, шагов по оси 2... шагов по оси N, время" (ну это упрощенно).Можно ли (если да, то как) заставить вашу программу взять готовый G-код,преобразовать его в такие команды, отправить в порт, дожаться выполнения и т.д.?Или LPT - и все?

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

Michael_K писал(а):Исходники есть?

У меня есть , но я их не публикую целиком, отвечу на конкретные вопросы, и кусок кода, если надо покажу. Мне кажется так лучше. А вот если заброшу проект (что врядли) - вот тогда исходники будут опенсорс...

Michael_K писал(а):Поддерживается ли скажем смена инструмента и калибровка после смены,контроль концевиков и т.д.?

Этого пока нет, как и многого другого. Программа умеет практически только то, что анонсировано.

Michael_K писал(а):Вообще, расскажите о программе и возможностях поподробнее.

Блин, с удовольствием, но очень трудно придумать что рассказать о чем-то, если знаешь об этом все. Так что лучше в режиме вопросов-ответов, если не возражаете

AndreiSk писал(а):Эт наверное в наши достижения надо, не?

Не, это все-таки проект.

Michael_K писал(а):Драйвер софтовый для PC... напишу, если буду знать API, к чему и зачем цеплять.

Это надо обсудить... Мне очень нравится идея LPT-моста: подменяется стандартный драйвер LPT, поток данных перенаправляется в интеллектуальное устройство (по любому интерфейсу и протоколу), можно реализовать и буферизацию и пр... В GIGAMESH встроено расширение для такого LPT-моста - в драйвер программа пытается передать временной интервал для каждого шага.

Мне очень нравится идея LPT-моста: подменяется стандартный драйвер LPT

Мне СОВСЕМ не нравится идея LPT.

LPT-порт (не ваш мост, а физический) практически выходит из употребления.
(я не хочу к станку - в опилки и масло - тащить комп, например, а eeePC какую-нибудь - можно .

Но проблема не только в физическом порту.
Проблема в том, что в LPT вы выдаете программно импульсы шагов-направления,
это значит, скорость и джиттер (неравномерность шагов) зависит от мощности компа,
загрузки системы, ну и прочих "странностей"...

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

Я бы предпочел более высокоуровневое API (например, конкретно в моем случае - это
относительные координаты следующей точки - в микрошагах, время за которое туда надо
доехать - в "попугаях" - то есть можно послать одну команду и он через весь стол поедет сам),
чем выковыривать отдельные импульсы STEP/DIR из LPT-моста.

+1
Я тоже думаю, программа должна вести обработку G-кода, а посылать на исполняемый контроллер количество шагов по осям, тогда в настройках программы можно учесть все нюансы механики (шаг винта, кол-во шагов на оборот ШД , временные задержки между шагами и т. д.)

Michael_K писал(а):Мне СОВСЕМ не нравится идея LPT.

LPT, как порт мне нравится... нормальный такой обычный порт, быстрый весьма... в силу параллельности... Но я говорю не о LPT-port, а о LPT-bridge!
Читаем здесь:

Код: Выделить всё

unsigned int __stdcall CncCmd(char *uType, unsigned long int Val1, unsigned long int Val2)

- возвращает процент заполнения буффера, управляющая программа должна поддерживать заполненность в диапазоне (25-75%)
- uType - тип выполняемой команды:
'Step' - выполняет шаг по 32-битной маске Val1 (DSDSDSDSDSDSDSDSDSDSDSDSDSDSDSDS), D - направление, S - шаг (S=1 - выполняется шаг, S=0 - шага нет), индексация приводов: 1-й привод соответствует младшим битам, 16-й привод старшим; Val2 - период выполнения шага в микросекундах
'Control'- выполняет включение/отключение по маске Val1, 1 - включено, 0 - отключено, индексация устройств: 1-е устройство соответствует младшему биту, 32-е - старшему; Val2 - время паузы после выполнения команды включения в микросекундах
Делаем библиотеку lptbridge.dll, при загрузке программа ищет ее, если находит - пытается загрузить функцию CNCCmd. Если успешно - работаем дальше с ними, если нет - загружаем inpout32.dll, работаем с ней. При этом, если в библиотеке inpout32.dll есть процедура PulseTimes (считаем что библиотека -подменная) - в нее шлется время периода и таймаута.
Соглашение о вызовах:

Код: Выделить всё

procedure Out32(PortAddress: smallint; Value: smallint);stdcall; external 'inpout32.dll';
function Inp32(PortAddress: smallint): smallint; stdcall; external 'inpout32.dll';
procedure PulseTimes(PulseTime, TimeOut: integer); stdcall; external 'inpout32.dll';

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

Michael_K писал(а):Я бы предпочел более высокоуровневое API (например, конкретно в моем случае - это относительные координаты следующей точки - в микрошагах, время за которое туда надодоехать - в "попугаях" - то есть можно послать одну команду и он через весь стол поедет сам),чем выковыривать отдельные импульсы STEP/DIR из LPT-моста.

Поймите, так можно сделать только для прямых и только для картезианских машин. Попробуйте представить последовательность таких "координат-попугаев" для дуги, сразу станет ясно почему так низззя. Так что шаги и периоды... их кстати тоже можно упаковывать простейшими алгоритмами... Можно по-другому: есть быстрые алгоритмы интерполяции полиномов, вот для них можно было бы мне генерить коэффициенты - упаковывать, а вам их распаковывать-интерполировать... НО! уверен, что эта работа весьма небыстрая... можно в перспективе об этом подумать.

Поймите, так можно сделать только для прямых

Почему же? Можно и дуги интерполировать прямыми с точностью
до шага (то есть нисколько не хуже чем шагами, как вы делаете).
При этом команд все равно ЗНАЧИТЕЛЬНО меньше.
(Хотя у меня и реализованы "чистые" дуги в двух координатах в железе,
обычно интерполяции прямыми за глаза хватает).

и только для картезианских машин.

Это вообще непонятно, какая разница? Мы задаем новое положение и время...
Куда и каким боком прикручена ось - контроллеру мотора вообще неведомо.

1. "Шаг/направление" вообще нереально сложить обратно в высокоуровневые команды,
а готовые высокоуровневые команды у вас уже есть (из G-кода получены).

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

3. Кроме того, я уже писал, винды - ДАЛЕКО не реалтаймовая система, а уж тем более,
если речь идет об интервалах в несколько (или несколько десятков) микросекунд.
Перекладывание низкого уровня, где нужен временной детерминизм, на железо
сильно упрощает требования к софту.

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

Ну, это как сказать...
Что очень много в секунду - хоть и с трудом , но верю,
а вот, что эти вызовы будут детерминированы
- равномерно распределены во времени - нет.

Вот у вас винды захотят время перевести на зимнее (или еще какую-нибудь пакость выдумают )
и тормознут ваш крутейший автобус... "всего" на 10 миллисекунд...

Для моего станочка это 400 микрошагов... даже если шаговик не потеряет шага и потом продолжит,
как ни в чем не бывало, то инструмент за это время ТАКУЮ "кляксу" в рабочей зоне поставит,
что можно будет смело выкидывать все... причем вместе со станком

Michael_K писал(а):Ну, это как сказать...
Что очень много в секунду - хоть и с трудом , но верю,
а вот, что эти вызовы будут детерминированы
- равномерно распределены во времени - нет.

Вот у вас винды захотят время перевести на зимнее (или еще какую-нибудь пакость выдумают )
и тормознут ваш крутейший автобус... "всего" на 10 миллисекунд...

Так это просто значит, что буфер должен быть в контроллере! И детерминированность тут совершенно не нужна. Интерфейс вполне достаточен для преобразования в скорости и координаты: у нас есть траектория, заданная шагами, и период импульсов, который привязывает эти шаги ко времени. Все, это уже готовая точная информация о траектории и скорости. Сделать буфер на 2 секунды, программа будет держать его полузаполненным, если комп даже на секунду "задумается" - контроллер будет продолжать отрабатывать траекторию, он же ее уже знает.

Вообще это фундаментальный момент при управлении через контроллер, который нужно решить изначально, от него зависят дальнейшие особенности архитектуры. А именно - кто является первичным источником отсчета времени - контроллер или компьютер. Если контроллер - должна обязательно быть обратная связь от него к компьютеру. Ну то есть компьютер шлет некие команды, содержащие указания о том, с какой скоростью и на какое расстояние нужно двигаться по всем координатам, а обратно приходят подтверждения, на основании которых управляющая программа решает - когда слать следующую команду или пачку команд. Это может быть просто флаг "готов к приему следующей команды", причем это вовсе не означает что все предыдущие выполнены - несколько штук вполне могут лежать в FIFO-буфере контроллера, просто это значит что в этот буфер войдет очередная команда. Или же это может быть процент заполненности буфера, как в вышеприведенном примере. Такая архитектура предпочтительнее - но управляющая программа должна быть под нее заточена - она не должна пытаться сама считать какие-либо временные интервалы, иначе потом окажется что контроллер выполняет их чуть-чуть медленнее или быстрее - и пойдет рассинхронизация.

Второй вариант - когда временем заведует компьютер, передавая команды на контроллер - хуже, но если сильно захотеть - тоже может быть буферизован. Просто контроллер получает последовательность сигналов step+dir и формирует на ее основе команды позиционирования, сглаживая колебания скоростей. То есть он гарантирует, что траектория инструмента будет точно такая как задана - а вот скорость может отличаться. При этом контроллер, основываясь на заполненности буфера, подстраивает скорость движения по траектории (умножая вычисленное по step/dir на коэффициент) и таким образом не допускает опустошения или переполнения буфера. Но это уже ИМХО танцы с бубном и делать такое есть смысл только если у нас есть любимая и самая луччая управляющая прога, но она кроме ЛПТ ничего не умеет.

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`е, в итоге это три варианта:

1. Подмена драйвера LPT и обработка функций подобных Inp32 и Out32 в inpout32.dll и измерение интервалов между вызовами
2. #1 без измерения интервалов, но с дополнительной функцией PulseTimes - передающей период импульса шага
3. Функция CNCCmd, с контролем заполненности буффера

Варианты 1 и 2 в GIGAMESH реализованы.

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

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

З.Ы.: Уважаемые собеседники, большая просьба внимательно читайте, не хочется тратить время на повторения и спор ниочем.