Simulink ? Или что-то другое ?

Дополню, чтобы было яснее. Читаю теорию и хочу немного попрактиковаться. Итак, задание - поддерживать обороты коллекторного моторчика. Три регулятора - П, ПИ и ПИД, соответственно имеем три маленьких исследовательских задачи.
Собрал макет - на дощечке укрепил коллекторный моторчик на 12В. Через резиновый ремешок он приводит в движение тахогенератор (обычный моторчик от CD-ROM'а). И еще, через такой же ремешок он приводит в движение второй моторчик от CD-ROM'а, который работает в генераторном режиме, нагружен на переменный проволочный резистор и служит нагрузкой, изменяя которую, можно подгружать или разгружать приводящий в движение всю эту систему моторчик на 12В.
Дальше я хочу экспериментально снять характеристики этого макета, ввести их в программу моделирования и смоделировать интересующие меня регуляторы ...

Берете Ваш любимый симулятор для электронных схем, заменяете мотор конденсатором, добавляете резисторы и пр...
http://electronix.ru/forum/index.php?s=&am...t&p=1257043

ИМХО, все-таки проще Симулинком. И прозрачнее... И оптимизатор подключить можно, который все параметры ПИД регуляторов легко просчитает.

Что удобнее/понятнее/доступнее/интереснее и т.п.

Для меня в свое время оказался интереснее VisSim, а также отечественный MVTU ( теперь он - SimInTech )

В VB

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

Я бы даже не брался за исследование такого макета.

В лучшем случае люди обучают поведению таких систем определенные топологии нейросетей.
Потом эти обученые нейросети используют как модели объекта при разработке алгоритмов управления.

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

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

Советую еще поставить стабилизатор тока мотора, управляемый Вашим регулятором. Что-нибудь такое - интегратор с двумя входами. На один - выход регулятора, на другой - сигнал с шунта. Почти бесплатно получится сделать этот интегратор на последнем суммирующем компоненты П, И и Д ОУ.

Набросал для Вас пример функц. схемы электропривода с двухмассовой системой нагрузки ( связь задается коэф. диссипации Kd и коэф. жесткости Kg)
W1 - скорость двигателя, W2 - скорость нагрузки.
К валу двигателя и к нагрузке приложены статические моменты сопротивления M1 и M2, соответственно.
Регуляторов здесь никаких нет! Прямой пуск.

Схема 1 - связь жесткая и с большой диссипацией.
Нажмите для просмотра прикрепленного файла

Схема 1 - связь мягкая и небольшая диссипация.
Нажмите для просмотра прикрепленного файла

Для не слишком сложных систем вполне можно и спайсом моделировать.
Пример:
Нажмите для просмотра прикрепленного файла

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

Можно и в OpenModelica попрактиковаться. Вполне достойная штука, много примеров, хорошая справочная система.

Это самый лучший подход - писать моделирование самому.

И многие могут это сделать профессионально, Вы считаете?

"Не смешите мои тапочки" (С)

В этом и заключается философия MATLABа в области Model Based Design в настоящий момент - рисуете в симулинке модель объекта управления. Хотите - электрическую, хотите - механическую или гидравлику. Рисуете там же ваш регулятор. Моделируете, пока все не запашет. Добавляете хардварные особенности, типа задержи выборки АЦП, реальный шаг вычисления алгоритма, проверяете, чтобы все продолжало работать.
Потом генерите Си код из регулятора и впихиваете его в контроллер.

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

Студенческой штучкой Матлаб/Симулинк был давно. Счас с такими вещами уже не играются, а реально работают, так как денег экономит не мало.
Серьезных проектов в настоящее время уже дофига и больше.
http://www.mathworks.de/company/user_stori...evelopment.html
http://www.mathworks.de/company/user_stori...Controller.html
Ну и еще сотня других крупняков, включая NASA, Airbus, Toyota и т.д, причем реально работающие проекты http://www.mathworks.de/company/user_stori...pplication.html раздел Embedded Systems

А вы думали матлаб способен только Лего да ардуино с распбери управлять?

А что означает слово "профессионально" в наше время?
Я сам никогда на программиста не учился, по вусем понятиям являюсь ламером, пишу на VB.
Однако, когда столкнулся с тем, что реально профессиональная программа для моделирования фильтров оказалась совершенно неадекватна задаче, написал моделирование сам за две недели, и мы все отлично смоделировали и потом реализовали. Тут главное не бояться
Другой вопрос - а многие ли смогут профессионально смоделировать и при наличии среды? Только кажется, что проще, ведь понимания-то может и не быть.
Самостоятельно писание позволяет именно понять суть процесса, это самое важное, как мне кажется. Поставленная здесь задача - ТАУ - вроде как раз очень адекватна для собственного написания.

Перечитайте еще раз что написали.

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

На самом деле вопрост в исследовании и инструментах для него.

Не совсем понял про черный ящик. Любой объект в какой-то мере им является.
ТС хочет снять численные характеристики объектов, математическая сущность поведения которых, как я понимаю, ему известна. А если известна недостаточно хорошо - именно собственное написание и позволит разобраться.
Если довести мысль до логического предела: вот есть некая система, поведение которой нам нужно понять. Мы моделируем поведение системы в некой программной среде, которая учитывает все. Ну, например выполняет дискретные вычисления по уравнениям Максвелла и т.п. Результаты моделирования верные, совпадают с реальностью. Получили ли мы при помощи такого моделирования понимание работы системы? Вряд ли. А собственное писание программы - это редуцирование системы, с выделением главного и отбрасыванием второстепенного. Да, для сложных систем уже нерационально и малореально, но для приведенной в вопросе - в самый раз.

Т.е. уравнения Максвелла для вас всё.
Ну тогда приведите или хотябы намекните как задачу TC привести к уравнениям Максвелла.

Вопрос можно и нужно ли такие системы описывать уравнениями.

Кстати, тоже сейчас занимаюсь ременными передачами. У них оказывается коэфициент передачи-то скользящий. Зависит от нагрузки.
Уравнения Максвела отдыхают. Линейные модели тоже.

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

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


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

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

Что значит "все"? Все не так очевидно.
Matlab как раз и приближает нас к точке "Я знаю, что ничего не знаю"

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

Но! В Matlab-Simulink вы можете просмотреть всю историю каждого сигнала, его статистику с максимумами, минимумами, девиациями и проч.
Построить график по любому сигналу, наложить графики и проч. Все простым редактированием связей, без единой строчки кода и компиляций.
Т.е. отладка модели просто молниеносная.

И тогда возникает сомнение можете ли вы знать про модель все если ограничены в средствах наблюдения за ее внутренними сигналами, когда пишите просто на C-и.
Не напишете же ва сами такую интерактивную среду как Matlab.

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

Конечно, абсолютно согласен с Вами. Вообще, Матлаб - это действительно не симулятор, а другое.
Но, Вы совершенно справедливо сказали - заложенная в него сложность является препятствием для быстрой реализации простых моделей. Лично у меня был случай, когда человек попросил меня реализовать в написанной мной оболочке одну задачу (сейсмическую, вообще не из моей сферы), и все получилось хорошо и быстро. С Матлабом он работает, но сказал, что там реализовывать слишком сложно.
Ведь в чужих средах часто есть еще одно немалое препятствие - неумение программистов правильно поставить задачу, в том числе по реализации интерфейса. В итоге, например, некие функции в проге формально есть, а реально ими очень трудно пользоваться. Как пример: PCAD-2004 есть очень хорошая реализация интерфейса (хотя не без претензий), AutoCad - плохая.

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

Что-то типа такого (это реализация совсем простой модели с пятью переменными, а можно хоть сотню):

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

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

Нельзя, тут лукавите.
Насколько видно из скриншота, там нет элементарного менеджмента сигналов и переменных.
Сто графиков на одном поле будет ничитаемое месиво.
Графиками надо управлять: cепарировать по горизонтали и вертикали, делать свои оси, ставить метки, делать курсоры, апроксимировать, накладывать, делать взаимные преобразования, извлекать статистику, экспортировать и т.д. и т.п.
Это все уже написано в вашей модели?






Это какой-то алогизм. Зачем вам вообще модель если вы уже знаете ее поведение?

Из пары операторов xor, обратных связей и задержек можно сделать такую модель поведение которой нобелевские лауреаты не предскажут.

Более половины того, что Вы написали, есть. Но я писал не продукт на продажу на все случаи жизни. Импорт, экспорт, курсор, много прочего - не вопрос. Если приглядитесь - это про сто "виртуальный осциллограф", можете сдвигать и масштабировать, как хотите. Я сам сопрягал это с потоком данных с осциллографа, например. Или вставлял туда движки для оперативного управления переменными.
И здесь пример самой простейшей модели. Я еще раз повторюсь - ТС спросил "в чем посоветуете моделировать НЕСЛОЖНЫЕ модели".
Главное - любую из перечисленных Вами функций я легко туда добавлю, если надо. Важнее вопрос, надо ли впихнуть в одну прогу все и погрязнуть в ней.

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

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

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

Вот очень старый опыт графического задания гистерезиса и параметров насыщающегося дросселя

Ну как мы выяснили даже если собственоручно напишите каждый знак припинания в алгоритме на C-и для вашей модели эта модель не станет яснее.
Так зачем ее писать самому? Чтобы знать как написать ее на C-и?
Не пытаетесь ли вы подменить цели под предлогом своего частного неудачного опыта со сторонним софтом?
Для фильтров я вообще не знаю ничего лучше Simulink-а.

Про Симулинк оно действительно есть, про Матлаб я понимаю примерно так, как Вы и сказали. Да, конечно, это мощные инструмент.


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

Ну так и замечательно. Мы просто делимся советами. Вы советуете Симулинк, я абсолютно принимаю этот совет (попробую при случае), я советую подход "написать самому" как тоже вполне успешный. Пусть ТС сам выберет, что больше по душе.

Кстати, советую перейти на Delphi и компоненты от Steema Software и DevExpress для своих приложений.
Кардинально облегчите себе выравнивание гаджетов в окнах, разнообразите их, придадите современный стиль и еще на мобильные дивайсы сможете перенести.
А графики по функциолнальностьи станут круче чем в Matlab.



Что вы, извините, редуцируете если модель это и есть редуцированное представление, взятое из сторонних источников как правило.
Или вы сами открываете законы механики заново и сами придумываете апериодические звенья?
Модель надо не редуцировать, а видоизменять, экспериментировать с ней. В результате экспериментов модель может и увеличиться и уменьшиться.

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

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

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

Поэтому даже тот же маталаб предлагает применять разные движки для разных моделей. Например Simulink - контроль. Stateflow - моделирование автоматов состояний. Simscape - физические процессы, при том SimPowerSystems - силовая электроника и электрика. Другие симуляторы включают другие движки - тот же Simplorer умеет хорошо 2D-термодинамику делать. Maxwell - FEM и т.д. И из этого вытекает, что


Это ессно зависит еще от того, какой движек выбрать. С одним это легко моделируется, с другим - это невозможно.

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

Дискуссия уперлась в то, что Simulink сравнивается с неким абстрактным C-и. Т.е. конкретный интструмент с абстракцией. Если на то пошло, то сам Simulink написан на C-и.
Я конечно знаю, что средств писать на С-и не так уж много: MS Visual Studio, да C++ Builder.
Но мы тут притворяемся что на C-и пишется в вакууме и не догадываемся о каких библиотеках и ограничениях может идти речь.
Вот и интересно насколько можно поддерживать аргументацию за C-и так и не назвав конкретные инструменты. С тем же успехом можно продвигать ассемблер.

Moderator: Посты скрыл, тон дискуссии настоятельно прошу не накалять. Предупреждение пока устное.

Отличительные особенности компьютерного симулятора физических (в частном случае электрических) процессов: 1. Модель часов (т.е. понятие времени) 2. Модель параллельно протекающих процессов.

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

Simulink и Spice изначально этими свойствами обладают, т.е. из коробки предоставляют этот уровень абстракции, т.е. если например вы подключили в симуляторе RC-цепочку к гидравлическому цилиндру посредством клиноременной передачи, то при подаче воздействий вы в моделируемом времени увидите то же поведение, что и в реальной жизни с точностью до учтенных в модели эффектов. Как будет описана модель и/или ее составные части: диф. уравнениями, передаточными функциями, пространством состояний, схемой, аналогиями или как-то еще - совершенно не важно.

Ни с++, ни машинные коды этими свойствами изначально не обладают.

Сложная какая-то дискуссия для меня получилась, я еще до таких высоких материй не дорос.
А дорос вот до чего. На ATMEGA8 сделал простые П - и ПИ - регуляторы, управляющие нагревателем. Нагреватель - обычная стоваттная лампочка, мощность в которой регулируется с дискретностью в один процент путем пропуска соотв. количества полупериодов питающей сети. В качестве ключа использован симистор. Датчик - обычный DS18b20. Он прижат к лампочке жесткой резинкой.
Все работает. Как и ожидалось, П-регулятор не может свести к нулю рассогласование между заданным значением температуры и реально существующим значением. С увеличением коэффициента усиления регулятора разность уменьшается, но никогда не достигает нуля.
Поэтому я сделал ПИ - регулятор. Проблема с рассогласованием решилась, зато появилось перерегулирование, и с этим нужно бороться, а это очень непросто. Например, я довольно быстро подобрал коэффициенты усиления так, чтобы перерегулирование не превышало 5%. Вроде бы, неплохо, но хочется еще лучше. А вот здесь возникают проблемы. При увеличении коэфф. усиления интегратора увеличивается перерегулирование. При уменьшении оно уменьшается, но недопустимо затягивается переходный процесс. После примерно однодневного подбора коэффициентов я сделал вывод, что теория права - регулятор нужно расчетным путем подгонять под объект. Вот здесь есть интересная статья. Там, правда, написано про электромотор, а не про нагреватель:

http://www.dynsoft.ru/PID.php

Аналогичной статьи про нагреватель я пока не нашел. Посему я пока отложу нагреватель в сторонку и вернусь к собранному и лежащему в шкафу стенду с моторчиком ...

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

Так абсолютно любой нагреватель со спиралью обладает таким качеством. Или я не прав ?

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

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





В правльном направлении идете.
Еще с пару десятков таких эвристических правил и у вас получится классическое управление методом fuzzy logic.

нет никакого угла, я полупериоды пропускаю. в секунде 100 полупериодов. Если пропустить один полупериод, в нагрузку уйдет 1% от возможной энергии, если 5 полупериодов - 5%. если же пропустить 100 полупериодов, то нагрузка получит полную мощность.

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

Я далек от ТАУ, но знаю симулинк. Поэтому предлагаю забыть предыдущие 3 страницы и решить задачу в лоб. Лампочка и датчик температуры - классический пример объекта управления с инерционностью.

1. Поэтому открываем матлаб и Control Design Examples и изучаем примеры Automatic PID tuning. Например Design a PID Controller Using Simulated I/O Data
2. На 5-ый день понимаем, что надо оптимизировать в случае лампочки с датчиком температуры и какие параметры объекта управления нужно знать
3. Экспериментально снимаем характеристики нашей системы лампочка - ДТ. Если я не ошибаюсь, надо просто с холодного состояния включать лампочку на 25%, 50%, 75%, 100% мощности и мерять датчиком температуру, пока она не выйдет на стабильный уровень. Определите тау, нелинейность и еще кучу параметров. Еще пара экспериментов и все, что нужно известно
4. Лепим в симулинке свою модель контроллера с лампочкой и загоняем туда измеренные параметры. Любуемся перерегулированием и переходными процессами а-ля реальность, при том, что 10 минут реального времени будут моделироваться за пару секунд. Офигиваем от того, сколько времени сэкономили, не сидя у макета и ждя, пока оно нагреется.
5. Запускаем optimization wizard и офигиваем еще раз от чудесным образом подсчитанных коэфициентов ПИД регулятора.
6. Проверяем в реальной жизни и офигиваем в 3-ий раз, что оно работает на практике.
7. Забываем ТАУ, как страшный сон... до следующего раза. Офигиваем, что задача была решена быстро и без дифуров.

Результаты можете выложить сюда.

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

Так вы одобряете мой метод - не интегрировать большие невязки ? Как я понял, да

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

Дискретное управление все портит.
Тем более если дискретизировать целыми периодами.
Частота управляющих воздействий приближается к временному масштабу регулирования. ПИД по моему здесь отдыхает.

Давайте уж сами обучайте спинной мозг. Это очень полезно обоим. Я вот иногда просто на глаз отгадываю нужные параметры регулятора им(?). Просто гляжу на устройство, а вижу их.

Не стоит недооценивать тау и переоценивать возможности инструментария.

Немного усложняем задачу:
1. Греть нужно не просто датчик, а например бульон, состав которого известен весьма приблизительно.
2. Он течет и/или меняется его состав по ходу подогрева

Объем экспериментов и данных на этапе характеризации возрастет в разы. Появляются лишние датчики.