Минимальное время цикла работы ПЛК

[BETEP]

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

Разве время цикла контроллера имеет к этому отношение? для ПИД всегда свой такт, регулировать температуру с тактом в 5 мс. круто да ещё со скоростью Овеновского АЦП.
---------------
Производители Омрона, ТАУ естественно не читали, у них период ПИД по глупости в настройках функции задаётся, так же как у Дельты с Мицубишей. И время цикла по умолчанию почему то не фиксируют, "продвинутые" электрики наверно...

[Дмитрий Артюховский]

температуру и ТМР202 отлично регулирует )) а некоторые регулируют скорость с реалтайме... экструдеры, насосы, конвееры...

[sea]

Все эти темы поднимаются в основном "продвинутыми" электриками, которым нужно датчик по порту подключить ))) Нет понимания главного... ПЛК придуманы не три лампочки включать - для этого есть реле, а для создания автоматизированных систем управления. А в них основная мысль в применении законов управления, есть наука такая - ТАУ, пропорциональные, интегральные, дифференциальные звенья, законы управления и пр. На контроллерах реализуется ее дискретное изложение. А для его реализации абсолютно необходима стабильная частота дискретизации взятия отсчетов и воздействий. При не выдерживании времени, и в частном случае при установки нулевого времени, цикла, закон управления, со всей своей мудреной математикой летит к чертям собачьим и система запросто сваливается, например в автоколебания ))))

Что такое ТАУ, описание передаточных функций линейных, релейных, цифровых систем, методы определения оптимальных настроек регуляторов на основе матмоделирования - вещи известные. Это все теория, а в любой теории есть допущения, которые на практике "вылазят".
Сейчас иногда проще и дешевле ПЛК и модули ввода/вывода поставить взамен кучи промежуточных реле, реле времени сложных переключателей и прочего. В итоге система получается дешевле, проще, надежней и более гибкой. Кроме этого появляются дополнительные возможности реализации связи, учета, управления и т.д. (кстати, есть такой раздел в ТАУ "Системы релейного управления").
Это для теории нужна стабильная частота, чтобы мозги не вскипели при математическом описании модели системы управления. А для большинства систем, чем меньше дискретизация по уровню и по времени - тем лучше, в том числе и по качеству регулирования.

Давайте не спорить по этим вопросам. Вопрос был больше практический.
Предложенное решение не противоречит стабильности частоты и прочих вещей. Пользовательская программа вызывается 1 раз в 10 мс при среднем (измеренном на железе) цикле ПЛК 8 мс (цифры для примера). Пусть 3 мс сама программа занимает. Для фоновых процессов в среднем требуется 5 мс, времени еще запас 2 мс. Результат - стабильный период в 10 мс, быстрый сетевой обмен. Минус есть тоже - постоянная загрузка контроллера, но это непринципиально.
А если просто выставить минимальное (уже здесь не гарантируется стабильность) время цикла ПЛК, пусть теже 10 мс, то сетевой обмен тормозит, проверено практикой.

[Дмитрий Артюховский]

"Предложенное решение не противоречит стабильности частоты и прочих вещей. Пользовательская программа вызывается 1 раз в 10 мс при среднем (измеренном на железе) цикле ПЛК 8 мс (цифры для примера). Пусть 3 мс сама программа занимает. Для фоновых процессов в среднем требуется 5 мс, времени еще запас 2 мс. Результат - стабильный период в 10 мс, быстрый сетевой обмен. Минус есть тоже - постоянная загрузка контроллера, но это непринципиально.
А если просто выставить минимальное (уже здесь не гарантируется стабильность) время цикла ПЛК, пусть теже 10 мс, то сетевой обмен тормозит, проверено практикой."

весьма сложно разделить время выполнения программы пользователя и фоновые процессы.... кроме того длительность фоновых процессов в 5 мс вызывает бооольшое сомнение..... идея цикла ПЛК, на мой взгляд, в следующем: выполняется цикл программы пользователя, затем выполняется ЦИКЛ ФОНОВЫХ ПРОЦЕССОВ, т.е. очередной цикл фона пройдет после очередного цикла программы, т.е. устанавливая большое время цикла ПЛК мы тормозим весь фоновый обмен.... байты - то накапливаются в буферах скорее всего равномерно по времени, а вот обработка собранных посылок, принятие решений о достоверности полученных данных и пр. принимаются периодически, по времени цикла.... таким образом, увеличивая время основного цикла мы можем "улетать" на превышения доступных тайм-аутов и нарушение правил протокола обмена.... поэтому мой выбор - это установка минимально стабильного времени цикла, если есть времеемкие задачи - их нужно ручками разводить по разным циклам.
В правильности данного подхода, меня убеждает использование библиотеки обмена по модбас ВНУТРИ программы пользователя, а не пользование конфигуратором... в этом случае, ошибки обмена возникают на порядки реже (обмен проходит с более высоким приоритетом), чем при работе через конфигуратор..... стабильная рекомендация тех.поддержки - увеличивайте тайминг - именно для того чтобы скомпенсировать время ожидания свободных тактов, для запуска фоновых процедур, в основном цикле.... наверно )))

[BETEP]

Дмитрий, ну спуститесь с небес на землю.
http://www.owen.ru/forum/showthread....l=1#post103641
Вы иногда причину со следствием путаете.

[Дмитрий Артюховский]

Да читал я это, но считаю неправильным. Еще раз повторюсь, если вы, пусть и редко, запускаете длительные вычисления пользователя (сравнимые или большие чем тайм-ауты обмена) - вы с очень большой вероятностью теряете сессию обмена - которая завершится ошибкой по таймауту. Нормальные протоколы обмена конечно должны прощать не множественные потери. Но поймите наконец, вы таким образом закладываете гарантированный сбой! Обмены по последовательным портам бесконечно медленные с точки зрения процессора ЦП и разговоры о том что обмен перегружает цикл - фуфло. Проблемы могут быть только при использовании usernet, там скорости высоки и при насыщенной "сетевой жизни" нагрузка может получаться значительной, ибо по протоколам сети необходимо реагировать на большое число сообщений...

[sink3d]

Разработчики говорят, что минимальное время цикла - это интервал вызова PLC_PRG(и все).Если же вызывать программу с помощью конфигуратора задач, то вызов PLC_PRG отключается, но это время продолжает влиять на обмен по Ehernet. Т.е. получается минимальное время цикла нужно выставлять всегда.По всей видимости программа пользователя крутится вместе с обработчиком Ehernet, причем реализована корпоративная многозадачность.Дмитрий я с вами полностью согласен. Для того чтобы разговор окончился результатом необходимо выработать рекомендации по времени цикла,для плк овен. Разработчики говорят, что уложите программу в 10-15мс и все у вас будет хорошо.Все бы хорошо, но сетевой обмен при таких цифрах реально напрягает, особенно при отладке. Издержки ПЛК без ОС.