Наткнулся на интересную программку от MIT, она пока еще на шару лежит на их сайте Tools
Дизайн вводится либо графическим либо текстом (С++) далее CppSim конвертирует в С++ код, компилирует и производит симуляцию. Далее результаты конвертируются и отображаются в МАТЛАБЕ.
Авторы утверждают что работает быстрее. Очень интересен пример сигма-делта модулятора.
ИМХО, очень интересная и полезная программка и при этом хорошо написана.
Кому интересно, давайте обсуждать.
Полная версия этой страницы: CppSim! алтернатива Simullinka; быстрее? удобнее?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Вопросы системного уровня проектирования
Ну во первых SIMULINK тоже может конвертировать свои модели в C а потом скомпилить, это у него называеться акселератор.
Профайлер в SIMULINK мощнейший.
Анализатор моделей на предмет ошибок тоже имеется.
Потом в SIMULINK столько готовых блоков и ToolBox-ов, что с ним никто тягаться не сможет.
И наконец на мой взгляд графика в SIMULINK и в MATLAB в целом отстойная и не стремиться исправляться, приходиться пользоваться внешним просмотрщиком графиков на базе TeeChart, а потому конвертирование результатов в графики MATLAB это скорее недостаток чем достоинство.
Профайлер в SIMULINK мощнейший.
Анализатор моделей на предмет ошибок тоже имеется.
Потом в SIMULINK столько готовых блоков и ToolBox-ов, что с ним никто тягаться не сможет.
И наконец на мой взгляд графика в SIMULINK и в MATLAB в целом отстойная и не стремиться исправляться, приходиться пользоваться внешним просмотрщиком графиков на базе TeeChart, а потому конвертирование результатов в графики MATLAB это скорее недостаток чем достоинство.
В мануале на CppSim подробно изложены все достоинства и недостатки возможных видов симуляции. Приведу лиш выдержки из этого описания.
Библиотека моделей для симуллинка возможно и большая но неуклюжая. Если необходимо указать поведения модели в виде цикла возникают проблемы с быстродействием. Так же под вопросом стоит создание новых моделей своих устройств. Например, у меня есть проблема, симуллинк не понимает j-мнимую единицу, необходимо для комплексных фильтров.
При необходимости в CppSim можно создать любую модель из уже имеющихся или описать объектно на C++
Так же насколько я себе представляю, симуллинк может скомпилить в С но при этом он будит использовать библиотеки МАТЛАБА, у меня здесь тоже возникают вопросы к быстродействию. Например, надо было просимулировать поведение большой сети электропередач, у матлаба эта работа заняла трое суток. Та же модель на С++ заняла около шести часов.
В дополнение язык матлаба не является ограниченным по сравнению с С++.
CppSim, представляет более гибкую среду для поведенческого проектирования. Представляя пользователю возможность не вглублятся програмирование на С++ а задавать модели в графическом режиме, при необходимости возможно корректирование модели вручную. А графику выводит в матлаб по причине совместимости, я думаю что результаты симуляции могут быть выведены куда угодно из CppSim.
В общем MIT порожняк не гонит, советую посмотреть ближе не достоинства и недостатки CppSimа.
Библиотека моделей для симуллинка возможно и большая но неуклюжая. Если необходимо указать поведения модели в виде цикла возникают проблемы с быстродействием. Так же под вопросом стоит создание новых моделей своих устройств. Например, у меня есть проблема, симуллинк не понимает j-мнимую единицу, необходимо для комплексных фильтров.
При необходимости в CppSim можно создать любую модель из уже имеющихся или описать объектно на C++
Так же насколько я себе представляю, симуллинк может скомпилить в С но при этом он будит использовать библиотеки МАТЛАБА, у меня здесь тоже возникают вопросы к быстродействию. Например, надо было просимулировать поведение большой сети электропередач, у матлаба эта работа заняла трое суток. Та же модель на С++ заняла около шести часов.
В дополнение язык матлаба не является ограниченным по сравнению с С++.
CppSim, представляет более гибкую среду для поведенческого проектирования. Представляя пользователю возможность не вглублятся програмирование на С++ а задавать модели в графическом режиме, при необходимости возможно корректирование модели вручную. А графику выводит в матлаб по причине совместимости, я думаю что результаты симуляции могут быть выведены куда угодно из CppSim.
В общем MIT порожняк не гонит, советую посмотреть ближе не достоинства и недостатки CppSimа.
Цитата(monya @ Mar 28 2005, 15:41)
Библиотека моделей для симуллинка возможно и большая но неуклюжая. Если необходимо указать поведения модели в виде цикла возникают проблемы с быстродействием. Так же под вопросом стоит создание новых моделей своих устройств. Например, у меня есть проблема, симуллинк не понимает j-мнимую единицу, необходимо для комплексных фильтров.
При необходимости в CppSim можно создать любую модель из уже имеющихся или описать объектно на C++
При необходимости в CppSim можно создать любую модель из уже имеющихся или описать объектно на C++
Спасибо за ссылку обязательно посмотрю.
Про неуклюжесть Simulinka это общеизвестный факт заливать 600 метров на диск и десятки тысяч файлов для моделирования системы даже из 1000 блоков просто не логично.
Но лично я как в институте познакомился с нашим комплексом МВТУ, так Simulink удалил. Для моделирования реально сложных объектов лучше го комплекса сейчас в мире нет.
Скачать можно отсюда:
http://energy.power.bmstu.ru/mvtu/
В прошлом году у них язык программирования встроенный появился так теперь вообще все, что движется можно отмоделировать. Например, нечеткая логика делается на раз:
Здесь описания как регулятор на нечетко логике делать, сразу предупреждаю это нецензурный вариант:
http://www.reactors.narod.ru/mvtu/mbtu_lab...gic_content.htm
цензурный вариант здесь:
http://www.reactors.narod.ru/mvtu/mbtu_lab...gic_content.htm
Еще раз о неуклюжести связки MatLab и Simulink
В приложенном архиве два примера сравнения Simulink и МВТУ.
Решается две простые, но жестки системы уравненией.
Настройки решателя анологичны. Простой метод Эйлера с фиксированным шагом.
Другими словами обе программы делают абсолютно одинаковый объем вычислений.
Для чистоты эксперимента удалены графические окна. Получается прямое чистое сравнение решателей. Simulink при первом старте моделирования создает код Си и компилирует dll. В процессе моделирования используется dll.
Разница в скорости вычислений составляет:
Simulink 25 сек. МВТУ 3-4 сек. Как говорится разница более чем в 5 раз.
Поскольку сами уравнения просты до безобразия, маловероятно, что в обоих примерах MatLab генерирует неоптимальный код Си.
Выводы
1 Simulink в связке с MatLab тормозит.
2 Скорость расчета моделей написанных на Си изрядно преувеличена, и кажется большой только при сравнении с Васиком или Java скрип.
Паровоз кажется скоростным видом транспорта только по сравнению с телегой.
Пора пересаживаться в самолет.
В приложенном архиве два примера сравнения Simulink и МВТУ.
Решается две простые, но жестки системы уравненией.
Настройки решателя анологичны. Простой метод Эйлера с фиксированным шагом.
Другими словами обе программы делают абсолютно одинаковый объем вычислений.
Для чистоты эксперимента удалены графические окна. Получается прямое чистое сравнение решателей. Simulink при первом старте моделирования создает код Си и компилирует dll. В процессе моделирования используется dll.
Разница в скорости вычислений составляет:
Simulink 25 сек. МВТУ 3-4 сек. Как говорится разница более чем в 5 раз.
Поскольку сами уравнения просты до безобразия, маловероятно, что в обоих примерах MatLab генерирует неоптимальный код Си.
Выводы
1 Simulink в связке с MatLab тормозит.
2 Скорость расчета моделей написанных на Си изрядно преувеличена, и кажется большой только при сравнении с Васиком или Java скрип.
Паровоз кажется скоростным видом транспорта только по сравнению с телегой.
Пора пересаживаться в самолет.
Цитата(petuhoff @ Nov 3 2005, 14:38)
Еще раз о неуклюжести связки MatLab и Simulink
В приложенном архиве два примера сравнения Simulink и МВТУ.
Решается две простые, но жестки системы уравненией.
Настройки решателя анологичны. Простой метод Эйлера с фиксированным шагом.
Другими словами обе программы делают абсолютно одинаковый объем вычислений.
Для чистоты эксперимента удалены графические окна. Получается прямое чистое сравнение решателей. Simulink при первом старте моделирования создает код Си и компилирует dll. В процессе моделирования используется dll.
Разница в скорости вычислений составляет:
Simulink 25 сек. МВТУ 3-4 сек. Как говорится разница более чем в 5 раз.
Поскольку сами уравнения просты до безобразия, маловероятно, что в обоих примерах MatLab генерирует неоптимальный код Си.
Выводы
1 Simulink в связке с MatLab тормозит.
2 Скорость расчета моделей написанных на Си изрядно преувеличена, и кажется большой только при сравнении с Васиком или Java скрип.
Паровоз кажется скоростным видом транспорта только по сравнению с телегой.
Пора пересаживаться в самолет.
В приложенном архиве два примера сравнения Simulink и МВТУ.
Решается две простые, но жестки системы уравненией.
Настройки решателя анологичны. Простой метод Эйлера с фиксированным шагом.
Другими словами обе программы делают абсолютно одинаковый объем вычислений.
Для чистоты эксперимента удалены графические окна. Получается прямое чистое сравнение решателей. Simulink при первом старте моделирования создает код Си и компилирует dll. В процессе моделирования используется dll.
Разница в скорости вычислений составляет:
Simulink 25 сек. МВТУ 3-4 сек. Как говорится разница более чем в 5 раз.
Поскольку сами уравнения просты до безобразия, маловероятно, что в обоих примерах MatLab генерирует неоптимальный код Си.
Выводы
1 Simulink в связке с MatLab тормозит.
2 Скорость расчета моделей написанных на Си изрядно преувеличена, и кажется большой только при сравнении с Васиком или Java скрип.
Паровоз кажется скоростным видом транспорта только по сравнению с телегой.
Пора пересаживаться в самолет.
А как насчёт разнообразия моделей в МВТУ???
Вы пробовали симулировать mix-mode схемы??
Насчет разнообразия моделей все нормально.
Поскольку идеологически MBTY это тот же Simulink (Пакет структурного моделирования) только быстрее, то все что может Simulink может и МВТУ.
Если говорить конкретно по отраслям, скажем АСУ ТП моделировать однозначно лучше в МВТУ.
А кроме блоков для моделирования автоматики есть специальные библиотеки блоков для моделирования электродвигателей, силового гидропривода, пневмоавтоматики, ядреных установок, теплогидравлики, систем перекачки и хранения природного газа.
Но главное язык программирования, позволяющий дописать все чего не хватает, мне кажется, что основное преимущество МВТУ над Simulink в том что у MatchWorks сначала был медленный и неуклюжий MatLab к которому она прикрутила быстрый Simulink и теперь в одной повозке конь и трепетная лань. А в МВТУ в реактивном пакете структурного моделирования сделали такой же реактивный “матлаб” (встроенный язык программирования).
А что вы подразумеваете под mix-mode системами?
Поскольку идеологически MBTY это тот же Simulink (Пакет структурного моделирования) только быстрее, то все что может Simulink может и МВТУ.
Если говорить конкретно по отраслям, скажем АСУ ТП моделировать однозначно лучше в МВТУ.
А кроме блоков для моделирования автоматики есть специальные библиотеки блоков для моделирования электродвигателей, силового гидропривода, пневмоавтоматики, ядреных установок, теплогидравлики, систем перекачки и хранения природного газа.
Но главное язык программирования, позволяющий дописать все чего не хватает, мне кажется, что основное преимущество МВТУ над Simulink в том что у MatchWorks сначала был медленный и неуклюжий MatLab к которому она прикрутила быстрый Simulink и теперь в одной повозке конь и трепетная лань. А в МВТУ в реактивном пакете структурного моделирования сделали такой же реактивный “матлаб” (встроенный язык программирования).
А что вы подразумеваете под mix-mode системами?
Цитата(petuhoff @ Nov 8 2005, 20:59)
Насчет разнообразия моделей все нормально.
Поскольку идеологически MBTY это тот же Simulink (Пакет структурного моделирования) только быстрее, то все что может Simulink может и МВТУ.
Если говорить конкретно по отраслям, скажем АСУ ТП моделировать однозначно лучше в МВТУ.
А кроме блоков для моделирования автоматики есть специальные библиотеки блоков для моделирования электродвигателей, силового гидропривода, пневмоавтоматики, ядреных установок, теплогидравлики, систем перекачки и хранения природного газа.
Но главное язык программирования, позволяющий дописать все чего не хватает, мне кажется, что основное преимущество МВТУ над Simulink в том что у MatchWorks сначала был медленный и неуклюжий MatLab к которому она прикрутила быстрый Simulink и теперь в одной повозке конь и трепетная лань. А в МВТУ в реактивном пакете структурного моделирования сделали такой же реактивный “матлаб” (встроенный язык программирования).
А что вы подразумеваете под mix-mode системами?
Поскольку идеологически MBTY это тот же Simulink (Пакет структурного моделирования) только быстрее, то все что может Simulink может и МВТУ.
Если говорить конкретно по отраслям, скажем АСУ ТП моделировать однозначно лучше в МВТУ.
А кроме блоков для моделирования автоматики есть специальные библиотеки блоков для моделирования электродвигателей, силового гидропривода, пневмоавтоматики, ядреных установок, теплогидравлики, систем перекачки и хранения природного газа.
Но главное язык программирования, позволяющий дописать все чего не хватает, мне кажется, что основное преимущество МВТУ над Simulink в том что у MatchWorks сначала был медленный и неуклюжий MatLab к которому она прикрутила быстрый Simulink и теперь в одной повозке конь и трепетная лань. А в МВТУ в реактивном пакете структурного моделирования сделали такой же реактивный “матлаб” (встроенный язык программирования).
А что вы подразумеваете под mix-mode системами?
Mix-Mode подразумеваю Analog/Digital (ADC, DAC и т.д.)
Позвольте ещё вопрос. А каким образом вы гарантируете точность ваших моделей? Производились ли сравнения с реальными устройствами или это всё "академические модели"?
>>Mix-Mode подразумеваю Analog/Digital (ADC, DAC и т.д.)
С этим никаких проблем. Собирайте модели аналоговых приборов и из динамических линейных и не линейных блоков, цифровую часть собираете с помощью дискретных блоков и вперед, единственная тонкость использование экстраполятор на обратных связях когда изменение передается дискретно с определенным периодом квантования
См пример в папке \МВТУ 3.5\Demo\Следящие_приводы\diskret\ Dcmaaaa.mrj
Там дискретная (цифровая) управляющая часть работает с аналоговой моделью редуктора.
>>Позвольте ещё вопрос. А каким образом вы гарантируете точность ваших моделей? Производились >>ли сравнения с реальными устройствами или это всё "академические модели"?
Если говорить о точности модели, то она целиком и полностью на совести того, кто ее собирает из блоков. Авторы гарантируют только точность блоков, другими словами авторы гарантируют, что дифференциальные уравнения, зашитые в блоки будут рассчитанные с заданной относительной точностью, в случае невозможности достижения заданной точности, например, когда пользователь установил слишком большой минимальный шаг, будет выдано предупреждение.
В качестве “реального устройства” можно привести Смоленскую атомную станцию, модель АЭС собранная в МВТУ рассчитывала переходный процесс снижения мощности. Данные расчета сравнивались с реальными данными работающей АЭС и показали отличное совпадение.
О надежности МВТУ говорит то, что ее используют для разработки алгоритмов управления для действующих АЭС. А так же для проверки работоспособности реального железа перед поставками на АЭС.
С этим никаких проблем. Собирайте модели аналоговых приборов и из динамических линейных и не линейных блоков, цифровую часть собираете с помощью дискретных блоков и вперед, единственная тонкость использование экстраполятор на обратных связях когда изменение передается дискретно с определенным периодом квантования
См пример в папке \МВТУ 3.5\Demo\Следящие_приводы\diskret\ Dcmaaaa.mrj
Там дискретная (цифровая) управляющая часть работает с аналоговой моделью редуктора.
>>Позвольте ещё вопрос. А каким образом вы гарантируете точность ваших моделей? Производились >>ли сравнения с реальными устройствами или это всё "академические модели"?
Если говорить о точности модели, то она целиком и полностью на совести того, кто ее собирает из блоков. Авторы гарантируют только точность блоков, другими словами авторы гарантируют, что дифференциальные уравнения, зашитые в блоки будут рассчитанные с заданной относительной точностью, в случае невозможности достижения заданной точности, например, когда пользователь установил слишком большой минимальный шаг, будет выдано предупреждение.
В качестве “реального устройства” можно привести Смоленскую атомную станцию, модель АЭС собранная в МВТУ рассчитывала переходный процесс снижения мощности. Данные расчета сравнивались с реальными данными работающей АЭС и показали отличное совпадение.
О надежности МВТУ говорит то, что ее используют для разработки алгоритмов управления для действующих АЭС. А так же для проверки работоспособности реального железа перед поставками на АЭС.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.