Каковы могут быть причины разной работы программы (стандартный ПИД-регулятор из библиотек 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мс гарантировано прошла. Аналогичная картина и с измерением длительности.Цитата:
Сообщение от Михаил Иванович
Симулятор ориентирован не на управление машиной, а на глаза и восприятие человека. Он намеренно прогоняет программу намеренно медленнее. Все вычисления отрабатываются, но надо понимать, что не в реальном времени.
Что Вы! Ничего я не требовал, я спрашивал "Каковы могут быть причины разной работы программы ...". И получил от Вас и Игоря Петрова ответы, которые мне понятны. Спасибо.Цитата:
Сообщение от capzap
На мой взгляд, сначала должна писаться документация, потом программа. Это относится и к мелким правкам. Но это дискуссия уже на другую тему. Извините.Цитата:
Сообщение от Игорь Петров
Беда не в том, что медленнее, это как раз не страшно, тут у меня вопросов бы не возникло. На разных машинах программы тоже с разной скоростью идут. Беда в том, что из-за разного масштаба времени, о чем сами приборы, конечно, не знают, они идут по-разному. Эту особенность и причину Вы объяснили, а я понял. Это хорошо. Будем с этим считаться.Цитата:
Сообщение от Игорь Петров
Спасибо.
Согласен, но... Вы сдаете важный горящий объект, попросите внести мелкую правку. Вместо помощи за 5 минут, программист зарядит это дело в отдел технической документации.. после праздников они согласуют.. Боюсь, что мой взгляд в такой ситуации выражался бы только матом :)Цитата:
Сообщение от Михаил Иванович
Если серьезно, то документацию и ПО пишут не боги. Стоит взять за правило тестировать самому любую новую функцию или блок, прежде чем использовать в деле. Это и в CoDeSys и в любых других системах является хорошей идеей.
Вы утрируете ситуацию для того, чтобы показать ее более ярко. С яркостью - согласен. Но, я думаю. что все не так страшно. В приведенном Вами случае программист перед тем, как менять саму программу, должен написать за 5 минут техническое задание на коррекцию программы в самой простой свободной форме, еще за 5 минут - проект вносимого изменения, тоже в свободной форме, причем первое и второе можно совместить, еще за 5 минут внести эти изменения, потом потратить пол-часа на проверку того, не навредил-ли, и если все в порядке, зафиксировать внесенные изменения, получить подпись заказчика на акте испытаний внесенных изменений. А уж "после праздников", если они уже наступили, передать свои листочки в соответствующий отдел, они с ними разберутся, дадут программисту втык, за то, что не по форме, наябедничают начальству, начальство, как водится наградит непричастных и накажет невиновных, листочки в первозданном виде подошьют куда надо ибо выяснится, что и такая форма не противоречит ГОСТу, внесут запись в лист изменений, заведут на это изменение карточку и разошлют ее смежникам - держателям проектной документации. И только такой путь (за исключением ябеды начальству) позволит не утонуть в волнах вносимых изменений. Ибо опыт показывает, что документация "потом" - не пишется. То о чем я говорю называется элементарной производственной дисциплиной. Конечно, это требует определенных волевых усилий, для огромного большинства программистов просто немыслимых. Отсюда и рождаются всякие концепции "экстремального программирования" и т.п. Приведенная Вами в примере "помощь за 5 минут" в дальнейшем обернется сутками поиска где, когда и зачем кто-то что-то внес. А если человек уволился, то это может стать вообще безнадёжным делом. Уверен, что Вы с этим сталкивались, если не при разработке конкретной программы, то в какой-то иной ситуации, потому что это явление общее. Так может быть, лучше потратить час на простое документирование?Цитата:
Сообщение от Игорь Петров
Совершенно согласен. Собственно, именно это и является источником моих вопросов, на которые Вы и другие специалисты отвечаете, за что еще раз спасибо.Цитата:
Сообщение от Игорь Петров
Всегда разрабатываются детальные спецификации, но например я не способен все придумать сразу, особенно если делается нечто не имеющее аналогов. Многие вещи рождаются в процессе, обкатываются, притираются, потом описываются. Хорошо бы художнику зайти в Лувр, получить описание требуемого шедевра и спокойно его нарисовать :cool:
Будет как у юристов – поправка 215 к поправке закону, инструкция по чтению инструкции...Цитата:
Сообщение от Михаил Иванович
Не надо сутки поиска. Проблема решается системами управления версиями. Для CoDeSys V2 используется ENI. В V3 Professional Edition интегрирован SVN. На конференции раскроем эту тему.
Никто не способен. Есть процесс разработки, есть пробы, ошибки, решения. И бывает так, что изначальный вариант меняется до неузнаваемости - это объективно неизбежный процесс. Но если изначально нет Тех. задания, нет проекта с первоначальным описанием решений на основании того, что "все равно изменится, потом все опишу", не делается текущих описаний в этом процессе на том же основании, то "потом" - никогда не наступает. Почему? Первое - идеология. Человек, который придерживается идеологии "потом опишу" не способен на это. Он потому её и придерживается, что она позволяет ускользнуть от невозможного для него дела, найти себе текущее оправдание. Второе - забывается все быстро. Даже если добросовестный сотрудник действительно может и хочет описать потом, то у него может это не получиться или придётся затратить огромное, несопоставимое с самой работой время. Пока вы что-то делаете, пока "в теме", все кажется понятным. Проходит месяц, настаёт "потом" - и все надо поднимать заново. Сидеть и разбираться - а зачем такое было написано, выбрано такое решение. Неужели Вы с этим не сталкивались? У меня у самого такое бывало, поэтому взял за правило документировать, хоть пару строк - зачем, почему, как. Всего три вопроса и надо осветить. А если в проекте участвует много людей и один из них что-то важное забыл? Или уволился. Не было у Вас таких случаев? У меня, к счастью, не было, а с некоторых пор вообще предпочитаю работать в одиночку, но я такое наблюдал. Нельзя написать "потом", "потом" можно только подытожить, создать создать на основе текущих локальных документов новый общий документ. Вам хочется использовать систему управления версиями? Пожалуйста. Кто-то использует листочек бумажки и карандаш, кто-то делает заметки в Word'е, кто-то по каждому поводу запускает сервер с Аксаптой. Не важно, что используется, важно, чтобы этот процесс был системным, чтобы он был обязательной частью разработки. На каждом этапе. Это и называется "производственная дисциплина". И я речь веду именно о ней - не путать с отсидкой. Её автоматизировать невозможно. И без неё любая система, в том числе ENI, в том числе любая ERP-система превращается в автоматизированный бардак. А это совсем плохо.Цитата:
Сообщение от Игорь Петров
Должен ещё сказать, что у меня есть впечатление, что мы как-то по-разному понимаем предмет обсуждения. Не могу я себе представить, что Вы не понимаете необходимости документирования проекта на всем протяжении процесса его реализации.
О конференции я знаю, но, увы, присутствовать не смогу.
Спасибо.