ПР205

[zakhar81]

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

[capzap]

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

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

[zakhar81]

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

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

[zakhar81]

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

[zakhar81]

Нужно затычку ставить на прием пакетов которые не может переварить ПР205, без этого глюки будут, мы так работать не можем и у других будет такая же проблема при работе через интернет
Конечно я думаю что мы сейчас попробуем исходя из вышеописанных наших умозаключений костыль придумать для невозможности отправки запроса со стороны сервера на пр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
Что-ж это вы так неосторожно...