Вид для печати
ПЛК100 будет постоянно опрашиваться Мастер Скадой по сети Еthernet. Основная функция - чтение восьми переменных с аналогового модуля. Какое минимальное время цикла MinCycleLenhth необходимо установить при настройке конфигурации ПЛК, чтобы он работал максимально устойчиво. MaxCycleLenhth думаю оставить по умолчанию.
пятерочки для всего хватает.
Подскажите, какое время цикла ПЛК (минимальное) установить?
Нужно определить сколько по времени будут выполняться сервисные функции ПЛК, а именно операции сетевого обмена.
RS-485: ПЛК110-32 (ведущий); МВ110-224.1ТД, МСД-200, СМИ2 (ведомые).
RS-232: СП270 (ведущий); ПЛК110-32 (тотже ПЛК, ведомый).
Протокол в обоих интерфейсах одинаковый ModBus RTU, скорость 115200 бит/с, данные 8 бит, 1 стоп бит.
Нагрузка ПЛК по данным в сети RS-485:
- чтение REAL и WORD;
- запись WORD, REAL, DWORD, WORD, STRING6 (48 бит).
Чтение и запись данных осуществляется раздельно по каждой переменной.
Нагрузка ПЛК по данным в сети RS-232:
- передача 45 последовательных 2-х байтовых переменных на один запрос от СП270 (передача одним пакетом).
Добавлены модули ModBus (Master) (RS-485), ModBus (Slave) (RS-232) в конфигураторе ПЛК.
Я так пологаю (опираюсь на руководство программирования ПЛК, п. "Задание времени цикла ПЛК"), что время цикла ПЛК должно включать в себя и время, необходимое на сетевой обмен. Т.е., например, ввод данных 0,5 мс; выполнение пользовательской программы 1 мс; вывод данных 0,5 мс; сетевой обмен 8 мс; итого 10 мс. Тогда с учетом 20% запаса устанавливаем MinCycleLength 12 мс.
Проблема определения времени сетевого обмена ПЛК возникла когда он стал передавать не стабильно данные в другие устройства, иногда правильные актуальные, а иногда устаревшие (за прошлый цикл). Повышать время цикла ПЛК до 10 мс - уже критично. Сейчас 10 мс установлено, но иногда в модуле Statistic время цикла более 10 мс заметить можно (12...15 мс), хотя по средним данным перегрузка не высвечивается и запас есть. Это из-за того, что сетевой обмен с разным периодом происходит (так думаю). Вот и хотелось бы определить максимальное время, которое необходимо ПЛК для корректного обмена данными.
Попробуйте установить в 0. Где-то на форуме была темка про это.Цитата:
Сообщение от sea
См. ссылку этой темы http://www.owen.ru/forum/showthread....l=1#post103202
Спасибо, ссылку просмотрю.Цитата:
Сообщение от amn
Установить 0 не могу поскольку требуется опрос дискретных входов и МВ110-224.1ТД один раз максимум в 10 мс. Иначе быстродействие системы управления упадет и качество продукции снизится.
Почему так?Цитата:
один раз максимум в 10 мс. Иначе быстродействие системы управления упадет и качество продукции снизи
Подскажите. ПЛК110-60,3 вход. модуля,3 выход.Модуль статистик показывает min cycle 5 ms.На плк ставил и1ms и 5ms и10ms и ничего не изменяется все работает и не глючит.А какое реальное надо выставить.
Потому что сказывается дискретизация сигнала по времени.Цитата:
Сообщение от Amko
Например, дозатор. Поздно (из-за запаздывания) закрыли дозирующую заслонку - получили бОльшую массу материала, в итоге не 40%, а 45%.
Для данного обмена ПЛК принимает/передает 3200 бит, при заданной скорости на это тратится 27,78 мс.Цитата:
Сообщение от sea
Такое время цикла ПЛК в модуле Statistica (при выявлении максимума) не отображается, максимум зафиксировал 6 мс (среднее значение около 2...3 мс). Следовательно, "операции обмена данными" - это не сама передача данных и полное время обмена данными (27,78 мс) в цикл ПЛК включать не следует.
В сети RS-232 происходит передача 1086 бит (9,43 мс, около 1/3 от общего времени обмена). Беру откидываю RS-232 от ПЛК (СП270 - мастер исчезает), что приводит к остановке посылок запросов к ПЛК. В результате на времени цикла ПЛК это практически не сказывается.
То SEA - вы неправильно понимаете способ функционирования обменов по портам. Реально на операции обмена тратятся микросекунды, остальное время ПЛК лишь проверяет завершенность операций (для пользователя! реальное функционирование скрыто в фоновых задачах и библиотеках) . Ставьте время цикла 1 мс и проверяйте в своих циклах флаги завершения операций обмена.
Ожидать в одном цикле завершения обмена в корне не верно! Выдаете команду на начало обмена, а далее, в следующих циклах, проверяете флаг завершения. Скорость опроса от этого не изменится, а запаздывание реакции - не более времени одного цикла - 1мс.
Поэтому пытаюсь разобраться.Цитата:
Сообщение от Дмитрий Артюховский
Чем тратяться микросекунды, центральным микроконтроллером? Реальным обменом наверное вообще другой МК занимается?Цитата:
Сообщение от Дмитрий Артюховский
Время цикла нельзя устанавливать меньше времени выполнения программы. Сейчас статистику набираю по времени цикла ПЛК (установлено минимальное значение 0):Цитата:
Сообщение от Дмитрий Артюховский
- минимальное 0,3 мс;
- максимальное 5,7 мс;
- среднее 0,5 мс.
Так какое установить?
Спасибо, получил подтверждение своим догадкам.Цитата:
Сообщение от Дмитрий Артюховский
Скорость, понятно, что 115200 бит/с стабильна. А на счет запаздывания данных - не "1 мс".Цитата:
Сообщение от Дмитрий Артюховский
Данные еще нужно принять/передать. Пусть программа вызывается 1 раз в 1 мс. Отсюда максимальное запаздывание 2 цикла, т.е. 2 мс. Передача данных на запрос одним пакетом 1028 бит занимает еще 9,43 мс. Итоговое запаздывание 11,43 мс.
На чтение ПЛК (Ведущий) одного регистра из Ведомого требуется 1,79 мс (206 бит), для записи - 1,88 мс. А может еще и ни с первой попытки обмен пройти.
Итого в сети RS-485 обмен происходит за 18,35 мс.
Вот вопрос стал: RS-232, RS-485 на одном микроконтроллере (не на центральном) реализованы или на разных?
Или все же не дополнительные МК, а отдельная перефирия (типа АЦП, ЦАП, ШИМ и т.д.) центрального микроконтроллера?
Гм. Если мы чаще прочитали сигнал, тогда из-за чего получится запаздывание? Мы раньше прочитали уставку - раньше закрыли. Плюс в дозаторах есть же зона остановки дозирования, настраивается эмпирически в зависимости от условий работы. И сюда же закладывается запаздывание считывания. Вот не пойму я, почему вам надо именно реже читать значения веса. От дребезга избавляетесь? Болтает ваш дозатор, значения скачут?Цитата:
Например, дозатор. Поздно (из-за запаздывания) закрыли дозирующую заслонку - получили бОльшую массу материала, в итоге не 40%, а 45%.
Имелось в виду: не реже чем 1 раз в 10 мс, т.е. минимальное время цикла не более 10 мс.Цитата:
Сообщение от sea
Про дозатор просто пример привел. Конечно, чаще необходимо считывать вес. Система измерения веса без контактов (МВ110-224.1ТД).Цитата:
Сообщение от Amko
Реальный обмен, скорее всего, выполняют отдельные чипы, но опрос завершения выполняется центральным процессором, на это и тратится его время.Цитата:
Сообщение от sea
Время цикла можно устанавливать меньше чем пиковые значения времени цикла. Единичный цикл просто растянется на требуемое время. При выходе времени цикла за рамки - будут приостанавливаться некоторые фоновые процессы, потом они нагонятся, главное чтобы среднее время выполнения было меньше установленного. "запаздывание" - имелось ввиду отставание реакции основной программы контроллера на полностью полученный пакет, а не время получения пакета.
Концепция ПЛК: получение входных данных - обработка - отправка ответов. Реальный побайтовый обмен по портам скрыт в фоновых процессах и программер получает информацию о статусе обмена в фазе "получение входных данных"
"Имелось в виду: не реже чем 1 раз в 10 мс, т.е. минимальное время цикла не более 10 мс." - различайте цикл выполнения ПЛК и цикл (период) регулирования системы
Еще раз спасибо за ссылочку. Просмотрел данную тему, по совету и примеру sink3d сделал следующееЦитата:
Сообщение от amn
- чтобы не тормозил сетевой обмен выставил минимальное время цикла ПЛК 0 мс;
- через конфигуратор задач добавил циклическую задачу с вызовом основной программы через 10 мс.
Результат положительный, проверено на железе (ПЛК150 и СП270).
Если ставлю, например, МинВЦ ПЛК 10 мс, то сетевой обмен раз в 10 мс запускается (sink3d) и в результате СП270 (опрос через 10 мс, меньше 9,43 мс нельзя, максимальное время задержки ответа 20 мс) все время выдает ошибку связи.
Смыcл в "чаще" если время оцифровки - в лучшем случае до 25мс ? РЭ Т2.1Цитата:
Сообщение от sea
И зачем стараться так быстро на панель ? Оператор брюс ли ?
нет, к зиме готовится, при такой частоте микросхемы смогут работать и при минусовой температуре за бортом :)Цитата:
Сообщение от Валенок
Для панели это время (10 мс) не критично, и можно 50...100 мс. Для расчета максимальной загрузки ПЛК использовалось. Но вроде обмен по RS-485 и RS-232 типа параллельно и независимо происходит физически.Цитата:
Сообщение от Валенок
В РЭ Таблица 2.2 для МВ110-224.1ТД "Время обновления данных измерений, мс, не более" может быть и 2,1 мс.
Кстати на 44,64 Гц (24 мс) и настроили прибор.
Но ПЛК110 все равно не чаще 10 мс опрос может производить (по крайней мере через Конфигуратор ПЛК).
От этих 10 мс и пляшем.
Сам процесс считывания данных массы на входе и статуса прибора занимает 3,75 мс (REAL и WORD). По массе - 1,96 мс.
Первоначально думал так: опрос входов - выполнение программы - установка выходов - другое, в том числе и сетевой обмен - конец цикла. И к новому вызову программы - опа, свежие данные по массе.
Теперь понятней! Если бы это в РП ПЛК было обозначено - вопросов меньше возникало.Цитата:
Сообщение от Дмитрий Артюховский
В общем, ориентир на среднее время цикла ПЛК держать.
Это я для себя сетевой обмен представил, как опросы входа и установка выходов.Цитата:
Сообщение от Дмитрий Артюховский
Проще, просто МинВЦ ПЛК установить 0 мс и забыть про это. Хотя в данном случае иногда (вопрос вероятности) цикл ПЛК может превысить максимально допустимый период запуска программы. Все зависит от задачи...
Где там в Т2.2 про 2.1мс ? Можно, конечно, тешить себя что не более 25 это и 0 (ноль) тоже. Как и -1.
Вы серъезно так считаете ? Это случай связи устройств с временем цикла обоих стремящихся к нулю. А учли квантование времени в ПЛК, квантование времени в слейве ? Даже не выходя из цикла ПЛК - в лучшем случае 6-7мс. Причем все равно 115.2 или 38.4. Время тут ест не обмен, а квантование и временные маркеры конца пакетов.Цитата:
Сам процесс считывания данных массы на входе и статуса прибора занимает 3,75 мс.
Минимальное время цикла и контроль изменений. Изменения и есть - опа.
Больше 10 мс - будет затык. Самое неприятное, когда на действующем оборудовании CodeSys с ошибкой "вылетит". Связь рвётся и приходится к шкаПчику бежать - проверять: не повис ли и ПЛК заодно.
Да, на сайте открыл РЭ (re_mv110-224.td_1404.pdf), в нем как Вы указали.Цитата:
Сообщение от Валенок
У меня на HDD другая версия РЭ (rie_mv110-224.td_1118.pdf) и с прибором тоже она была:
http://www.owen.ru/uploads/rie_mv110-224.td_1118.pdf
И частоту дискретизации можно изменить в приборе.
Рассчитал минимальное время передачи бит в канале без задержек (от чего-то нужно было отталкиваться), "запрос - ответ".Цитата:
Сообщение от Валенок
REAL - 226 бит, 1,96 мс;
WORD - 206 бит, 1,79 мс.
Начало и конец пакета для RTU приняты по 14 бит.
Стартовый бит может не идти сразу за стоповымЦитата:
REAL - 226 бит, 1,96 мс ..WORD - 206 бит, 1,79 мс
Читаем например википедиюЦитата:
Начало и конец пакета для RTU приняты по 14 бит.
Слейв имеет цикл. Нужно быть уверенным что отправив в порт из мастера :
1.Данные пошли сию мксекунду
2.Прям в момент прихода последнего бита от мастера стартовал цикл слейва чтоб в очередной раз включить таймер для отслеживания маркера -ведь уже может быть задержка.
Но:
3.Цикл слейва не будет кратен маркеру - придется выдержать округленное вверх время маркера
4.Слейву нужно тупо время для подготовки данных расчета crc
5.Слейв может тупо позаниматся другой задачей
6.Слейв стал посылать данные в ответ
7-8. см. 2-3, но квантуется цикл мастера
9.Проверка данных с выкладыванием в область обмена займет время
10. Вот они - данные
Набегает в общем в отличие от теории
Это понятно. Конечно, еще есть задержки по времени передачи данных. Я рассчитал минимальное время обмена данными, чтобы хоть ориентировочно можно было от него отталкиваться...Цитата:
Сообщение от Валенок
Да и смотря какой слейв.
От темы мы отошли. А решение по установки МинВЦ ПЛК уже указано постами выше:
- МинВЦ ПЛК устанавливаем 0 мс;
- через Конфигуратор задач запускаем программу с требуемым интервалом (если требуется). Данный интервал принимает больше среднего времени цикла ПЛК.
В этом случае и сетевой обмен не тормозит и программа выполняется через заданный интервал.
Работает ? Вот и славненько
"От темы мы отошли. А решение по установки МинВЦ ПЛК уже указано постами выше:
- МинВЦ ПЛК устанавливаем 0 мс;
- через Конфигуратор задач запускаем программу с требуемым интервалом (если требуется). Данный интервал принимает больше среднего времени цикла ПЛК.
В этом случае и сетевой обмен не тормозит и программа выполняется через заданный интервал."
это примерно тоже самое что ставить телегу впереди лошади )))) вроде и работает, но выглядит идиотски, и колеса буксуют в ямках )))
нормальное состояние это когда ритмично выполняется цикл ПЛК в котором прогоняется программа пользователя, затем служебные задания (обмены), затем временная пауза для выравнивания времени. В этом случае основной код выполняется со стабильной частотой дискретизации, происходят регулярные, стабильные во времени, вызовы фоновых процедур. Предлагаемая вами схема подразумевает довольно значительное время выполнения цикла основного кода, в это время не будет обработки фоновых обменов, и возможны потери из-за переполнения буферов и из-за превышения таймингов запросов - ответов протокола обмена. Зато, во время нулевых циклов, когда основной код не выполняется, будут только суматошные вызовы фоновых процедур по контролю пустых буферов обмена ))) Кроме того, на фоновые обмены отводится время между окончанием цикла пользователя и очередным таймерным отсчетом.... а если этот таймер не настроен будет??? (нулевое время цикла) то сколько времени будет отведено на фоновые процедуры???
А что Вы предложите?Цитата:
Сообщение от Дмитрий Артюховский
Эту тему:
http://www.owen.ru/forum/showthread.php?t=14379
просматривали?
Все эти темы поднимаются в основном "продвинутыми" электриками, которым нужно датчик по порту подключить ))) Нет понимания главного... ПЛК придуманы не три лампочки включать - для этого есть реле, а для создания автоматизированных систем управления. А в них основная мысль в применении законов управления, есть наука такая - ТАУ, пропорциональные, интегральные, дифференциальные звенья, законы управления и пр. На контроллерах реализуется ее дискретное изложение. А для его реализации абсолютно необходима стабильная частота дискретизации взятия отсчетов и воздействий. При не выдерживании времени, и в частном случае при установки нулевого времени, цикла, закон управления, со всей своей мудреной математикой летит к чертям собачьим и система запросто сваливается, например в автоколебания ))))
а так, да конечно, как кто-то написал "работает и ладненько"... ну как типа никто же не запрещает и гвоздь утюгом забить )))
Разве время цикла контроллера имеет к этому отношение? для ПИД всегда свой такт, регулировать температуру с тактом в 5 мс. круто :) да ещё со скоростью Овеновского АЦП.Цитата:
Сообщение от Дмитрий Артюховский
---------------
Производители Омрона, ТАУ естественно не читали, у них период ПИД по глупости в настройках функции задаётся, так же как у Дельты с Мицубишей. И время цикла по умолчанию почему то не фиксируют, "продвинутые" электрики наверно...
температуру и ТМР202 отлично регулирует )) а некоторые регулируют скорость с реалтайме... экструдеры, насосы, конвееры...
Что такое ТАУ, описание передаточных функций линейных, релейных, цифровых систем, методы определения оптимальных настроек регуляторов на основе матмоделирования - вещи известные. Это все теория, а в любой теории есть допущения, которые на практике "вылазят".Цитата:
Сообщение от Дмитрий Артюховский
Сейчас иногда проще и дешевле ПЛК и модули ввода/вывода поставить взамен кучи промежуточных реле, реле времени сложных переключателей и прочего. В итоге система получается дешевле, проще, надежней и более гибкой. Кроме этого появляются дополнительные возможности реализации связи, учета, управления и т.д. (кстати, есть такой раздел в ТАУ "Системы релейного управления").
Это для теории нужна стабильная частота, чтобы мозги не вскипели при математическом описании модели системы управления. А для большинства систем, чем меньше дискретизация по уровню и по времени - тем лучше, в том числе и по качеству регулирования.
Давайте не спорить по этим вопросам. Вопрос был больше практический.
Предложенное решение не противоречит стабильности частоты и прочих вещей. Пользовательская программа вызывается 1 раз в 10 мс при среднем (измеренном на железе) цикле ПЛК 8 мс (цифры для примера). Пусть 3 мс сама программа занимает. Для фоновых процессов в среднем требуется 5 мс, времени еще запас 2 мс. Результат - стабильный период в 10 мс, быстрый сетевой обмен. Минус есть тоже - постоянная загрузка контроллера, но это непринципиально.
А если просто выставить минимальное (уже здесь не гарантируется стабильность) время цикла ПЛК, пусть теже 10 мс, то сетевой обмен тормозит, проверено практикой.
"Предложенное решение не противоречит стабильности частоты и прочих вещей. Пользовательская программа вызывается 1 раз в 10 мс при среднем (измеренном на железе) цикле ПЛК 8 мс (цифры для примера). Пусть 3 мс сама программа занимает. Для фоновых процессов в среднем требуется 5 мс, времени еще запас 2 мс. Результат - стабильный период в 10 мс, быстрый сетевой обмен. Минус есть тоже - постоянная загрузка контроллера, но это непринципиально.
А если просто выставить минимальное (уже здесь не гарантируется стабильность) время цикла ПЛК, пусть теже 10 мс, то сетевой обмен тормозит, проверено практикой."
весьма сложно разделить время выполнения программы пользователя и фоновые процессы.... кроме того длительность фоновых процессов в 5 мс вызывает бооольшое сомнение..... идея цикла ПЛК, на мой взгляд, в следующем: выполняется цикл программы пользователя, затем выполняется ЦИКЛ ФОНОВЫХ ПРОЦЕССОВ, т.е. очередной цикл фона пройдет после очередного цикла программы, т.е. устанавливая большое время цикла ПЛК мы тормозим весь фоновый обмен.... байты - то накапливаются в буферах скорее всего равномерно по времени, а вот обработка собранных посылок, принятие решений о достоверности полученных данных и пр. принимаются периодически, по времени цикла.... таким образом, увеличивая время основного цикла мы можем "улетать" на превышения доступных тайм-аутов и нарушение правил протокола обмена.... поэтому мой выбор - это установка минимально стабильного времени цикла, если есть времеемкие задачи - их нужно ручками разводить по разным циклам.
В правильности данного подхода, меня убеждает использование библиотеки обмена по модбас ВНУТРИ программы пользователя, а не пользование конфигуратором... в этом случае, ошибки обмена возникают на порядки реже (обмен проходит с более высоким приоритетом), чем при работе через конфигуратор..... стабильная рекомендация тех.поддержки - увеличивайте тайминг - именно для того чтобы скомпенсировать время ожидания свободных тактов, для запуска фоновых процедур, в основном цикле.... наверно )))
Дмитрий, ну спуститесь с небес на землю.
http://www.owen.ru/forum/showthread....l=1#post103641
Вы иногда причину со следствием путаете.
Да читал я это, но считаю неправильным. Еще раз повторюсь, если вы, пусть и редко, запускаете длительные вычисления пользователя (сравнимые или большие чем тайм-ауты обмена) - вы с очень большой вероятностью теряете сессию обмена - которая завершится ошибкой по таймауту. Нормальные протоколы обмена конечно должны прощать не множественные потери. Но поймите наконец, вы таким образом закладываете гарантированный сбой! Обмены по последовательным портам бесконечно медленные с точки зрения процессора ЦП и разговоры о том что обмен перегружает цикл - фуфло. Проблемы могут быть только при использовании usernet, там скорости высоки и при насыщенной "сетевой жизни" нагрузка может получаться значительной, ибо по протоколам сети необходимо реагировать на большое число сообщений...
Разработчики говорят, что минимальное время цикла - это интервал вызова PLC_PRG(и все).Если же вызывать программу с помощью конфигуратора задач, то вызов PLC_PRG отключается, но это время продолжает влиять на обмен по Ehernet. Т.е. получается минимальное время цикла нужно выставлять всегда.По всей видимости программа пользователя крутится вместе с обработчиком Ehernet, причем реализована корпоративная многозадачность.Дмитрий я с вами полностью согласен. Для того чтобы разговор окончился результатом необходимо выработать рекомендации по времени цикла,для плк овен. Разработчики говорят, что уложите программу в 10-15мс и все у вас будет хорошо.Все бы хорошо, но сетевой обмен при таких цифрах реально напрягает, особенно при отладке. Издержки ПЛК без ОС.