А если через WAN не снижать опрос, а просто увеличить паузу между запросами? если ПО позволяет конечно.
А если через WAN не снижать опрос, а просто увеличить паузу между запросами? если ПО позволяет конечно.
Для TCP есть особенность в отличие от UDP в том что есть механизм повторной передачи пакетов при их потере(пропусках) в моменты перегрузок сетевого оборудования
https://russianblogs.com/article/64722230277/
Возможно при больших таймаутах в итоге на ПР205 прилетают куча потерянных пакетов и он не может этого пережить
Я не гуру в этой области но я не знаю как это объяснить
Ну вот я вообще думаю динамически это менять со стороны мастера (сервера), читать секунды с ПР205 или с другого устройства за маршрутизатором в той же локалке что и ПР205 и менять цикл опроса в зависимости от пропускной способностиСообщение от melky
я не про таймауты. Тем более у вас ПР205 сервер, то есть слейв. А клиент некий ПК со Scada или чем там? Если Scada позволяет, сделайте циклический опрос или не реже раза в 1с , но с паузой между запросами и все это через WAN.
Мастер это как раз клиент, а Сервер это ПР.
Добрый вечер
Под сервером я подразумевал диспетчерский сервер на котором запущен мастер ModBusTCP который опрашивает слейвы - ПР205 через WAN
Но сам ПР205 он же слейв котрый функционально является сервером ModBusTCP для нашего мастера который запущен на диспетчерском сервере (в том смысле что он является тоже сервером у которого, в свою очередь есть уже группа клиентов получающих данные с него.
Короче каламбур со словами получился и все запутались!)
У меня так и было, как Вы говорите, с интервалом 1 сек диспетчерский сервер опрашивал ПР205-ые, через WAN, у которых фиксировались описанные выше в этой теме глюки с перезагрузками
И после всяческих опытов и переделок уменьшили интенсивность запросов до периода 30 секунд и глюки все как рукой сняло
В локалке к с тати работает без проблем с циклом 100 мс
Сейчас 10 секунд сделали интервал между запросами со стороны сервака тоже нормально
Запросы на запись группы регистров вообще сделали только по изменению параметров
Почему так работает через WAN не понятно, видимо влияет пропускная способность сетевого оборудования, но почему это приводит к обнулению или попаданию не пойми каких значений в переменные и перезагрузке ПР205 я не понимаю.
Тут кто то писал что разводка неправильная, ну пусть она была бы не правильная, но при чем тут глюки со значениями переменных? Это только программная часть не физическая
А что касается разводки или схемотехники, то у нас все развязано гальванически. Источник питания на дискретную периферию отдельный, сигналы с этой периферии дискретной (реле давления и т.п.) на обмотки реле а контактные группы этих реле используют 24В с внутреннего источника ПР205 и на его же дискретные входы сигнал коммутируют. Аналоговые выходы тоже с внутреннего источника так же питаются через барьеры 4-20мА на внешние управляемые краны уходят, и соответственно не связаны гальванически с их источником питания. Аналоговые входы - термометры сопротивления, тоже ни с чем не связаны
Короче нужно разбираться с сетевым обменом TCP через WAN но времени нет на лабораторные эксперименты
Может наши разработчики из овена соберутся силами и проведут испытания с обменом ПР205 через WAN и чего нибудь отловят
Последний раз редактировалось zakhar81; 25.01.2024 в 16:45.
я говорю не про интервалы запросов, а про паузу между ними.
У меня не пачка из 45-ти запросов для 45-ти регистров, у меня один запрос на все 45-регистров длиной 118 байт, максимально разрешенная длина 125 (регламентируемая для протокола ModBus TCP)
Поэтому у меня интервал и пауза это одно и тоже, как в ШИМ сигнале
Если бы я каждый регистр отдельно опрашивал то у меня была бы пачка из 45 запросов с каким то временным промежутком между ними или точнее сказать смещением каким то аппаратным (не поддающимся настройкам) и циклом или паузой между отправкой запросов/пакетов
Немного из информационных материалов касаемо протоколов TCP и UDP
1. TCP протокол подразумевает повторную передачу пакетов по которым не пришло подтверждения доставки от удаленного хоста, при чем неоднократно 12 попыток с экспоненциальным увеличением периода каждой последующей повторной отправки вплоть до 64 сек, потом сброс и выставление флага о недоступности
http://dan.spb.ru/tcp_ip/tcp21.html
2. Маршрутизатор или роутер при маршрутизации пакетов может помещать их в стек своей оперативной памяти или в так называемую очередь и потом чуть позже их "выплевывать" в сеть
https://www.geeksforgeeks.org/packet...ng-in-routers/
Из этого можно сделать вывод, как я предполагал выше, в одном из своих сообщений, что при потерях связи и её восстановлении эти пакеты могут пачками одним разом прилететь на ПР205 и его аппаратная часть или программно аппаратная часть с этим не справляется. В локальной сети такие проблемы при испытаниях будет проблематично имитировать, потому как если тупо выключить питание или выдернуть сетевой кабель у коммутатора, то ясен пень он там из буфера никакие пакеты не выплюнет, у него это не предусмотрено функционально в отличии от маршрутизатора или роутера. А вот связь через интернет (WAN) имеет достаточно много узловых точек с маршрутизаторами и при потерях связи механизм повторной передачи пакетов я думаю пытается обеспечить их доставку и долбит наш ПР205 как надо, после восстановления связи после таймаутов. У нас их на одном объекте только два наших, не считая провайдера местного и маршрута через остальные узлы самой WAN.
Если на форуме есть специалисты в области сетевых технологий опровергните или подтвердите то что я тут написал
Последний раз редактировалось zakhar81; 25.01.2024 в 19:52.
не надо рассказывать лишнего. Банальный пример. Циклический опрос с таймаутом, достаточным при приеме ответа даже при задержках + пауза между запросами скажем 300мс.. Используемое вами ПО вообще позволяет так настроить?
Пусть в сумме это будет не раз в 1с а чуть больше. Будут перезагрузки ПР или прекратятся ?
Конечно позволяет, таймаут это максимальное время ожидания ответа, после которого ожидание ответа заканчивается и выставляется флаг ошибки, у меня он 15 сек, а цикл опроса 10 сек он же и есть пауза между запросами
Ваши права
Ответить с цитированием