я не про таймауты. Тем более у вас ПР205 сервер, то есть слейв. А клиент некий ПК со Scada или чем там? Если Scada позволяет, сделайте циклический опрос или не реже раза в 1с , но с паузой между запросами и все это через WAN.
Мастер это как раз клиент, а Сервер это ПР.
Добрый вечерСообщение от melky
Под сервером я подразумевал диспетчерский сервер на котором запущен мастер 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 сек он же и есть пауза между запросами
Нет, пауза между запросами это другое. При опросе раз в 10 сек на нее плевать, а вот при циклическом или раз в 1с это может повлиять.
таймаут у вас бешенный, обычно столько не требуется даже в радио преобразователе RS485 вполне хватало 3с.
Не сразу понял про вашу паузу, это время ожидания ответа на запрос, и да у некоторых это действительно пауза называется, в том числе у овеновского OPC
Пробовал разные варианты, от 1 секунды до 5 секунд, наиболее устойчиво работает начиная от 5 секунд, т.е цикл 5 сек и ожидание (пауза) еще 5 секунд
При тестировании сети в разные дни бывает не одного пакета не теряется и ответы на запросы прилетают через 30-80 мс, не пинги узла а именно ответы от ПР205.
А бывает что и 5 секунд не хватает, тогда через таймаут (он тоже настраивается) наш сервак (мастер) срабатывает сессию и запускает пакеты заново.
Добрый вечер
Еще раз настаиваю на проверке закидывания ПР205 пакетами при появлении связи после её потери
Нужна защита от этого, это имеет место быть
Мы выбрали интервал 5 сек и время ожидания 5 сек, но ПР205 и через 100 мс отвечает неплохо, но стоит прервать связь и потом тысячи пакетов недоставленных кладут Пр205 набок и он перезагружается и переменные в памяти обнуляются или съезжают, видимо из за переполнения буфера в памяти отводимого под прием с порта.
Я больше никак не могу объяснить такое поведение, нужно сделать защиту от прилета кучи пакетов
При цикле 5 сек при замирании связи ПР205 видимо как то вывозит прилетающие недоставленные пакеты, но все же иногда перезагружается и всегда при этом я не могу запустить отладку на таких перезагруженных ПР-ах, в них не та программа что в ОЛ, про это я писал неоднократно.
Проблема не решена, увеличив цикл мы вставили костыль, но это не решение
Испытайте все таки уже обмен через интернет а не по локалке.
Вот, можете почитать:
https://mizakona.ru/kak-rabotaet-mex...-svyazi-v-tcp/
Ваши права
Ответить с цитированием