LepreconSTR
Junior Member / Новичок
Участник № / Member № 7367
отправлено / posted
При обмене по Modbus TCP в случае кратковременном сбое обмена все каналы которые связаны с обменом по сети маркируются флагом программной недостоверности _F. В случае длительного отсутствия связи после ее восстановления флаги недостоверности сбрасываются. А вот в случае кратковременного обрыва (~0.1 сек) флаги программной недостоверности продолжают висеть, а обмен по сети происходит нормально. При этом вручную сбросить флаг нельзя, система обратно выставляет его в _F.
Эксперименты с выдергиванием кабеля были проведены на трех PC с win7. Версия Trace mode 6.10 и 6.10.2 PRO И на каждом эксперименте удавалось рано или поздно прекратить обновление данных на экране в связи выставленной недостоверностью (обмен при этом восстанавливался). Есть ли способ решения данной проблемы? В случае необходимости могу снять видео и прислать логи анализатора трафика с видимым обменом.
Сообщения / Posts 8 | Из / From: RU
| IP / IP: IP адрес / IP address |
отправлено / posted
Данный раздел форума не предусматривает обсуждение проблем профессионального ПО.
У нас нет возможности воспроизвести физический разрыв сетевой связи с последующим восстановлением сетевого подключения в ОС менее чем через 0.1 сек.
В любом случае следует провести протоколирование сетевого обмена с заданием необходимого отладочного ключа в конфигурационном файле *.cnf.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
LepreconSTR
Junior Member / Новичок
Участник № / Member № 7367
отправлено / posted
1. К сожалению коробки с продуктом сейчас нет под рукой, а простым смертным в нужный раздел не напишешь. 2. нет необходимости делать это быстрее чем за 0,1 сек достаточно чуть вытащить коннектор Ethernet до потери контакта и вставить его обратно. 3. На ключе Debug=400 получаю кучу сообщений на каждый полученый пакет после имитации обрыва: ERR_TCP:recieve wrong ident from XXX. Помог с этой болячкой ключ IDENT_OFF (могу ошибаться в точном написании) в файле tcp_modbus. Но правильно ли это?
Сообщения / Posts 8 | Из / From: RU
| IP / IP: IP адрес / IP address |
отправлено / posted
Ключ "IDNT_OFF или IDNT_ON (по умолчанию) – не анализировать или анализировать ID пакетов (ModBus, TCP USER);" Отключение идентификации TCP-пакетов - путь к повышению вероятности сетевых ошибок.
"чуть вытащить коннектор Ethernet до потери контакта " - как регистрируется "потеря контакта"?
Вы искусственно вызываете нарушение потока ответных транзакций и получаете эффект, описанный в первом посте. В любом случае, хотя и с задержкой, после реального восстановления связи и идентификации транзакций достоверность каналов обмена должна восстановиться.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
LepreconSTR
Junior Member / Новичок
Участник № / Member № 7367
отправлено / posted
Ну в том то и вопрос что достоверность восстанавливается но не всегда. Примерно 1 раз из 5-10 достоверность не восстановится. Приходится либо перезапускать МРВ либо еще раз дергать кабель.
quote:как регистрируется потеря контакта
Как отключение сети в сетевых подключениях и прекращение обмена в wireshark. Грубо конечно, но аппаратный обрыв это симулировало
Есть еще один небольшой вопрос, если позволите: Как уменьшить интервал между ERR_TCP? Как видно по рисунку между попытками подключения проходит 20-30 секунд. Необходимо уменьшить это время. Ключи TCP_RECONT и TCP_DICONT видимого эффекта не дали.
Сообщения / Posts 8 | Из / From: RU
| IP / IP: IP адрес / IP address |
отправлено / posted
1. Когда восстанавливается сеть у ПК в сетевых подключениях, в протоколах узла появляется сообщение об установлении связи с Modbus-сервером? И при этом каналы обмена с Modbus-сервером сервером не получают данных? Вы можете провести аналогичное тестирование с использованием, например, ModSim32 или подобного эмулятора?
2. В предыдущем топике Вам рекомендовали "Для контроля и управления обменом по встроенным протоколам предусмотрены следующие ключи в файле *.cnf: ... TCP_DIFCONN<nn>=<число секунд> – таймаут переподключения. В случае ошибки соединения попытка подключения предпринимается спустя время, заданное данным ключом (значение по умолчанию – 30с, nn – номер протокола);
TCP_DISCONN<nn>=<число секунд> – таймаут разрыва соединения. Если в ходе нормального обмена с устройством наступает момент, когда не проходит посылка, то сокет не уничтожается, а в течение времени, заданного данным ключом, примерно 1 раз в 10с предпринимается попытка повторной отправки посылки. Если отправить посылку не удается, по истечении таймаута сокет уничтожается. Значение данного таймаута по умолчанию – 0, что соответствует уничтожению сокета через 1 минуту;"
Printer-friendly view of this topic
![[Улыбка / Smile]](smile.gif)
