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

[IvanLis]

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

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

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

Мы все учились понемногу Чему-нибудь и как-нибудь, Так воспитаньем, слава богу, У нас немудрено блеснуть.

Откройте спецификацию и прочтите.
Если у Вас возникают ошибки, дело не в протоколе, а в логике работы программы.
В случае если соединение установлено, то доставка гарантирована на 100%.
Если соединение разорвалось по какой-то причине, а Вы это проморгали, то протокол тут невиновен.
Другой вопрос, что при плохом качестве канала, значительно падает скорость передачи, и в указанный Вами TimeOut не укладывается. Что опять же все упирается не в протокол, а к тому, кто диктует правила и ограничения передачи данных.

Я делал много программ, в том числе когда одновременно идет непрерывный опрос более 3000 устройств по протоколу ModBusTCP, программы работают 24/365 и ни разу не сталкивался с описанными Вами проблемами, при условии что все необходимые ошибки правильно обрабатываются.

[ujin1]

Откройте спецификацию и прочтите.

Я уже пробовал обсуждать этот вопрос. Приводит к "непонятно как у тебя вообще что-то работало с такими знаниями TCP". Написано такого не может быть значит не может быть. Соответственно Вы так же двигаетесь в этом направлении.
Я бы предложил без обсуждения принять, что вероятность доставки не может быть 100%. Не приходит на память такое техническое событие, которое происходит с вероятностью 100%.
Далее по Вашему методу все необходимые ошибки правильно обрабатываются
Как в известной математической шутке: Поставил машину на то, что не встречу подряд 100 мужчин и тут мимо меня прошла рота солдат.

[AndreyDmitriev]

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

На самом деле Modbus Master в интерпретации NI действительно так устроен, что он сам разрывает соединение при отстутствии активности через какое-то время. Сам по себе TCP тут ни при чём, он так устроен, что соединение остаётся активным и в отсутствие данных, тут логика заложена в демон Modbus. Я налетел на те же самые грабли лет пятнадцать назад (но тогда весь тулкит был открыт). По хорошему таки лучше использовать Modbus Slave, а роль мастера оставить ПЛК, но если вы хотите быть мастером, то в общем это тоже имеет право на жизнь. Однако там внутри есть некоторое количество хард кодированных таймаутов. В самом первом грубом приближении происходит вот что. Когда вы открываете соединение, там по умолчанию пять секунд таймауты на чтение и запись устанавливаются, вот здесь:

Эти таймауты вот сюда пишутся:

Ну а вот тут в Read ADU Packet.vi они читаются, откуда вам и прилетает ошибка 56:

Попробуйте просто увеличить эти таймауты, скажем до минуты (вроде бы до этого места тулкит не запаролен). Чтобы избавиться от них совсем, либо обрабатывать их как-то иначе, вам придётся по любому залезть в запароленные инструменты, сделать дотошный трейсинг коммуникации и менять там логику удержания соединения в отстутствие активности. Там на самом деле несколько мест откуда летит ошибка 56:

и вот ещё:

кроме того я навскидку не вижу, откуда возникает ошибка -1967353903 (к DSC она не имеет отношения, просто так прописан текст ошибки), но тут просто глубже надо копать. Где-то так.

[ujin1]

Попробуйте просто увеличить эти таймауты, скажем до минуты (вроде бы до этого места тулкит не запаролен).

Это тема старая. Тулкит у меня в заводской поставке Labview 2019 г. не запаролен.
Я его изучил, как мне нужно переделал, добавил надстройку для коннекта, чтения, реконнекта и т.д. и у меня проблем не стало.
Где таймауты применяются и где задаются соответственно изучил.

Надстройка примерно такая получилась
Чтение имен классов из базы

Инициализация классов по именам (Channeling pattern)

Загрузка параметров из базы

Старт мастеров. Классы загружаются через обертку. Ядро в виде state machine. Управляющие сигналы из управляющей очереди
Данные складываются в общую таблицу (DVR). Статус мастера - DVR

Обмен. Тут вызов API

[AndreyDmitriev]

Попробуйте просто увеличить эти таймауты, скажем до минуты (вроде бы до этого места тулкит не запаролен).

Это тема старая. Тулкит у меня в заводской поставке Labview 2019 г. не запаролен.
Я его изучил, как мне нужно переделал, добавил надстройку для коннекта, чтения, реконнекта и т.д. и у меня проблем не стало.

Да, я его тоже допиливал примерно похожим образом. Я при ответе не заметил, что топикстартер-то rsv.
Вообще я давно уже с modbus не работал, мы как-то постепенно на OPC UA практически во всех проектах переползли (и да, там есть свои тонкости с реконнектом, но другие).

[ujin1]

Вообще я давно уже с modbus не работал, мы как-то постепенно на OPC UA практически во всех проектах переползли (и да, там есть свои тонкости с реконнектом, но другие).

OPC получше с реконнектом. Он сам реконнектится даже по разным параллельным сетям. Но в библиотеке NI есть свойство, что при реконнекте пропадают события. Сделал мониторинг параметра connect и "переподписку" на параметры. Тогда события опять восстанавливаются. Если события не использовать, то и делать ничего не нужно.

[IvanLis]

У меня был Тензометр "туповатый", он измерять начинал по запросу.
А время измерения могло доходить до 20 сек.
Боролся примерно так

Снимок экрана от 2024-01-29 16-09-17.png (4.65 КБ) 2190 просмотров

Лазать внутрь библиотеки не очень люблю, предпочитаю внешними средствами бороться

[rsv]

мы как-то постепенно на OPC UA практически во всех проектах переползли

А LabVIEW поддерживает OPC UA? В разделе Protocols ничего похожего не нашёл.
Или на Плюсах реализуете?

[AndreyDmitriev]

мы как-то постепенно на OPC UA практически во всех проектах переползли

А LabVIEW поддерживает OPC UA? В разделе Protocols ничего похожего не нашёл.

Да, при помощи NI OPC UA Toolkit (https://www.ni.com/en-us/shop/product/l ... olkit.html).
Но есть инфрмация, что этот тулкит дальше разрабатываться не будет, а там пара фич отсутствует — во-первых, он не поддерживает SHA256, а только SHA1 (Basic256), которое уже устарело, кроме того, во-вторых, он не поддерживает Methods Calls. Соседний отдел работает на плюсах используя open62541 (https://www.open62541.org), и у меня есть идея на досуге сделать LabVIEW-обёртку к этой библиотеке, но там довольно много возни, особенно в области вызовов методов.