В этом и заключается философия 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 - плохая.

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

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

Сообщение отредактировал AlexeyW - Jul 20 2014, 19:22

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

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

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






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

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

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

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

Сообщение отредактировал AlexeyW - Jul 21 2014, 21:11

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