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

[rsv]

Стандартрой библиотекой никак. Чтение буфера закопано глубоко внутри и закрыто паролем.

Печально. До отпуска ещё покапаюсь, может какие-то обходные пути найдутся...

[Artem.spb]

А ва

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

И вас не смущает, что ваш прибор так долго отвечает?

[rsv]

А ва

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

И вас не смущает, что ваш прибор так долго отвечает?

Извините, совсем не понял Вашу реплику.
В моём сообщении указаны значения, которые я выставлял в приложении. Если устройство отвечает, то быстро. Если не отвечает, то за 1 500 мс дождаться ответа не удалось.
А вообще, при непрерывном опросе (без пауз) на 1000 запросов теряется от 5 до 15 ответов (вообще не приходят), среднее время ответа ~ 20 мс.

[Borjomy_1]

Если TCP Read завершается ошибкой 56, то соединение не рвется автоматически. Можно ещё раз вызвать эту функцию. Но это абсолютно аналогично увеличению таймаута. Очень странно, что у сервера, который должен отвечать в течение 50 мс, не помогают таймауты 1500..2000 мс. Это означает, что пакет вообще не доходит.
Думаю, проблему вы не видите в упор: сервер имеет ограниченную вычислительную мощность и не успевает одновременно обрабатывать данные и общаться с сетью. Это первый момент. Второй момент- физическое качество соединения и сетевая инфраструктура. Tcp пакеты должны быть гарантировано доставлены, это означает, что у микросхемы сетевого драйвера должен быть буфер и специальная микропрограмма, которая не справляется с плохим соединением. Не забываем также, что обмен идёт пакетами по ~250 байт. Т.е если идёт групповое чтение/запись, то пакетов отправляется несколько, пачкой. Буфер и повторная доставка тут становятся критичными.
Рекомендую снизить частоту запросов и подключить устройство коротким кабелем, без свичей.
Также есть старая библиотечка Modbus 8.5.llb (если не ошибаюсь). В ней все функции открытые, она простая до безобразия и там можно все посмотреть на самом нижнем уровне.

[rsv]

Если TCP Read завершается ошибкой 56, то соединение не рвется автоматически. Можно ещё раз вызвать эту функцию. Но это абсолютно аналогично увеличению таймаута. Очень странно, что у сервера, который должен отвечать в течение 50 мс, не помогают таймауты 1500..2000 мс. Это означает, что пакет вообще не доходит.

Ну да, после одного беответного запроса сниффер показывает наличие запросов к устройству с интервалом, заданным в приложении. Значит, соединение сохранилось. А модуль DSC глючит (из-за нарушения последовательности Transaction ID, как предполагает ujin1) и генерирует ошибку.

Сейчас пытаюсь найти комп без модуля DSC и проверить на нём.

... сервер имеет ограниченную вычислительную мощность и не успевает одновременно обрабатывать данные и общаться с сетью.

Это как раз понятно. Проблема в том, что приложение на labVIEW рушится при первом неответе.

Рекомендую снизить частоту запросов и подключить устройство коротким кабелем, без свичей.
Также есть старая библиотечка Modbus 8.5.llb (если не ошибаюсь). В ней все функции открытые, она простая до безобразия и там можно все посмотреть на самом нижнем уровне.

От частоты запросов вообще ничего не зависит. При 200 мс и 2 000 мс примерно одинаково возникают ошибки.
А вот протестировать подключение напрямую обязательно попробую. Может и до старой библиотечки доберусь...

[ujin1]

Не забываем также, что обмен идёт пакетами по ~250 байт

250 байт это не про IP пакеты. Стандартный размер Maximum Transmission Unit (MTU) Ethernet равен 1500. Подсчетами с учетом заголовков размер сегмента получается 1460 байт. Payload = 1460 - TCP Header = 1460-20 = 1440. https://habr.com/ru/articles/226807/
Максимальный размер Modbus пакета в запросе MBAP Header + Modbus request = 7+5 = 12 байт.
https://modbus.org/docs/Modbus_Messagin ... _V1_0b.pdf. В 4.3.2 TCP layer parameterization пишут что максимальный размер сегмента нужен 300 байт. 256 bytes + the
MBAP header size. Видимо за MBAP header size в этом абзаце приняты заголовки IP пакета. + Рекомендуют приемный буфер на минимум 3 пакета (по 300 байт = 900 байт)
В Wireshark видно что запрос 66 байт суммарно. Т. е. на заголовки потрачено 44 байт. Как раз эти самые 44 байта
https://modbus.org/docs/Modbus_Applicat ... V1_1b3.pdf. Здесь пишут что максимальный размер данных исторически сложился в 253 байт.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.
Максимальный размер MODBUS пакета всегда влезет в payload IP пакета без дробления.
В ответе так же видно размер ответа 69 байт. Это если я правильно принял цифры за размер сообщения один-два параметра. Заголовки столбцов Wireshark не видны.
Для сетевых карт, свичей 70 байт раз в 200 мс это 0,01% нагрузки.

[ujin1]

Может и до старой библиотечки доберусь...

А старая библиотечка будет работать. Потому, что поле Transaction ID в ней всегда будет = 0. Если Вы его сами не будете задавать.
А при приеме пакета оно так же не проверяется. Если Вы его сами не будете проверять.
Таким образом вам будут приходить ответы на прошлые запросы. Со сдвигом на 1 а может и более.
А если вы будете чередовать разные адреса в запросах, но с одинаковым количеством регистров, будете получать данные из регистров не тех что запрашивали.
На диаграмме библиотека 8.5. Transaction ID в кластере на входе MBAP Header. Дальше нигде не меняется и не проверяется. И на этот вход в примерах ничего не подано.

[rsv]

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

Ожидаемо не помогло. Но всё равно, спасибо.

[rsv]

Запустил из labVIEW 2018, без модуля DSC.
Почти то же самое. Единственное отличие - все ошибки однотипные, с кодом 56.

[Andrew Lunev]

Проблема в том, что приложение на labVIEW рушится при первом неответе.

По моему, это как раз нормальное поведение LabVIEW.
Исходные посылки:
Данные передаются по протоколу TCP, который гарантирует доставку пакета.
Нормально работающий прибор обязан ответить на запрос в указанное время.

Если ответ не получен, то или сеть Ethernet неисправна или прибор неисправен. Обе проблемы являются критическими и самое логичное выдать ошибку и дальше позволить решить программисту что делать. Как мне кажется, верный вариант - разорвать текущее соединение и попробовать установить его заново.

Как мне кажется, проблема в том, что ваш прибор периодически не отвечает на запросы Modbus. То есть принимает TCP пакет, но почему-то не выдает ответа на него. Если это так, то явно проблемы с реализацией протокола в прошивке устройства и LabVIEW тут не при чем.

Я встречал похожую проблему с расходомерами фирмы Взлет. Когда расходомер находился в режиме измерения, он не реагировал ни на какие запросы по сети и если в этот момент ему отправить запрос Modbus, то ответа от него не дождаться никогда. По хорошему, такой прибор является браком и не должен эксплуатироваться. Но если уж очень надо, то переподключение помогает. При опросе раз в секунду прибор не отвечал примерно на 10% запросов.

[rsv]

По моему, это как раз нормальное поведение LabVIEW.

Не согласен. TCP-пакеты могут путешествовать по всему миру, передаваться по радиоканалу, через спутник, через множество разнообразных ретрансляторв. Потеря отдельных пакетов возможна по множеству причин, не только по вине прибора.

Да и сам прибор может работать с очень разной нагрузкой. Потеря отдельных пакетов может быть связана с пиковой нагрузкой. А если по уму, то разрыв и восстановление соединениия должны сопровождаться авторизаций, а это вообще-то долго.

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

Но, вообще это мои интуитивные представления о протоколе (я по нему совсем не специалист). Ссылок на достоверные источники привести не могу. Попробую разобраться в этом вопросе. Может кто знает больше и сразу приведёт сылки на достоверные источники.

... позволить решить программисту что делать.

В том-то и дело, что в данном случае LabVIEW не предоставляет выбора - только переустановка соединения.
На мой взгляд, это внутренняя ошибка LabVIEW. Объясняю почему:
С одной стороны, после возникновения ошибки соединение сохраняется, запросы из приложения уходят.
А с другой стороны, в приложении невозможно получить ответы устройства на собственные запросы.
Было бы логичней сразу разорвать соединение в случае ошибки...

[ujin1]

приведёт сылки на достоверные источники.

https://modbus.org/tech.php - Раздел технические ресурсы официального сайта организации.
Выше были ссылки на документы по протоколу.

[FredP]

По моему, это как раз нормальное поведение LabVIEW.

Не согласен. TCP-пакеты могут путешествовать по всему миру, передаваться по радиоканалу, через спутник, через множество разнообразных ретрансляторв. Потеря отдельных пакетов возможна по множеству причин, не только по вине прибора.

Да и сам прибор может работать с очень разной нагрузкой. Потеря отдельных пакетов может быть связана с пиковой нагрузкой. А если по уму, то разрыв и восстановление соединениия должны сопровождаться авторизаций, а это вообще-то долго.

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

Но, вообще это мои интуитивные представления о протоколе (я по нему совсем не специалист). Ссылок на достоверные источники привести не могу. Попробую разобраться в этом вопросе. Может кто знает больше и сразу приведёт сылки на достоверные источники.

... позволить решить программисту что делать.

В том-то и дело, что в данном случае LabVIEW не предоставляет выбора - только переустановка соединения.
На мой взгляд, это внутренняя ошибка LabVIEW. Объясняю почему:
С одной стороны, после возникновения ошибки соединение сохраняется, запросы из приложения уходят.
А с другой стороны, в приложении невозможно получить ответы устройства на собственные запросы.
Было бы логичней сразу разорвать соединение в случае ошибки...

Меня тоже заинтересовала эта история. Глянул библиотеку ni_lib_modbus_library-1.2.1.42.vip Там черным по белому написано: слейв копирует transaction ID из сообщения мастера. Сам он +1 делать не имеет права. ну и проверка логичная или равно или ошибка.

[IvanLis]

Не согласен. TCP-пакеты могут путешествовать по всему миру, передаваться по радиоканалу, через спутник, через множество разнообразных ретрансляторв. Потеря отдельных пакетов возможна по множеству причин, не только по вине прибора.

Да и сам прибор может работать с очень разной нагрузкой. Потеря отдельных пакетов может быть связана с пиковой нагрузкой. А если по уму, то разрыв и восстановление соединениия должны сопровождаться авторизаций, а это вообще-то долго.

Протокол TCP - является протоколом с установлением соединения (виртуальный канал) и гарантированной доставкой.
Т.е. на уровне протокола доставка гарантируется при наличии действующего соединения.
Если соединение не разорвано, то пакет будет перезапрошен столько раз, сколько потребуется, но доставлен будет. Причем очередность отправки и приема сохраняется.

[ujin1]

Протокол TCP - является протоколом с установлением соединения (виртуальный канал) и гарантированной доставкой.
Т.е. на уровне протокола доставка гарантируется при наличии действующего соединения.
Если соединение не разорвано, то пакет будет перезапрошен столько раз, сколько потребуется, но доставлен будет. Причем очередность отправки и приема сохраняется.

Если добавить к Вашему утверждению цифру оно будет звучать так: Гарантия 100%, или вероятность успешной доставки 1 (100 %). Что сразу же вызывает сомнения у технического специалиста. И как показывает моя практика вероятность успешной доставки не 100%. При периодичности 10 запросов в секунду сбои с одним прибором происходили 5-6 раз в сутки. Т.е. вероятность недоставки была низкая 6/864000=7х10-6, но тем не менее установка 6 раз в сутки останавливалась, что задокументировано в журнале. Обсуждение почему в связи с множеством возможных вариантов приводит к "непонятно как у тебя вообще что-то работало с такими знаниями TCP".