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

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

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

Ну как мы выяснили даже если собственоручно напишите каждый знак припинания в алгоритме на 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. Забываем ТАУ, как страшный сон... до следующего раза. Офигиваем, что задача была решена быстро и без дифуров.

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

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