Каковы могут быть причины разной работы программы (стандартный ПИД-регулятор из библиотек CoDeSys) на эмуляторе и на контроллере (ПЛК-150)? Должно ли что-то настраиваться, чтобы они работали одинаково? Где?
Вид для печати
Каковы могут быть причины разной работы программы (стандартный ПИД-регулятор из библиотек CoDeSys) на эмуляторе и на контроллере (ПЛК-150)? Должно ли что-то настраиваться, чтобы они работали одинаково? Где?
Начнем с того что время потраченное на один цикл в пк и плк разное и добиться равенство не представляется возможным, ну если только не поставить минимальное время достаточно большим, чтоб обеспечить когда оба устройства будут ждать следущего цикла
Спасибо за отклик.Цитата:
Сообщение от capzap
Такая гипотеза у меня была. И даже был проведен эксперимент: в законе регулирования был занулён наиболее чувствительный элемент - дифференцирование. Совпадение работы улучшилось. Результат говорит за эту гипотезу. Тогда, действительно, дифференциал может различаться в десятки, а то и в сотни раз. Но это же означает, что ПЛК "Овен" работает вовсе не по времени, хотя именно оно указывается в законе регулирования, а по циклам! То есть, дифференцируя, он берет дифференциал, не учитывая реальной длительности цикла. Неужели это так? Но это же принципиальное нарушение инвариантности реализации программы. Мне это кажется странным. Ведь тогда изменение длительности цикла будет влечь за собой необходимость изменения всех коэффициентов. Поэтому я засомневался в своей гипотезе и решил обратиться к специалистам, поскольку в документации я по этому вопросу ничего не нашел. За отклик благодарен, но ведь это тоже только Ваша гипотеза. Или есть какой-то документированный источник? Возможно, Вы что-то видели в документации по "Овену", а я пропустил. Поделитесь, пожалуйста, если это возможно, ссылкой.
прочтите руководство на МВА, там рекомендуют для регулирования использовать значение канала и время, во избежание расхождений периода.
А по большому счету, Вам это для чего, неужели Вы собрались подобрать коэффициенты регулирования на эмуляторе для работы реального объекта, вот это то как раз и является странным
1. Как говорят программисты: лучше исходных текстов нет документации. Библиотека Util.lib написана на языке ST. Открываете, смотрите текст и комментарии. Можно прогнать отладчиком.
2. Эмулятор предназначен для отладки логики программы. Реального времени он не обеспечивает. Работает на тиках системного таймера PC. Вы пытаетесь мерить миллисекунды, а таймер тикает в 55 раз реже. Получается ерунда. Секундные интервалы в эмуляторе реальны, но не меньше.
3. Для эмуляции систем с реальным временем запускам SP RTE и с ним работаем вместо ПЛК.
4. Посмотрите исходный текст блока ПИД. Он сам измеряет время между вызовами и использует его в вычислениях. В ПЛК это будет работать.
5. Обратите внимание на блок PID_FIXCYCLE. Ему время дается на вход и можно вести симуляцию в нужном масштабе времени.
Верю Вам, что программисты так говорят. Но 1. Справедливость этого утверждения весьма спорна; 2. Кроме программистов есть еще и пользователи. Увы, мы не всегда так хорошо разбираемся в этом, как хотелось бы. Но, согласитесь, что если бы нас не было, то и программисты были бы ни к чему.Цитата:
Сообщение от Игорь Петров
Понял, спасибо. Это все объясняет.Цитата:
Сообщение от Игорь Петров
А почему в 55 раз? Это число чем-то обусловлено, или это просто для примера?
По остальным пунктам тоже огромное спасибо. Познавательно. Рекомендации попробую.
Спасибо. Посмотрю.Цитата:
Сообщение от capzap
Ну почему же это странно? Я так не собираюсь делать, но согласитесь, что при наличии адекватной модели объекта регулирования, это было бы вполне хорошо. Осуществить первичный подбор на компьютере и последующую доводку на реальном объекте. Чем плохо? По-моему, очень даже прогрессивно.Цитата:
Сообщение от capzap
как видите, эмулятор не подходит даже для первичного подбора коэффициентов, надо использовать либо реальный контроллер, либо SP RTE
Вот ключевые слова, здесь почему то Вы не отрицаете факта, что придется подстраиваться, но требуете от эмуляции точного выполнения физики процесса. Может причина не в ПЛК, а в программе отвечающей за создание адекватной модели регулируемой средыЦитата:
Сообщение от Михаил Иванович
Это не утверждение, а практический совет.Цитата:
Сообщение от Михаил Иванович
Применительно к CoDeSys Пользователи = Прикладные программисты. Биб-ка Util написана не на каких-то заумных языках программирования, требующих ученой степени и приобретения дорогих инструментов, а прямо в CoDeSys на обычных МЭК языках. Вполне доступно пользователю. По жизни мелкие правки программ часто несколько опережают мануалы. Можно законно требовать и ждать исправлений, либо потратить немного времени на изучение исходного текста. Это дает ответы, плюс новые приемы. Рекомендую, успешно пользуюсь этим способом уже два десятка лет.
Стандартные МЭК таймеры обеспечивают переключение выхода после заданного времени. Т.е. если выход сработал, то можно гарантировать что время истекло. Однако, как давно оно истекло неизвестно! Типично в любом ПЛК аппаратный таймер тикает через 1 мс или даже меньше. Вот с такой точностью и будут работать все программные блоки. В Windows PC штатный аппаратный таймер тикает раз в 55 мс. Запустив в эмуляторе TON на 1мс, через 110мс его выход точно сообщит что 1мс гарантировано прошла. Аналогичная картина и с измерением длительности.Цитата:
Сообщение от Михаил Иванович
Симулятор ориентирован не на управление машиной, а на глаза и восприятие человека. Он намеренно прогоняет программу намеренно медленнее. Все вычисления отрабатываются, но надо понимать, что не в реальном времени.