|
Повідомлення створено: 29. 11. 2016 [06:53]
|
|
Petr2off
Владимир Петров
Автор теми
Зареєстрован(а) с: 08.07.2015
Повідомлення: 38
|
Доброго дня коллеги. Хотелось бы обсудить одну занятную проблему, с которой я столкнулся.
Стандартная ситуация а АСУ ТП - взаимодействие синхронных процессов. Скажем, есть PLC (izagraf)
которая как slave device в цикле с периодом 40 мс выдает регистры модбус. Есть OpenScada в которой контроллеры modbas с циклом 100 мс осуществляет обмен с PLC. Есть логические контроллеры, которые с циклом 100 мс общаются с контроллерами modbas. Ну и на закуску есть еще цикл проекта, 100 мс.
Вопрос - какое соотношение времен циклов является оптимальным ? Понятно, что есть "технологические" особенности. Скажем в izagrafe 3 - нет аналога контроллеру modbasa OpenScada. Там есть переменные modbas, которые все за раз и выталкиваются. В результате у меня возникала некоторая рассинхронизация со скадой. Потому как посылка была одна и большая а принимало ее несколько источников, которые грубо говоря стартовали одновременно, что приводило к периодическому пропуску чтений последних переменных izagraf. Собственно говоря я поэтому и уменьшил цикл PLC. И тут мне помог полезный инструмент, в контроллере modbas можно посмотреть параметры цикла чтения. Но иногда пропадания все таки имеют место быть.
И тут у меня вопрос возник, а ведь еще у нас в этой цепочке есть логические контроллеры и цикл проекта.
Чем руководствоваться при определении размеров этих циклов ? Скажем в виджетах, я теперь всегда ставлю время цикла в -1, обжегся на том,что при задании конкретного времени у меня иногда события из event не обрабатывались.
Понятно, что скажем время цикла логического контроллера не должно быть меньше цикла modbas контроллера, с которым он связан. С другой стороны - слишком большим его тоже делать не хочется, потому как от этого зависит быстродействие АРМ.
|
|
Повідомлення створено: 29. 11. 2016 [08:37]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"Petr2off" wrote:
Вопрос - какое соотношение времен циклов является оптимальным ?
Несущественно тут и нет проблемы синхронизации с ПЛК вообще, а проблема отсутствия данных связана исключительно с потерей связи и ошибками на канале связи, что будет видно по счётчикам в поле статуса. Единственное условие это то, что периодичность задачи опроса не должна быть больше периодичности самого частого архиватора, когда дыры в архиве очевидны. Скорее всего это некорректный выбор таймаутов или линия связи зашумлена.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 29. 11. 2016 [08:53]
|
|
Petr2off
Владимир Петров
Автор теми
Зареєстрован(а) с: 08.07.2015
Повідомлення: 38
|
Насчет зашумления линии сомнения берут, PLC и Скада соединяются по 10мб ethrnet - все это в одном шкафу находится, как бы я проблем тут не вижу. С другой стороны - когда я сделал соотношения циклов PLC/SCada modbus в 40/100 ситуация улучшилась кардинально.
Про таймаут - тут ничего сказать не могу, там как стояло значение по умолчания 30 сек, так и стоит. Его отработку я вижу, когда сервер скаду останавливаю и поднимаю. Через 30 сек интервейс скада станции поднимается.
С сожалению я более существенно цикл PLC уменьшить не могу, тогда там пропуски начинаются.
|
|
Повідомлення створено: 29. 11. 2016 [09:16]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"Petr2off" wrote:
Насчет зашумления линии сомнения берут, PLC и Скада соединяются по 10мб ethrnet - все это в одном шкафу находится, как бы я проблем тут не вижу. С другой стороны - когда я сделал соотношения циклов PLC/SCada modbus в 40/100 ситуация улучшилась кардинально.
Типа с Ethernet, сетевыми адаптерами и маршрутами проблем не бывает, чего я встречал достаточно!
"Petr2off" wrote:
Про таймаут - тут ничего сказать не могу, там как стояло значение по умолчания 30 сек, так и стоит. Его отработку я вижу, когда сервер скаду останавливаю и поднимаю. Через 30 сек интервейс скада станции поднимается.
Зачем такой огромный? Наверное чтобы обрывы связи по Вашему якобы быстрому и надёжному каналу обнаруживались в течении 30 секунд?
"Petr2off" wrote:
С сожалению я более существенно цикл PLC уменьшить не могу, тогда там пропуски начинаются.
Не исключаю конечно кривизны ПЛК, когда он ячейки данных перед записью новых значений очищает, но тогда Вы бы не дыры в архиве получали!
P.S. Если Вам нравиться находиться в таком заблуждении то я Вас тут переубеждать не буду, кроме того зачем Вы сюда пишете если типа "знаете"?
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 02. 12. 2016 [09:36]
|
|
Petr2off
Владимир Петров
Автор теми
Зареєстрован(а) с: 08.07.2015
Повідомлення: 38
|
На всезнайство я никогда не претендовал, это Вы зря батенька по напраслину гоните.
Далее - данное оборудование применяется у нас на нескольких объектах, и нареканий нет. Поэтому я в этой части копать и не собираюсь. По поводу таймаута, давайте уточним - что Вы имеете ввиду ?
В контроллере modbus есть 2 временных параметра
1) Время ожидания соединения (мс) - 0
2) Время восстановления (с) - 30
Какое время Вы обозначаете как таймаут ?
Как я понял ситуацию в данном конкретном случае соотношение времен циклов оказалось значимым.
Цикл PLC |1111111|222222|33333|-------| (1 - данные для 1 го КМ, 2 - для 2-го, и т.д. итого 100 мс
Скада |1111111|----------------------- -|
|222222|--------------------------|
|33333|----------------------------| В результате 1-й читался без пропусков, во втором иногда были пропуски, в третьем больше.
Конечно это я для примера, на самом деле КМ не 3 а несколько десятков, но принцип такой.
Сокращение цикла PLC ситуацию в корне изменило.
И возвращаясь к содержательной части Вашего сообщения, как я понял речь идет о времени ожидания соединения ? Ну пропуски у меня сейчас минимальные, я их в PLC сижу, Вряд ли Скада что то тут добавляет, но попробую поставить 40 мс - 1 цикл PLC
|
