ПР205 - Минимизация задержек в режиме мастера

[Director]

Доброго дня! Со дня на день ввожу в эксплуатацию свою программу на пр205 на объект, где проектом предусмотрено использование устройства из серии программируемых реле. Перейду сразу к делу.
Пр205 с временем цикла в районе 15 мсек работает в режиме мастера modbus tcp в связке с модулями овен (Ai - 8 к, 2 x Di по 32 каждый, 2 x Do по 16 и 1 Do 24 канала для общей картины). Опрашивается 6 устройств. Дискретные опрашиваются по одному запросу на каждое устройство. Аналоговый модуль опрашивается на 8 регистров с группировкой по 8. Программа с множеством таймеров рассчитана на практически мгновенную реакцию на какие либо изменения по статусу дискретных входов. Понятно что такое недостижимо и хотелось бы уложиться в 0,2 - 0,3 секунды. На настройках мастера по умолчанию был проведен тест времени задержки на получение ответа с использованием связки ПР205 + ПР 100ой серии. По результатам теста имел плавающую задержку от 0,1 сек и порой даже до 7 секунд. В среднем 0,8 сек. Правками периода чтения и таймаута ответа путем занижения значений удалось стабилизировать на значениях не больше 0,8 секунд, что так-же нежелательно. Предполагаю, что имею дело с последовательным опросом устройств с учетом запроса-ответа, а не параллельным, как ожидалось. К сожалению не имею вагона времени на детальный поиск решения. Хотелось бы услышать умные мысли касательно данной проблемы и советов как поступить правильнее.
UPD: Связка пр205 + 6 модулей в отдельной подсети.

[Сергей0308]

Доброго дня! Со дня на день ввожу в эксплуатацию свою программу на пр205 на объект, где проектом предусмотрено использование устройства из серии программируемых реле. Перейду сразу к делу.
Пр205 с временем цикла в районе 15 мсек работает в режиме мастера modbus tcp в связке с модулями овен (Ai - 8 к, 2 x Di по 32 каждый, 2 x Do по 16 и 1 Do 24 канала для общей картины). Опрашивается 5 устройств. Дискретные опрашиваются по одному запросу на каждое устройство. Аналоговый модуль опрашивается на 8 регистров с группировкой по 8. Программа с множеством таймеров рассчитана на практически мгновенную реакцию на какие либо изменения по статусу дискретных входов. Понятно что такое недостижимо и хотелось бы уложиться в 0,2 - 0,3 секунды. На настройках мастера по умолчанию был проведен тест времени задержки на получение ответа с использованием связки ПР205 + ПР 100ой серии. По результатам теста имел плавающую задержку от 0,1 сек и порой даже до 7 секунд. В среднем 0,8 сек. Правками периода чтения и таймаута ответа путем занижения значений удалось стабилизировать на значениях не больше 0,8 секунд, что так-же нежелательно. Предполагаю, что имею дело с последовательным опросом устройств с учетом запроса-ответа, а не параллельным, как ожидалось. К сожалению не имею вагона времени на детальный поиск решения. Хотелось бы услышать умные мысли касательно данной проблемы и советов как поступить правильнее.

Мне кажется для сигналов где требуется максимальное быстродействие лучше применить модули расширения по внутренней шине:
https://owen.ru/product/prm
А остальные, где не требуется максимального быстродействия по сети.

[Валенок]

Если опрашивать только 2x Di (на остальное временно болт) - задержка норм?

[kondor3000]

Если нужны минимальные задержки, то надо было использовать ПЛК110-60 (36 входов, 24 выхода) и модули с RS485.
Оптимизировать программу, выкинуть кучу таймеров.

[Dimensy]

Я не понял. Вы тест проводили на связке ПР205 - ПР100? Но это же RS-485. А модули у вас по Ethernet опрашиваются - там, насколько я помню 4 потока и скорости совсем другие
А еще, модуль с аналоговыми входами эти самые входа опрашивает со скорость не менее 0,5 секунды каждый. Так что...

85363

[Director]

Я не понял. Вы тест проводили на связке ПР205 - ПР100? Но это же RS-485. А модули у вас по Ethernet опрашиваются - там, насколько я помню 4 потока и скорости совсем другие
А еще, модуль с аналоговыми входами эти самые входа опрашивает со скорость не менее 0,5 секунды каждый. Так что...

85363

Пр103 если быть точнее, ethernet. Связку использовал для тестирования работы алгоритма в реальных условиях, а не только в симуляции, которая может вести себя по разному (ну может годами раньше было так), и параллельно заметил такую особенность в задержке. Пр103 висело как 7 слэйв устройство по одному регистру принимающее и в другой свой регистр записывающее ответ. Пр205 считывал разницу во времени в записи и считывании с этих регистров в роли мастера. В данный момент не имею возможности покрутить её в руках для дальнейших экспериментов. Может ли помочь увеличить период опроса устройства аналогового ввода, для уменьшения задержки считывания дискретных, пусть даже незначительной?
Да и хотелось бы узнать приемлемые параметры опроса под мои задачи.

[Сергей0308]

Пр103 если быть точнее, ethernet. Связку использовал для тестирования работы алгоритма в реальных условиях, а не только в симуляции, которая может вести себя по разному (ну может годами раньше было так), и параллельно заметил такую особенность в задержке. Пр103 висело как 7 слэйв устройство по одному регистру принимающее и в другой свой регистр записывающее ответ. Пр205 считывал разницу во времени в записи и считывании с этих регистров в роли мастера. В данный момент не имею возможности покрутить её в руках для дальнейших экспериментов. Может ли помочь увеличить период опроса устройства аналогового ввода, для уменьшения задержки считывания дискретных, пусть даже незначительной?
Да и хотелось бы узнать приемлемые параметры опроса под мои задачи.

Мне кажется в принципе нет смысла опрашивать модули аналогового ввода чаще, чем период обновления значений на их входах!

Здесь не форум ясновидящих, в смысле, мы не знаем ваши задачи, может Вы термоядерным реактором управляете, а может среднегодовую температуру высчитываете, как бы для Вас это странно не показалось, но кроме Вас ваши задачи никто не знает!

[Director]

Соглашусь как минимум с одним - заложить ethernet модули для моих задач было опрометчиво. На объекте производится управление гидравлической системой и множеством движков. Некоторые задержки потенциально могут привести к фатальным последствиям.

[KotoVasya]

В промышленном оборудовании для связи приводов с контроллером обычно применяют Ethercat. А Ethernet на 100 Mbps, да ещё и через TCP/IP вместо UDP - это не самый быстрый вариант для realtime.

[KotoVasya]

85510

А те же ПР-ки вообще поддерживают только ОДНО TCP-соединение, и опрос больше одного устройства в сети напоминает анекдот:

Катится колобок.Навстречу ему едут три богатыря.
- Здравствуй, Илья Муромец.
- Здравствуй, Колобок.
- Здравствуй, Добрыня Никитич.
- Здравствуй, Колобок.
- Здравствуй, Алёша Попович.
- Здравствуй, Колобок.
- Здравствуй, конь Ильи Муромца.
- Здравствуй, Колобок.
- Здравствуй, конь Добрыни Никитича.
- Здравствуй, Колобок.
- Здравствуй, конь Алёши Поповича.
- Здравствуй, Колобок.
- До свидания, Илья Муромец.
- До свидания, Колобок.
- До свидания, Добрыня Никитич.
- До свидания, Колобок.
- До свидания, Алёша Попович.
- До свидания, Колобок.
- До свидания, конь Ильи Муромца.
- До свидания, Колобок.
- До свидания, конь Добрыни Никитича.
- До свидания, Колобок.
- До свидания, конь Алёши Поповича.
- До свидания, Колобок.

Катится колобок дальше. Навстречу ему идут Али-баба и сорок разбойников.
- Здравствуй, Али-баба.
- Иди-ка ты в пень, колобок! Мы торопимся!

[KotoVasya]

85511855128551385514
Взял я OWEN ПР225 с прошивкой v.1.9.1, пару OWEN МВ210-212 с прошивкой v.g1.2.0 и комп под Win7x64 с весьма полезной утилитой-сниффером "Акула Варя шаркает :-)" Wireshark Ver. 4.0.17. Соединил их всех через хаб Phoenix Contact FL HUB 8TX-ZF (чёрный кабель - к компу).

[KotoVasya]

85515855168551785518
Через OWEN Конфигуратор МВ-шке с MAC адресом E4:1E:0A:0A:4B:38 задал IP адрес 192.168.0.212, а второй, что с MAC E4:1E:0A:0A:4B:39 присвоил IP 192.168.0.213 соответственно.
В OWEN Logic этому ПР225 с MAC-адресом E4:1E:0A:09:06:EC присвоил IP-адрес 192.168.0.2 (под адресом 192.168.0.1 в этой сети сидит комп), накидал простейшую прогу для чтения из первой МВ-шки пары 16bit регистров c адресами 51 и 52 в одну 32bit переменную ПР225 и отображения её в десятичном виде на экране.
Залил прогу в ПР225, закрыл OWEN Logic (чтобы в сети лишними пакетами картинку не усложнял), выключил ПР, запустил "акулье шарканье :-)", включил ПР.
И что я таки вижу?

[KotoVasya]

Эх, пришлось в цех сходить, а тут и рабочий день закончился. Завтра выложу скрины обмена.

[KotoVasya]

85523

Сначала идёт перекличка на протоколе ARP. В первом пакете ПР225 кричит так, чтобы слышали все (broadcast): "Всем!Всем!Всем!(MAC FF:FF:FF:FF:FF:FF)! Мой MAC E4:1E:0A:09:06:EC, мой IP 192.168.0.2! Чей IP 192.168.0.212? Ответь мне, назови свой MAC-адрес!". Во втором пакете первый МВ210-212 ему и отвечает: "Мой MAC E4:1E:0A:0A:4B:38, это мой IP адрес 192.168.0.212!". Всё, у кого в сети какие MAC и IP адреса разобрались. Хитрая Акула Варя заменила первую часть (код производителя) MAC-адреса (E4:1E:0A) на текст "Zavod№42".

Потом идёт установка соединения на протоколе TCP. В третьем пакете ПР225 (IP 192.168.0.2) предлагает (флаг SYN) первому МВ210-212 (IP 192.168.0.212) вступить в связь через TCP/IP. В четвёртом пакете МВ210-212 (IP 192.168.0.212) соглашается (флаг ACK) вступить в связь c ПР225 (IP 192.168.0.2) и спрашивает (флаг SYN) у ПР225, а хочет ли тот сам вступать в связь с ней. В пятом пакете ПР225 подтверждает (флаг ACK), что действительно хочет вступить в связь через TCP/IP с МВ-шкой.

И только с шестого пакета они начинают "вальсировать" ("раз-два-три, раз-два-три, раз-два-три") по три пакета (6-7-8, 9-10-11, 12-13-14) и так далее. В шестом пакете ПР225 (IP 192.168.0.2) через вложенный в "обёртку" протокола TCP/IP запрос на протоколе Modbus (6 байт полезной нагрузки) спрашивает МВ210-212 (IP 192.168.0.212): "Что там в регистрах 51 и 52?". В седьмом пакете МВ210-212 (IP 192.168.0.212) отвечает ПР-ке: "Вот четыре байта: старший байт регистра 51, младший байт регистра 51, старший байт регистра 52, младший байт регистра 52" (7 байт полезной нагрузки Modbus). И, наконец, в восьмом пакете ПР225 (IP 192.168.0.2) подтверждает (флаг ACK) приём предыдущего (седьмого) пакета от МВ210-212 (IP 192.168.0.212): "Принял!". Дальше история повторяется, по три пакета на каждый обмен.

Итого затраты на передачу ЧЕТЫРЁХ байт (два 16bit регистра): 5 пакетов х 60 байт = 300 байт на установку соединения, и по 66 + 67 + 60 = 193 байта на каждую передачу. При скорости 100 Мбит/с это весьма быстро.

[KotoVasya]

8552585526
Далее я проверил связь со второй МВ-шкой (IP 192.168.0.213) - всё так же, как и с первой.

[KotoVasya]

8552785528
Потом я добавил в прогу для ПР225 вторую МВ-шку вторым slave с чтением и отображением её регистров 51 и 52 аналогично первой МВ-шке. Снова залил прогу в ПР225, закрыл OWEN Logic, выключил ПР, запустил Wireshark, включил ПР. И вот тут начался анекдот про Колобка.

[KotoVasya]

85530
В первых пяти пакетах ПР225 установил TCP/IP соединение со второй МВ210-212 (IP 192.168.0.213). Почему он начал не с первой, не знаю. Далее, в 6 и 7 пакетах идут запрос и ответ, а в восьмом пакете ПР225 вместо выдачи подтверждения (флаг ACK, "Принял!") получения ответа, снова выдаёт запрос МВ-шке. Так они "вальсируют" (уже с подтверждениями) восемь раз, и вдруг в 34-м пакете ПР225 вместо выдачи очередного подтверждения внезапно вспоминает о первой МВ210-212 (IP 192.168.0.212), которая сразу же, в 35-м пакете, ему отзывается. В 36-м пакете ПР225 подтверждает (флаг ACK) приём 33-го пакета от второй МВ210-212 (IP 192.168.0.213) и заявляет о прекращении TCP/IP соединения с ней (флаг FIN, "Финиш!"). В 37-м пакете ПР225 уже хочет (флаг SYN) вступить в TCP/IP связь с первой МВ210-212 (IP 192.168.0.212), не дожидаясь "развода" со второй МВ210-212 (IP 192.168.0.213). Интересный момент: ПР увеличивает номер своего порта на единицу при каждом новом TCP/IP соединении (1461 > 1462 в данном случае), при этом порт назначения в slave, естественно, остаётся прежним, как я и указал в настройках (502 mbap - modbus application protocol). В 38-м пакете вторая МВ-шка подтверждает получение запроса на завершение соединения, и в 41-м пакете подтверждает "развод" с ПР225 (флаги FIN и ACK). А ПР-ка уже в 39-м, 40-м и 42-м пакетах устанавливает TCP/IP соединение с первой МВ-шкой, после чего они успевают совершить только один обмен полезной Modbus-информацией (пакеты 43 и 44), и ПР-ка в 45-м пакете уже требует "развода" с ней. В 46-м пакете ПР снова запрашивает (флаг SYN) соединение со второй МВ210-212 (IP 192.168.0.213), получая ответ с подтверждением от неё в 48-м, и подтверждая этот ответ в 49-м. В 47-м пакете первая МВ-ка подтверждает получение запроса на завершение соединения, и в 51-м пакете подтверждает "развод" с ПР225. Что и кому в 50-м пакете подтверждает ПР225, запуталась даже акула Варя :-)))

[KotoVasya]

8553185532
И такая дребедень - целый день! Чехарда с установкой соединения, одним-единственным полезным обменом (два пакета), и последующим разрывом "отношений" с каждой из двух МВ-шек входит в цикл из 9 пакетов, общим объёмом (60 х 7) + 66 + 67 = 533 байт. Вот так вот, на то, чтобы гарантированно передать 4 байта (пара регистров), уходит чуть больше полкилобайта служебной информации. И это при двух slave в сети, а при 10 задержки будут заметны даже на 100 Мбит/с.

[KotoVasya]

855338553485535
Попробовал я подключить вторую МВ-шку отдельным кабелем (жёлтым) напрямую к хабу (который я ошибочно называл коммутатором), минуя маршрутизатор (который оказался коммутатором) в первой МВ-шке - ничего не изменилось, так же сначала соединение со второй МВ-шкой, тот же цикл из девяти пакетов на опрос каждой МВ-шки, и та же смена номера порта ПР-ки при каждом новом соединении.

[imaex]

855338553485535
Попробовал я подключить вторую МВ-шку отдельным кабелем (жёлтым) напрямую к коммутатору, минуя маршрутизатор в первой МВ-шке

А где Вы маршрутизатор в МВ обнаружили? Его там отродясь не было. Да и не по чину, вообще-то.

Я тут пригляделся - а где Вы изернет-хаб отрыли? На блошином рынке прикупили или собственную кладовку хлама разграбили?

[KotoVasya]

А модули у вас по Ethernet опрашиваются - там, насколько я помню 4 потока
Не знаю, где там 4 потока. Я не спец по сетям, поэтому не понимаю, почему нельзя вести обмен пакетами сразу по двум TCP/IP соединениям. Да и смена номера порта каждый раз тоже выглядит странно.

[KotoVasya]

А где Вы маршрутизатор в МВ обнаружили? Его там отродясь не было. Да и не по чину, вообще-то.

Я тут пригляделся - а где Вы изернет-хаб отрыли? На блошином рынке прикупили или собственную кладовку хлама разграбили?

Хаб валялся у рабочих в слесарке на полке среди всякого хлама, видимо, снят со списанного литейного комплекса. Оказался вполне живой.
А в МВ-шке, похоже (я не разбирал, но прозвонил тестером), стоят пара реле, через нормально замкнутые контакты которых разъёмы Ethernet 1 и Ethernet 2 соединены (RX>TX, TX>RX) при отключенном питании МВ-шки, а через нормально разомкнутые - перекидываются на две отдельных сетевых порта. При запуске МВ-шки раздаётся щелчок, и пакеты, адресованные самой МВ-шке через один разъём (а также исходящие от неё в ответ), не проходят на второй, значит, между этими двумя портами есть маршрутизатор. Хотя, я только начинаю изучать сеть, и, конечно, могу ошибаться.

Если взять одну МВ-шку, подключить к одному её разъёму ПР-ку, а ко второму - комп, то пакеты обмена между ПР и МВ на порт компа дублироваться не будут, это заметно даже по миганию светодиодов на самой МВ-шке. При этом можно с компа опрашивать МВ-шку (с помощью эмулятора Modbus TCP Master), и на ПР передавать пакеты через МВ. Именно поэтому я применил хаб.

[imaex]

значит, между этими двумя портами есть маршрутизатор.

Коммутатор. Там 2-хпортовый коммутатор.

[KotoVasya]

Коммутатор. Там 2-хпортовый коммутатор.
Спасибо большое!
Я ещё только начинаю разбираться в этих сетях, и считал хаб синонимом коммутатора. Благодаря Вашей подсказке я ещё раз перечитал статьи про хабы, коммутаторы и маршрутизаторы и вот что понял:
Хаб (синоним - концентратор) - это и есть мой Phoenix Contact FL HUB 8TX-ZF. Он умеет только тупо передавать пакет с одного разъёма сразу на все остальные разъёмы (кроме тех, к которым ничего не подключено). Все подключенные к нему устройства получают этот пакет и должны сами смотреть по MAC-адресу, кому он предназначался.
А коммутатор (он же свитч), уже более "умное" устройство, само составляющее и хранящее в свой памяти таблицу, к какому разъёму подключены устройства с какими MAC-адресами. Значит, в МВ210-212 находится коммутатор, который по MAC-адресу получателя пакета (как раз первые 6 байт пакета) решает, передавать полученный пакет на второй разъём, или "оставить себе", если это его MAC-адрес.
Про маршрутизатор (он же роутер) я понял, что это вообще целый мини-компьютер под своей ОС (типа Линукса), который может менять IP-адреса внутри пакета, соответственно обмениваться пакетами с другими сетями и быть шлюзом в интернет. Для МВ-шки с её простенькой прошивкой это, конечно, слишком круто :-)

[KotoVasya]

8554385542
Вот, я даже гифки нашёл.

[imaex]

Спасибо большое!
Хаб (синоним - концентратор)
А коммутатор (он же свитч)


В целом верно.
Хаб - репитер, т.е. повторитель. На одной из первых фоток так и написано на нём.
Коммутатор - много(2 и более)портовый мост. Свитч - просто калька с англ.