cnc-club.ru

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

Имеется Yaskawa управляемая по скорости.
Mesa 6i25 + 7i77.
EMC2.

Не могу понять идеологически, как всё должно ползать по-нормальному ?

1. Яскавовский контроллер принимает к себе от месы X вольт, и едет, пока имеет эти Х вольт на входе. Это понятно.
2. Наружу яскава дает сигнал от энкодеров - это тоже понятно. Пока забудем о том, как всё надо запитывать, когда подавать SON итп.

3. Меса получает от яскавы значения с энкодеров - это понятно. Но кто его обрабатывает, чтобы осуществить PID-регулирование ?
Если делать это со стороны EMC2, то нафига вообще нужна меса ? Только для разгрузки LPT-порта ?
Нельзя ли прямо внутри этой могучей электроники реального времени рассчитать PID и выдать его сразу же наружу без EMC ?

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

Еще раз сформулирую вопрос: где должны обрабатываться данные с энкодеров и генерироваться (с помощью ПИД) величина
управляющего воздействия ? В месе или в EMC ?

SVP писал(а):? Только для разгрузки LPT-порта ?

практически - да...
парпорт не "успевает" считывать энкодер (может только на очень маленьких скоростях, штурвал на 100 тиков например)
это основное предназначение меса...
а далее - формирование +-10V , опторазвязка IO и тд. - можно и без мессы сделать...
пид конечно работает на стороне емс (обратная связь по положению) , в отличие от возможных пи(пид) регуляторов в приводах (ну или сервах - как это все упрощенно
сейчас называют)...

SVP писал(а):Но кто его обрабатывает, чтобы осуществить PID-регулирование ?

ЕМС

SVP писал(а):Если делать это со стороны EMC2, то нафига вообще нужна меса ?

а как ты энкодеры заведешь?

SVP писал(а):Только для разгрузки LPT-порта ?

а ты попробуй через ЛПТ энкодеры протащить

SVP писал(а):Нельзя ли прямо внутри этой могучей электроники реального времени рассчитать PID и выдать его сразу же наружу без EMC ?

если прошивку свою напишешь

SVP писал(а):Еще раз сформулирую вопрос: где должны обрабатываться данные с энкодеров и генерироваться (с помощью ПИД) величина
управляющего воздействия ? В месе или в EMC ?

Выбора нет, их обрабатывает ЕМС

Мда... понятно, итого проталкиваем всё, что можно в EMC и обрабатываем там ?
Как-то печально всё это несколько.

ЗЫ. Прошивку... не, я пока не готов, это уже черезчур. Щаз разобраться бы для начала "в целом".

есть платы которые ПИД обрабатывают сами типо KFLOP но это либо под Мач либо под собственную прогу KFLOP. На ней же можно cделать closed loop

SVP писал(а):А если я проталкиваю данные от энкодеров в EMC, то получается я опять завишу от того, насколько в реальном времени этот
EMC работает, и от всех потенциальных глюков компа.

PID работает в servo-thread - т.е. около 1кГц. На этой частоте компьютеры работают гораздо стабильнее.
Когда загружаешь latency test там показывается два параметра base-thread jitter и servo-thread jitter, это фактически разброс по выполнению real-time.
Вообще, realtime - это по определению не мгновенная работа, а гарантированное выполнение в заданных временных рамках. Правильное проведение latency-test дает понятие о тех ограничениях, которые будут получены на данном компьютере для потоков realtime.
Но 100% гарантии нет, что не скакнет напряжение в сети или какой-нибудь электромагнитный импульс не вышибет что-то важное в компе.

Как-то уж больно коряво и пафосно я все это написал

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

Бывали случаи, когда комп вис, (точнее не ком, а gui) с ним было ничего не сделать кроме жесткого ребута, а EMC работал дальше по программе как ни в чем не бывало.

SVP писал(а):Как-то печально всё это несколько.

А чем печально? Не хватает скорости, или что-то глючит?

aftaev писал(а):есть платы которые ПИД обрабатывают сами типо KFLOP но это либо под Мач либо под собственную прогу KFLOP. На ней же можно cделать closed loop

А он точно на плате ПИД обрабатывает, а не на компе, где-нибудь в драйверах или в своем ПО?
Хотя, в принципе этот ПИД вроде как не шибко сложный.

Хотя с другой стороны, задание он все равно постоянно получает с компа, поэтому какая разница где пид?

Если ПИД на компе, то задание на серву меняется раз в servo-thread.
Если ПИД снаружи, то все равно задание драйверу меняется раз в servo-thread, т.к. на PID задание меняется не чаще. Будет небольшой плюс по регулированию сервы внутри серво периода, но не факт, что это как-то ощутимо скажется на системе в целом.

Nick писал(а):Хотя с другой стороны, задание он все равно постоянно получает с компа, поэтому какая разница где пид?

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

Nick писал(а):

SVP писал(а):Как-то печально всё это несколько.

А чем печально? Не хватает скорости, или что-то глючит?

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

Но нет худа без добра. Я рассчитывал, что придется 1000 раз перепрошивать месу параметрами для подбора ПИДа к примеру,
а в текущей схеме она похоже вообще plug & pray, и ничего с ней делать не надо, всё в текстовых конфигах.

Nick писал(а):А он точно на плате ПИД обрабатывает, а не на компе, где-нибудь в драйверах или в своем ПО?

Мач не умеет с обраткой работать, а КФЛОП работает и в нем в настройках задаются параметры ПИД. Мач скидывает задание как бы в буфер КФЛОП его обрабатывает.

Nick писал(а):Хотя с другой стороны, задание он все равно постоянно получает с компа, поэтому какая разница где пид?

У Кфлопа + Мач нажал паузу или стоп станок еще малость проезжает. В "задании" нету ПИДа

Nick писал(а):А он точно на плате ПИД обрабатывает, а не на компе, где-нибудь в драйверах или в своем ПО?

Просто у КФЛОП в своём МК выполняет те-же функции, что и linuxcnc на компе.

У килофлопа частота обхода сервоптли 11 кГц для каждого канала.
Задание предается не квантованными отрезками по времени, как у LinuxCNC или Mach3 а линейными участками траектории. Т.е. если нужно проехать 50 мм по прямой, то по USB будет передана одна команда.
В принципе - килофлоп может работать и автономно (это я к вопросу о расположении ПИД), но траекторию придется писать на языке Си

Собственно автор рекламирует то, что производительность килофлопа 1,2 GFLOPS (1,2 миллиарда операций с 64 битными числами с плавающей точкой в секунду), что нужно для быстрого расчета ПИД.

Пид это же вроде простой сумматор, там вроде надо 5-10 простых операций и все...
А вот траектории считать - это да, там и корни и прочая неприятная лабудень....

Nick писал(а):Пид это же вроде простой сумматор

А умножать, делить, дифференцировать и интегрировать кто будет
Понятно, что в конце концов всё сводится к элементарным операциям, только их довольно много получается.

Так дифференциируется все численно - т.е. dx/dt, и интеграл считается через сумму.
Никто не говорил, что делить не надо будет, хотя, можно и без деления обойтись и вообще сделать все в целых числах.

Nick писал(а):А вот траектории считать - это да, там и корни и прочая неприятная лабудень....

видать потому в Кфлопе DSP проц

DSP корни считает не лучше обычного процессора, он несколько в другом силён. Вот как раз PID он чуть лучше обсчитывает и сигналы умеет хорошо генерить.

Поскольку теперь по ПИД ищется исключительно эта тема, продолжу сюда.
Сходу не нашел, как настраивать.
Для теста попробовал настроить при неподключенном к станку движке.
Наблюдаю странное поведение.

При увеличении значения P f-error пропорционально УБЫВАЕТ. Я ожидал, что будет обратная картина,
либо вообще ничего меняться не будет. При некотором значении серва входит в резонанс.
При этом выглядит всё где-то так (без резонанса, если назад вернуться слегка)
График для движения по прямой в одном направлении. Поведение признаться мне немного непонятно.
Откуда такой ровный трапецивидный вид ?
Почему такая зубчатость сверху ?
Я ожидал от ошибки большей плавности, которую можно было бы ИД-компенсировать.
Куда копать ?

Пики где-то 0.02. Хочется как-то меньше.
Каковы для MAX_ACCELERATION адекватные значения ? Вроде бы зависит прямо.

Это я что, наблюдаю инерцию самого двигателя ?
Но тогда почему она при езде по прямой вылезает, а не только на старте ?

SVP писал(а):Наблюдаю странное поведение.

отнюдь

SVP писал(а):При увеличении значения P f-error пропорционально УБЫВАЕТ. Я ожидал, что будет обратная картина,

могло бы быть и наоборот - нет зависимости жесткой...

SVP писал(а):Откуда такой ровный трапецивидный вид ?

ну это же очевидно - рост ошибки на разгонах и торможениях

SVP писал(а):Почему такая зубчатость сверху ?

можно описать "почему" - но скажу лучше - можно попытаться ее сгладить...

SVP писал(а):Куда копать ?

копать в одну сторону - подбирать коэфициенты для уменьшения ошибки до требуемой
(кстати - на станке все-все придется настраивать заново)))
сейчас ошибка 0.015?

Так и должно быть, Ferror будет убывать по мере увеличения P, потом система начнет входить в колебания.

Кстати, какая это ось? Или серва пока просто лежит на столе?

Кстати. Какая амплитуда колебаний, случаем не +-1-2 тика энкодера?

Вот тут есть примеры различных ситуаций с картинками:
http://wiki.linuxcnc.org/cgi-bin/wiki.p ... Amplifiers