roboforum.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код: Выделить всё • Развернуть

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

где

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

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

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

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

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

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

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

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

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

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

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

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