Вот именно. А, что сразу не в HEX?

Нет коллеги.
Все что действительно автору нужно - это генерация нормальных сорсов тюнингированного в Matlab-e PIDа. (ADRC я пока тут выкладывать не буду )
Потому что он сейчас не может сопоставить свою реализацию PID-а с Matlab-овской.
Выглядит это так:
Тюнингируется штатный дискретный PID как я писал в самом начале.
Потом строится такая модель с тюнингированным пидом и параллельно для сравнения идентичности подсистема полностью копирующая штатный PID
Нажмите для просмотра прикрепленного файла
Подсистему сделал я. Чтобы она совпадала в штатном пиде должен быть выбран режим clamping для anti-windup.
Подсистема внутри выглядит так:
Нажмите для просмотра прикрепленного файла
И теперь автор может спокойно из Simulimk-а сгенерить сорсы на C для своего контроллера для этой подсистемы.
Он получит понятную функцию без магических matlabовских чисел, где все константы передаются как аргументы.
А константы он будет брать из полей в диалоге штатного PID-а каждый раз когда будет перетюнингировать его.

Режет без остановки по несколько часов на равные части.

Возвращаемся в самое-самое начало - зачем тебе позиционировать нож в начальное положение, если он будет всегда вращаться?Длина полотна будет определяться временем оборота ножа на 360 и скоростью полотна. Первое -ты задаешь просто частотой вращения, а второе ты влиять не можешь. За время одного оборота твоя картонка сместится на расстояние L=скорость линии*время оборота ножа. Стабилизируешь скорость - стабилизируешь длину того,что режешь.Ну хорошо -сделай опцию, чтобы перед каждой резкой нож возвращался в начальное положение по алгоритму выше- определяешь в какую сторону вращаться, даёшь небольшую скорость, чтобы не проскочить и пока энкодер на насчитает нужное число вращать, как только насчитает - стоп. Алгоритм есть выше. Оно тебе надо делать отрезной станок вертикального взлета с самонаведением?

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

А почему не получается? Привод в 0 плавает?Реза не получается?

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

Графики-то будут?
Хотелось бы увидеть реакцию на скачок 1 - 4 В, а, после установившейся скорости, скачок обратно 4 -1 В.

Будут, возможно даже сегодня.

Предложи поменять редуктор.Дело в том, что реализуемость вашего решения определяется приведенным моментом инерции.Если он большой, то резкий разгон/тормоз возможен будет, если поднять стопорный ток в приводе-это не есть хорошо для непрерывно работающего двигатель.А редуктор уменьшит и момент инерции, и нагрузку на двигатель. С вашими 4:1, приведенный момент инерции уменьшен в 16 раз и нагрузка на двигатель в 4 раза.Если сделаете 5:1, момент инерции уменьшится в 25 раз.Как влияет инерция на разгон смотрите выше в картинках.Изготовить редуктор-дорогое удовольствие, могут послать.Надо тогда предупредить, что по другому может не сработать, подведите их к станку, дайте Макс.задание скорости и обратите внимание на время разгона.Пусть сами увидят возможности двигателя.
---
Или наоборот, надо увеличить момент инерции на выходе редуктора/изменить конструкцию ножа и пр.Это проблема не электропривода-это проблема механиков и технологов.22кВт разогнать за 0.1 сек даже не обсуждается, редуктор быстро умрет.Можно извращаться над станком, но хорошего изделия не получится

Щас они разбежались менять..
Редуктор у ТС как раз 5:1 - читать надо внимательней.
Пуска ступенькой не будет в нормальных режимах.
ТС разгоняет привод осторожно с постоянным (почти ) ускорением.
Кроме того, он делал замеры, вроде подтверждающие, что проскальзывания нет.
Переходные процессы на ступеньку нужны в тестовом режиме для примерного понимания работы штатного регулятора.

И к тому же сейчас стоит контроллер, старый и в единственном экземпляре, без нужного на сегодня функционала.
И он справляется с задачей точного реза.
Я собственно его заменяю. Я знаю, что железо станка умеет то, что мне нужно.

Если разгоняется с постоянным ускорением-значит идет разгон на стопорах и момент инерции все таки приличный.При торможении 0.4 секунды увеличьте стопор в двое-будет 0.2 секунды, а заказчикам предложите купить сразу новый двигатель (через месяца 3 понадобится) и новый редуктор

Я не буду тормозить за 0.4с, буду равнозамедленно. Этот параметр тоже задаётся, как и ускорение.
0.4с - это снятая характеристика. Меня просили - я снял. Но это не является рабочим режимом.

У вас есть токовые клещи? Какой ток в якоре при торможении? Это такой самый толстый провод, который с борнухи идет в преобразователь. Я поясню о чём идет речь. Если вы читали сообщения выше, то время разгона/торможения, которая в опции привода приводится - это постоянные времени задатчика интенсивности, потому что всю динамику задает он. Но если начнет работать подчиненный контур тока, то динамику будет определять контур тока. Зачем я все это говорю - для равнозамедленного движения вам придется отключить задатчик интенсивности в 0.0000001 на разгон и торможение и делать его у себя в контроллере - это норм. НО надо убедиться, что разгон/торможение будут идти без стопоров. Это все легко проверить : токовыми клещами измерить ток при разгоне/торможении без резов. Нет клещей - можно грубее: ставьте 1 сек тормоз и засекайте -отработает 1 сек? Если да, то 0.5 сек и так же проверяете. Но я вас сразу предупреждаю, что торможение/разгон 0.1 сек для такой мощности не проканает 70%. Там может проявится люфт/звон/минимальная постоянная времени привода и пр.,

Это обнадеживающее заявление. Значит Ваша задача имеет решение. Более того, оно существует "в живую" рядом с Вами.
Я бы, на Вашем месте, пока подождал с собственными экспериментами, а сосредоточился на изучении существующего решения.
Как минимум, доступ к энкодерам у Вас есть. То есть, можно снять практически полную картину, как все это работает.
"Разбор полетов" уже заведомо правильно работающего устройства, на данном этапе, даст Вам много больше информации,
чем углубление в теорию или собственные эксперименты.

Кстати, с какого напряжения управления шло торможение? Те же 1.5 В?

А на что заменяете? На чем сделан ваш контроллер?
Сами его сделали или нечто покупное?
Какая у него производительность?
Может он действительно может решать оптимизационые задачи в реальном времени и в него можно грузить прямо из Simulink-а .exe файлы

Как работает изучено. Так же, как я описал в первых постах.

По алгоритму работу у меня вопросов и не было.


Да, если не путаю. Картинку не сохранил.


Сами.

Производительность? Смотря по какому параметру измерять.
В реальном времени может делать все обсчёты, касаемые траектории, времени простоя, скорости, до которой ножу надо изменить скорость.

Из Симулинка брать .exe файлы? Не слышал даже про такое.))

Контроллер не претендует на готовое к выпуску коммерческое изделие, где просчитана стоимость каждого резистора.
Если я скажу на чём он сделан у ряда местных может случиться приступ.

Еще вопрос. Как я понял, у Вас есть возможность снятия дистанции с обоих энкодеров - двигателя и транспорта?
Для транспорта Вы вроде тоже собираетесь свою САУ делать?
Надо, чтобы была возможность получения значений обоих энкодеров на САУ главным приводом (нож).

Да.

Там пока туманно, но, как минимум, будет дублирование управления скоростью с физической кнопки на АРМ оператора, в ПК, через, как раз, контроллер.

Это сейчас есть. Как я иначе скорость линии узнаю..

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

Возможно. Вопросы были про ТАУ, в целом, и про PID, в частности.
Этого я из работы старого контроллера и показаний энкодеров, мне кажется, не пойму. Я вижу, что PID работает. Но вопрос был про настройку.
Я снял характеристики аналогового управления: измерил скорость нарастания напряжения, измерил зависимость Вольт/Скорость.
Ускорения принял за рабочие и выше них в своём контроллере не применяю.

Есть еще вариант - перед резом дать полное задание скорости приводу по энкодеру импульсно. Логика такая:
если показания энкодера >=число1 (где надо начать ускорять нож), то дать максимальное задание
если показание энкодера>=число2 (после реза), то снять максимальное задание и тормознуть, пока скорость не сравняется а нормальным заданием, ну или сделать выдержку времени на торможение
Дальше варьируйте, вариантов миллион
И первое, и второе числа подбирать подбирать при наладке. Так же - предельно просто и понятно и,самое главное, не надо никаких экспериментов - если не будет работать, то другие решения без замены редуктора не заработают никогда, потому что вы даёте ему максимум задания перед резом и снимаете максимально быстро после реза. Механика вам спасибо не скажет, но рез будет моментальный и инерция его задемпфирует. Вариант, когда используется максимум возможности привода. Такое решение вас устроит? Чтобы было попонятнее - в теории управления есть раздел, посвященный оптимальному управлению. Там доказывается теорема, по которой оптимальным по быстродействию управлением линейным объектом является релейное управление. Оно не оптимально в плане возникающих при таком управлении потерь, но по быстродействию нет ничего быстрее. То, что я вам предлагаю и есть релейное управление. И если вы регулятор в максимум -максимум-максимума настроете, у вас получится тоже реле (там просто итегратор в насыщение уйдёт моментально). Получается хитрый релейный регулятор положения

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

Нож - это ракета. САУ главным приводом - это САУ ракетой.
Цель - это виртуальная линия реза материала.
Ракета и цель двигаются по одной и той же прямой навстречу друг другу, т.е. одномерный случай перехвата.
(то, что в реальности нож двигается по окружности - ничего не меняет, мы виртуально распрямляем окружность).

Рассмотрим случай, когда ракета ждет цель.
Ракета имеет известные энергетические ограничения (допустимое ускорение) и рейсовые ограничения (типовое ускорение на маршруте).
Ракета обязана встретить цель в точке O на дистанции D от места старта и иметь скорость Vr.
Максимальное значение Dmax - это окружность реза.
Точка O - это место реза.
Ракета следит за целью (по энкодеру цели + свой энкодер) и, как только цель оказывается в зоне энергетической доступности ракеты, производится пуск.
Движение ракеты производится с заданными ограничениями на ускорение.
Управление движением ракеты производится на основании текущей дистанции между ракетой и целью (уменьшающаяся сумма двух энкодеров), при этом скорость движения цели может меняться.
Цель терминального управления - обеспечить приход ракеты в точку O одномоментно с целью и иметь скорость Vr.
Аналитический синтез управления осуществляется с учетом динамических качеств ракеты (привод ножа и САУ) и энергетических ограничений.
Для систем 2-3 порядка это делается "карандашом".
Более того, даже неточное знание динамики ракеты (привод ножа и САУ), позволяют корректировать траекторию движения, поскольку это делается на каждом шаге timestep.

Это на пальцах, чтобы Вам стал понятен принцип терминального управления.


В случае ТС это бессмысленно, поскольку у него нет энкодера на ноже и при релейном старте точно пойдет скольжение.
Вы же сами предупреждали, а теперь советуете

Зачем энкодер на ноже, если есть энкодер на двигателе

Что-то странное предлагаете. Кинетическая энергия останется такой же.

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

P.S.
Если уж и советовать по редуктору, то это переход на современные зубчатые шкивы и ремни.
Только сдается мне, ТС и слушать там никто не будет.

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

Значит Arduino.
Хотя я ничего позорного в этом не вижу. У нас в цеху каждый второй что-то ваяет на ардуино. Такая мода нынче.

Правда вы сильно ограничены в средствах отладки тогда.
Кодогенерация из Simulink вам тоже не подойдет. А вот это уже сильнейший минус.
Боюсь я тогда вам здесь не помогу.

Т.е. редуктор купить-денег жалка, а лицензия на матлаб с тулбоксами - норм?) Это же дороже на порядка 2 ^_^
---
Это нормально, если задача одноразовая. С разводкой платы, пайкой ваше изделие по себестоимости будет дороже и дольше

А зачем что-то смещать... Ведь с этим редуктором все нормально работает.

Нормальное решение для начинающих, для штучных партий, для супервизорного управления.

Хотя нет, не прав.
Посмотрел есть таки BSP для Arduino.

Нет, но в угадайку мы играть не будем.


Не нужна мне кодогенерация.

Матлаб не будет использоваться, я временно им пользуюсь.

И это правильно.
Надо все делать своими руками и мозгами + аккуратное использование инструментария.

P.S.
Возвращаемся к энергетике ( на основании единственного предоставленного Вами графика ):
Рассматриваем два способа выхода в конечную точку:
- по step;
- по ramp.

Считаем step-выход за максимально доступный по энергетике.
Приравниваем к нему ramp-выход и смотрим на фазовые координаты.
Вывод:
Чтобы достичь за минимально доступное время step-разгона 0.727 сек координаты 0.9 м - необходимо:
- при step-управлении выйти на скорость 80 м/мин;
- при ramp-управлении выйти на скорость 160 м/мин.

Из этого следует, что если мы ограничиваем ускорение из условия достижения скорости 80 м/мин на дистанции 0.9 м, то при ramp-управлении время выхода в точку составит около 2*0.727 = 1.5 сек.
Нажмите для просмотра прикрепленного файла

Значит другая крайность - Raspberry Pi или встраиваемая PC плата.
И управляющая программа на PHP.
Это тоже терпимо, тут некоторые целый умный дом на PHP и JavaScript программируют.
Так что не вижу поводов вам стесняться.

Но если воспользуетесь тюнингом Mаtlab-а, то учтите, что он свой тюнинг делает под свою структуру PID-а.
А его структура несколько отличается от кочующих по инетам реализаций.
И подставив коэффициенты из Mаtlab-а в свой алгоритм вы не получите то что было в модели.


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

Правильный СИФУ должен все учитывать (возмущения по нагрузке, сети и т.п.), а немцы - "правильные мальчики"
То, что там турецкий двигатель - не принципиально.



i8080, i8085 или 51-е

Я не верю в существование разработчиков застрявших на хардварных платформах прошлого века и одновременно способных строить современные GUI.
Скриншот автора скорее свидетельствует о применении пакета типа RLPlot и QT4 под Raspberry.
Вполне возможно что Raspberry был применен в паре с Arduino.

А вы, я так вижу, пользуетесь какой-то устаревшей версией VisSim 20-и летней давности.

Картинка из матлаба )). Далее всё будет в вэбе, никаких QT.
Думаю, будет php + БД, куда сложу всё через modbus tcp, но пока протокол чисто tcp/ip, внутри которого отсебятина.

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

Т.е. какой-то KIT на FPGA с линуксом? А Matlab только ради GUI?

FPGA - да, только голый. Ethernet при помощи wiznet чипа.
Матлаб для отработки алгоритма, для GUI. Потом его не будет. Хотел использовать System Generator в начале, но позже понял, что тут его и негде особо использовать, прошивка простая и так.

А микроконтроллер Wiznet-овский или в FPGA встроен?

Версия 5.11 - быстрая и легкая, много наработок.
Есть Solidthinking Embed 2017 (это дальнейшее развитие Vissim).

Итак, вот модель PID контроллера подготовленная к кодогенерации для ARM Cortex-M

Нажмите для просмотра прикрепленного файла
По модели генерируется код который не использует нигде магические константы типа периода сэмплирования и проч.
Все констаны задается явно во входной шине Pars (она же структура Pars в исходниках на C-и)
Явно задается и константа периода сэмплирования.
Модель представляет параллельную архитектуру PID-а, с клампингом и ограничениями на размах выходного сигнала.
Везде тип данных float. На 120 МГц Cortex-M4 с сопроцессором такой PID выполнится за пару микросекунд.
Загрузочный файл - PID_model.slx

AlexandrY
Вопрос по ограничителю скорости роста выходного сигнала. На "ступеньку" откликается "ступенькой". Что же он ограничивает ?

3288 тактов, если быть точнее, на Cortex-M4 с float point сопроцессором.
Т.е. на 48 МГц Cortex-M0 без сопроцессора будет где-то 300 мкс


Он следит чтобы при переносе этого PID-а на реальный объект всё не пошло бы в разнос.

Скажем у вас люфт. Это элемент задержки плюс неправильный отклик.
Люфт из любого хорошего PID-а сделает осциллятор.
Чтоб бороться с люфтом придумывают всякие эвристические алгоритмы на старте управления.
И вот пока вы их не настроили у PID-а надо включать ограничение на скорость.

Чем это ограничение отличается от обычного saturation - в чем фишка ?

saturation может скакать от max до min каждый период и получится такая жёсткая болтанка.
Если уменьшите max и min то болтанка все равно останется.
А ограничение скорости просто сделает плавную пилу если управление уйдет в осцилляцию, а чаще даже осцилляция пропадает.

Простите, но не могу увидеть ограничение скорости. Взял из модели модуль ограничения скорости. При входном сигнале с амплитудой в пределах границ saturation с частотами 5Гц, 10Гц, 15 Гц выходной сигнал абсолютно совпадает с входным сигналом.
Что то не так делаю ?