Разрыв соединения после первой ошибки по таймауту при чтении по Modbus-TCP

[rsv]

Суть проблемы:
- при периодическом опросе по протоколу Modbus-TCP если возникает ошибка 56, то соединение сразу разрывается.

Насколько я знаю, протокол Modbus-TCP не требует обязательного переподключения при возникновении ошибки. Другие приложения, опрашивающие в это время ПЛК после возникновения ошибки не теряют соединения и продолжают опрос.

Как-то можно избежать разрыва соединения если возникает ошибка 56?

Ошибка №1:
LabVIEW: (Hex 0x38) The network operation exceeded the user-specified or system time limit.

Ошибка №2 и все последующие:
LabVIEW DSC: The communication between the Modbus master and slave devices was interrupted. Check the connection status between the two devices.

P.S.
Приведённая программа тестовая, специально написал, что бы разобраться в этой проблеме.

[ujin1]

Суть проблемы:
- при периодическом опросе по протоколу Modbus-TCP если возникает ошибка 56, то соединение сразу разрывается.

Можно выяснить кем разрывается соединение. Wireshark покажет.
В Вашей программе нет блоков, которые разрывают соединение по таймауту
В описании ошибки присутствует LabVIEW DSC. Может в нем что-нибудь.
Другие программы могут разрывать соединение и снова устанавливать. И так несколько (обычно 3) попыток. При этом разрыва соединения показывать не будут.
В Modbus-TCP есть Transaction ID. Если ответ не пришел во время, возможно он придет позже. Так как устройство может задержать ответ или сетевая карта занята. Ответ придет на то же соединение и будет с предыдущим Transaction ID.
До LabVIEW 19 это поле не использовалось и я такой эффект получал (ответ на предыдущий запрос).
Поэтому при ошибке ответа нужно закрыть соединение и открыть снова. Такая ситуация не должна быть часто. Несколько раз в день приемлемо. Если чаще, то нужно смотреть таймауты, нагрузку ПЛК, нагрузку компьютера.
Wireshark все покажет.

[rsv]

Такая ситуация не должна быть часто. Несколько раз в день приемлемо. Если чаще, то нужно смотреть таймауты, нагрузку ПЛК, нагрузку компьютера.
Wireshark все покажет.

Такая ситуация возникает на каждую ошибку по превышению таймаута. Сначала думали, что случайность, потом ПЛК специально нагрузили что бы иногда выдавал ошибки и всё посыпалось. Это по наблюдениям за неделю на нескольких ПК.
Проблема, похоже, в самой LabVIEW.
Статистика ответов ПЛК на запросы по modbus-TCP из другой проги на скриншоте.

Буду разбираться с Wireshark.

[ujin1]

Буду разбираться с Wireshark.

Посмотрите мои наработки https://github.com/ujin117/LabVIEW-Modbus-API. Обновил до текущего состояния.
Прям сейчас экспериментальная установка на этой библиотеке работает.
Стандартную библиотеку переделал и добавил непрерывный опрос. Как раз с переподключением. Сложновато получилось, хотя и примеры есть.
Если будете пробовать нужно папку со стандартной библиотекой удалить в корзину. Потом можно восстановить. Так ничего не поломается.

[rsv]

Посмотрите мои наработки https://github.com/ujin117/LabVIEW-Modbus-API.

Спасибо, сначала попробую разобраться со штатной библиотекой.

WireShark показала следующее:
В какокй-то момент контроллер не отвечает на один запрос приложения и после этого всё рушится. Хотя приложение продолжает посылать запросы, а контроллер продолжает исправно отвечать.

На приведённом скриншоте контроллер не ответил на транзакцию 122. Последнее значение из ПЛК, показанное на форме относится к транзакции 121. Соединение не сбрасывается. Приложение по каким-то причинам после неответа ПЛК перестаёт правильно оценивать ответы ПЛК.

Может ещё что-то можно из WireShark вытащить, но я пока не знаю...

[jane_wild]

Посмотрите мои наработки https://github.com/ujin117/LabVIEW-Modbus-API. Обновил до текущего состояния.

Я бы тоже хотела посмотреть, но к сожалению LabVIEW 2021 у меня нет. Сохраните пожалуйста в версии 2020 на какой нибудь файлообменник

[ujin1]

WireShark показала следующее:
В какокй-то момент контроллер не отвечает на один запрос приложения и после этого всё рушится. Хотя приложение продолжает посылать запросы, а контроллер продолжает исправно отвечать.

Контроллер притормозил. Окончился тайм-аут. LabVIEW посылает следующий запрос с Transaction ID увеличенным на 1. В этот момент контроллер отвечает на прошлый запрос. Ответ лежит в буфере сетевого драйвера. LabVIEW читает из буфера ответ. Если он полностью совпадает, то Transaction ID все равно будет неправильным. Но ошибку неправильный Transaction ID LabVIEW не вводили. Поэтому показывают ошибку 56. В новых версиях может и добавили.

Приложение по каким-то причинам после неответа ПЛК перестаёт правильно оценивать ответы ПЛК.

Приложение правильно оценивает ответы. Спрашивает с одним Transaction ID. Ему отвечают с другим. Это ошибка. Вы можете в этом запросе запросить другие адреса. А в ответе начального адреса нет насколько помню.

[ujin1]

Посмотрите мои наработки https://github.com/ujin117/LabVIEW-Modbus-API. Обновил до текущего состояния.

Я бы тоже хотела посмотреть, но к сожалению LabVIEW 2021 у меня нет. Сохраните пожалуйста в версии 2020 на какой нибудь файлообменник

Сегодня уже не получится. Завтра выложу.

[Borjomy_1]

А тайм-аут увеличить? Не?

[Andrew Lunev]

Я делаю так.
Создаю машину состояний в которой есть состояние Reconnect и другие необходимые. Если возникает ошибка, то просто перехожу в состояние Reconnect и закрываю и снова открываю соединение. В этом случае есть небольшая задержка в опросе на переподключение, но если такая проблема возникает редко, то не страшно. Помогает и в случае, если реально связь потерялась, например устройство перезагрузили по питанию, или роутер. Или сетевой кабель выдернули и снова вставили. В вашей версии ПО надо всю программу перезапускать при разрыве соединения.

Ну и самый верный ответ, если возникают подобные ошибки, то надо увеличивать таймаут.

[ujin1]

Посмотрите мои наработки https://github.com/ujin117/LabVIEW-Modbus-API. Обновил до текущего состояния.

Я бы тоже хотела посмотреть, но к сожалению LabVIEW 2021 у меня нет. Сохраните пожалуйста в версии 2020 на какой нибудь файлообменник

https://drive.google.com/drive/folders/ ... sp=sharing

[rsv]

Приложение правильно оценивает ответы. Спрашивает с одним Transaction ID. Ему отвечают с другим. Это ошибка. Вы можете в этом запросе запросить другие адреса. А в ответе начального адреса нет насколько помню.

То, что Вы пишите похоже на правду. Только странно что навороченная LabVIEW эту ситуацию не может разрулить, а самописные программки как-то её разруливют без переподключения и продолжают опрос.

И как разрулить эту ситуацию в приложении без переподключения?

[rsv]

А тайм-аут увеличить? Не?

Увеличивал до 1 500 мс таймаут при чтении и интервал опроса до 2 000 мс. Значения совсем уже запредельные и работать с ними невозможно, но всё равно не помогло.

[rsv]

Создаю машину состояний в которой есть состояние Reconnect и другие необходимые. Если возникает ошибка, то просто перехожу в состояние Reconnect и закрываю и снова открываю соединение. В этом случае есть небольшая задержка в опросе на переподключение, но если такая проблема возникает редко, то не страшно. Помогает и в случае, если реально связь потерялась, например устройство перезагрузили по питанию, или роутер. Или сетевой кабель выдернули и снова вставили.

С переподключением понятно. Если других вариантов не найду придётся закрывать и заново создавать соединение.
Но, на мой взгляд, реация LabVIEW в данном случае несколько странная. Сначала буду искать решение без переподключения.

[ujin1]

То, что Вы пишите похоже на правду. Только странно что навороченная LabVIEW эту ситуацию не может разрулить, а самописные программки как-то её разруливют без переподключения и продолжают опрос.

Два варианта.
1. Программа смотрит что пришел ответ с предыдущим Transaction ID и читает с буфера еще раз.
2. Все таки переподключается. А переподключается или нет (закрывает ТСР соединение и открывает повторно) можно опять же проверить Wireshark' ом.

И как разрулить эту ситуацию в приложении без переподключения?

Стандартрой библиотекой никак. Чтение буфера

закопано глубоко внутри и закрыто паролем.