ПР205

[zakhar81]

Почитайте:

https://mizakona.ru/kak-rabotaet-mex...-svyazi-v-tcp/

http://dan.spb.ru/tcp_ip/tcp21.html

https://www.geeksforgeeks.org/packet...ng-in-routers/

[zakhar81]

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

ЗЫ вот же


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

Сейчас так
5 секунд цикл
Ожидание еще 5 сек или пауза у некоторых называется, потом сброс и дальше поехали
Таким образом при просадке скорости или связи после ёё восстановления уже не такое большое число пакетов долетает до ПР и более менее стабильно себя ведет, иногда ресетится но в памяти хотя бы переменные не съезжают
При этом после ресета один фиг подключиться с отладкой невозможно, ОЛ пишет что программа в приборе отличается от той что в ОЛ, что происходит с ним фиг знает
Поэтому нужно устранять, так работать не возможно

[capzap]

Так еще и сам механизм передачи TCP предусматривает гарантированную доставку пакетов, и вот если ответ не пришел мастеру ModBusTCP через время ожидания/паузу которые в настройках то мастер посылает следующий запрос. Таким образом, если пакеты на которые не было ответа "застряли" в буферах сетевого оборудования то вот этот механизм обеспечит их доставку как только разгрузка произойдет по траффику и на ПР они могут потом прилететь все сразу

Хотите сказать что условный Бил Гейтц когда то послал пакет в никуда и он досих пор где то бегает по сети, чему равны TTL и/или MSL в Вашем случае?

[zakhar81]

Нужно затычку ставить на прием пакетов которые не может переварить ПР205, без этого глюки будут, мы так работать не можем и у других будет такая же проблема при работе через интернет
Конечно я думаю что мы сейчас попробуем исходя из вышеописанных наших умозаключений костыль придумать для невозможности отправки запроса со стороны сервера на пр205 даже после истечения таймаута
Но это все гемор

[capzap]

Сейчас так
5 секунд цикл
Ожидание еще 5 сек или пауза у некоторых называется, потом сброс и дальше поехали
Таким образом при просадке скорости или связи после ёё восстановления уже не такое большое число пакетов долетает до ПР и более менее стабильно себя ведет, иногда ресетится но в памяти хотя бы переменные не съезжают
При этом после ресета один фиг подключиться с отладкой невозможно, ОЛ пишет что программа в приборе отличается от той что в ОЛ, что происходит с ним фиг знает
Поэтому нужно устранять, так работать не возможно

Если Вы с терминами не разобрались, просто выкладывайте лог обмена и станет все понятно, где есть ответы на запросы, а где не дождавшись ответа сыпется очередной запрос, по времени сразу станет ясно какой там аут подойдёт для настроек мастера

[zakhar81]

Хотите сказать что условный Бил Гейтц когда то послал пакет в никуда и он досих пор где то бегает по сети, чему равны TTL и/или MSL в Вашем случае?

Ну давайте без сарказма, а то что пакеты долетают, в моменте, после разгрузки сети то по концепции TCP это так, в отличии от UDP
Это на наших глазах было, пару случаев, когда роутер выдергивали изи WAN и после того как воткнули произошел ресет ПР205
Давайте тогда от ОВЕНа сделают пусть UDP вариант

[zakhar81]

В локалке может обычный свитч использоваться и там да только мастером ModBusTCP определяется отсылка пакетов до ПР205

[capzap]

Нужно затычку ставить на прием пакетов которые не может переварить ПР205, без этого глюки будут, мы так работать не можем и у других будет такая же проблема при работе через интернет

Что за бред, как только это сделают, появляться пользователи у которых будет пропадать информация и они будут обвинять в этом эту переделку, на уровне ТСР ни одно прикладное приложение не работает, им достаточно своего уровня в сетевой модели

[zakhar81]

Бред - это перезагрузка ПР205
Защита от переполнения должна быть, косяк именно в этом, поскольку после этого в памяти ПР205 с переменными да и самой программой не пойми что
В локалке проблемы нет такой, мы тоже испытывали как и ОВЕН
Время терять на это или сервер ставить в ИТП дома чтобы через него с ПР-ми обмен был уже в локалке не вариант
Нам проще тогда свой контроллер собрать под серийную задачу, на базе ARM или AVR и прилепить планшет 5-7 дюймовый на морду шкафа, DWIN например, в сумме дешевле ПР205 будет и заниматься отладкой этого девайса так же как сейчас бьемся с ПР205, так хоть не жаль времени будет на это потратить, свое изделие
Брали ПР205 для альтернативы Segnetics SMH4, по цене и доступности по срокам в 2023-м году

[ПавелП]

Бред - это перезагрузка ПР205
Защита от переполнения должна быть, косяк именно в этом,

ОВЕН даже если попытается что-то исправить - это много времени уйдёт...
Я же грю вам - подстраивайтесь, меняйте свой алгоритм.
Увы. Иначе грабли не обойти.

так хоть не жаль времени будет на это потратить, свое изделие

Солидарен. Я потратился 20 лет назад, и всякие мелочи ими и решаю.
"Самый короткий путь тот, который ты знаешь" (c)

Брали ПР205 для альтернативы Segnetics SMH4, по цене и доступности по срокам в 2023-м году

Красивые контроллеры, и возможности фантастические. Linux
Что-ж это вы так неосторожно...