ПР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 секунды каждый. Так что...

Безымянный.png

[Director]

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

Безымянный.png

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

[Сергей0308]

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

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

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

[Director]

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

[KotoVasya]

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

[KotoVasya]

Овен ТСР.JPG

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

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

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