roboforum.ru

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

Добавлено спустя 53 секунды:
spike, сорри - сначала написал, потом прочитал

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

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

мой "станочек" например гоняет лазер по голограммке.

Ну ладно, нет, так нет, придется учиться писать плагины к MACH3...

Michael_K писал(а):

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

Это далеко не всегда возможно.

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

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

Для интерполятора все равно для чего будет использоваться его траектория

Michael_K писал(а):Ну ладно, нет, так нет, придется учиться писать плагины к MACH3...

Что-то вы как-то быстро соскочили с темы, зря мне кажется... Кто сказал нет-то?

Добавлено спустя 3 минуты 14 секунд:

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

Дыкть есть уже кое что, а отдаст она с удовольствием, да еще проконтролирует чтоб слишком много не было, или мало... Но несколько позже.

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

A!!! Наконец-то понял о чем вы!
Комп должен знать, насколько у контроллера заполнен буфер!
Согласен, в этом случае жесткий реалтайм на компе не нужен.

Что-то вы как-то быстро соскочили с темы, зря мне кажется...

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

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

То есть мне нужна САМ-система для ортогональных осей.

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

2 Michael_K
Можете в отдельной теме описать свой контроллер по подробней, ну в рамках того что вы можете описать? Просто я тоже буду скоро такое делать, не хотелось бы изобретать велосипед.
Какой алгоритм работы, какие команды, есть ли функция разгона и торможения.

Michael_K писал(а):A!!! Наконец-то понял о чем вы!

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

Попробую еще аргументы привести против вашей идеи о кусочно-линейной интерполяции. Вобщем, стал я вспоминать разговор с одним спецом по электроприводу, так вот, когда я ему предлагал подобный вариант (причем даже не кусочно-линейную, а сплайн-интерполяцию) он сказал примерно следующее: - нет нафиг, хорошего из этого не выйдет, ты мне, говорит, передавай элементарные приращения и для каждого время, а про остальное забудь. Вот. Я уж не помню что он говорил, почему так. Ну да ладно... Сам вот что подумал:
Вот представь себе (ничего что все-таки на ты?) приводу нужно отработать заданную криволинейную траекторию, но не просто отработать, а за строго определенное время (чтобы соблюсти, например, скорость подачи, скоростные характеристики моторов). Так? Ну вот а теперь подумай, как ты будешь сшивать эти отрезки во времени, и самое интересное, что из себя будет представлять алгоритм ускорения-торможения! Или на каждом отрезке вначале надо будет разогнаться, а в конце затормозить? Если так - будет полная фигня. Поэтому аглоритму, который рассчитывает временные интервалы должен быть доступен весь кадр, а еще лучше вся программа.

Michael_K писал(а):Сами алгоритмы есть, но как оказалось, G-кодов столько разных вариантови команд, что этот кусок (парсер Г-кода) хочется готовый поиметь.Слишком сложно в тестировании...

Да, насчет алгоритмов (кусочно-линейных) подумал - полно их готовых даже.
Насчет G-кода и парсера все довольно просто - можно отдельно пообщаться на эту тему. Думаю что мог бы помочь. В следующей версии программы будет примерно такие информационные потоки:

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

УП -> КП(xml) -> ТР+ЭА(битовые маски) -> ТР+ЭА+В (битовые маски с метками времени)

где

• УП - управляющая программа (может быть Ж-код, HPLG, DWG, да хоть BMP, да что угодно...), транслируется в КП;
• КП - каноническая программа (каждый кадр самодостаточен, может быть обработан и выполнен отдельно от всей программы), наброски системы команд этого языка здесь - внимание! это черновик... и об xml там пока нет ни слова. Я попробовал, в xml кадры укладываются идеально
• ТР+ЭА(битовые маски) - по две 32-битных маски на каждый шаг, первая - протокол step-dir, вторая - электроавтоматика
• ТР+ЭА+В (битовые маски с метками времени) - здесь добавляется метка времени.

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

Michael_K писал(а):Тут, мне кажется, проще что-то более подходящее поискать или даже с нуля наваять, чем вашу прогграммку адаптировать, хотя вам, конечно, виднее.

С свете аргумента про временные характеристики, рассмотри этот вопрос.

Попробую еще аргументы привести против вашей идеи о кусочно-линейной интерполяции.

Какая нафиг идея - это железка реальная живая.
Приводи аргументы, не приводи аргументы, она по-другому работать не станет!

Добавлено спустя 6 минут 29 секунд:
Там буфер есть, конечно, поэтому в "склейках" не происходит сбоев.
Например, по кругу (линейно кусочному) она едет ОЧЕНЬ плавно.
При этом интервалы между шагами (в том числе и между шагами в разных "отрезках")
стоят практически с точностью кварца!!!

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

В пределе МОЖНО даже на каждый шаг такую команду выдавать -
тогда и получится полный аналог вашего интерфейса,
только траффик будет немерянный (при 40000 шагах-то в секунду).

Добавлено спустя 11 минут 12 секунд:
А реально я даже думаю, что компу 40000 шагов в секунду - мало не покажется...
и застревания неизбежны. Или буфер в контроллере придется городить безумный.

Добавлено спустя 5 минут 5 секунд:
Кстати, по поводу кусочно-линейности...
Там дуги в двух координатах и спирали тоже реализованы были, но, насколько я знаю,
то ли не вошли в окончательный вариант, то ли ими не пользуются просто....

Michael_K писал(а):Торможения и разгоны задаются компом, он выдает не только куда ехать,но и за какое время... Я ж писал вроде об этом.

Так все-таки, девайсу достаточно координаты и времени, для ее достижения? или еще какие-то параметры туда пересылаться должны? Ну и вопрос задам, с которого надо было начать: хоть двух словах об алгоритме работы вашей железки в связке с РС расскажите?

хоть двух словах об алгоритме работы вашей железки в связке с РС расскажите?

Я только железо делал. Софт для PC не я писал, хотя простенькие программки ваял, конечно, при тестировании.

Да и при чем здесь ЕГО алгоритмы? Я же писал - применение специальное (гоняет лазер по голограммке).
Свою задачу он делает... и может быть даже вообще без "алгоритмов", а с жесткой последовательностью команд...
Мне же хотелось бы использовать ЭТОТ ЖЕ стол в более широком применении, чтобы он стандарты понимал
Г-коды, напрмер...

Я спрашиваю об алгоритмах подготовки управляющих воздействий (по вашему утверждению это координата-время) и обработке их сервоконтроллером. Просто расскажите, вот мол, РС делает кусочно-линейную интерполяцию траектории, при этом получаются такие-то данные, просчитывает временные точки, так, чтобы то-то и то-то... потом РС передает такие-то команды и параметры в сервоконтроллер, в нем они хранятся (буферизуются) или нет, если да - то сколько и зачем... Конкретно такие-то данные нужны сервоконтроллеру: координата-время, коэффициенты ПИД, параметры ускорений, что-то еще. Дальше, какие цели ставятся ПИД-регулятору, такие-то исходные условия в начале линейного отрезка, такие-то в конце... "сшивка" осуществляется так, чтобы то-то и то-то... ПИД-регулятор осуществляет регулирование по скорости и/или по положению или еще по чему-то...
Поймите, без четкого понимания хотя бы в общих чертах алгоритма функционирования никакие дальнейшие действия не возможны.

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

продолжать диалог - о такой разработки всем кроме вас ни горячо ни холодно

Я и не говорил, что кому-то должно быть горячо или холодно.
Диалог о моей разработке - не моя инициатива.

Я же спрашивал О ВАШЕЙ ПРОГРАММЕ. Я задал конкретные вопросы, о том,
можно ли применить вашу программу для управления моей железкой - понял, что нет.

Michael_K писал(а):Я задал конкретные вопросы

Спасибо Вам за это. Многие вещи формализовались и появились в виде текстового описания.
Очень жаль что Ваши знания останутся только Вашими...

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

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

Предельно понятно.
Мне кажется краткое описание, в стиле примера выше, нисколько не будет противоречить этому? И ваши соображения по этому вопросу тоже были бы немало интересны. Возможно что в будущих версиях будет реализовываться поддержка векторного управления сервами, может быть... Очень бы хотелось учесть возможные ньюансы такого управления...

Michael_K, интересная у вас жестянка получилась. Микрошаг на скорости 40000 шагов - это чего то да стоит. Давай так. Есть проект, который делается русскими людьми, с которыми ты тоже всегда можешь договариться на русском языке, да? Проект, как мне думается, весьма успешный. Есть такое предложение. Ты вливаешься в проект - одни знания и опыт чего стоят - а обязательства - черт с ними, мы ж в россии живем. Ту программу, о которой ты интересовался, ты можешь помочь сделать весьма достойной твоего детища. Вот это деловой подход. И очевидный профит.