Плагин Modbus
-
Вручную. Если вручную не перезапускать в дебаге пусто.
Будет если еще случай - попробую подождать подольше.
Да, нужно просто открыть отладчик и ждать. Ну или посмотреть времена - запуск - останов плагина (обновлять экран - динамически там не обновляется)
И все равно не понятно.
Контроллер не ограничивает создание второго, третьего подключния.
Когда на этапе первичной настройки некорректно выставлял функцию - создавалось несколько соединений.
Когда вносил изменения - добавлял регистры для обмены, было видно, что сервер создает второе соединение не закрыв первого, а первое само отсыхало через несколько секунд.
А в этой ситуации что мешает создать второе соединение? И пусть первое отсыхает себе не мешая общей работоспособности.
Когда сервер (плагин) завершает работу штатно (в том числе при ошибке адресации), он закрывает соединение, то есть посылает пакет FIN. Поэтому такие соединения закрываются чисто.
Когда плагин запускается - он открывает, естественно, новое соединение. Но, вероятно, что-то мешает контроллеру ответить взаимностью
-
Будет если еще случай - попробую подождать подольше.
А вот и случай.
С 17-30 жду, года плагин соизволит самовосстановить взаимодействие.
Судя по дебагеру, он и не пытается ни разу. Там чисто и пусто.
Сколько подождать? 11 минут 2 раза прошло.
-
Будет если еще случай - попробую подождать подольше.
А вот и случай.
С 17-30 жду, года плагин соизволит самовосстановить взаимодействие.
Судя по дебагеру, он и не пытается ни разу. Там чисто и пусто.
Сколько подождать? 11 минут 2 раза прошло.
А состояние какое? Запущен он? Время запуска - останова?
-
Был запущен, связи с контроллером не было.
в 19-53 перезапустил руками, заработало.
-
добрый день, можно синхронизировать carel pco compact с ІН? по протоколу Modbus.
-
Был запущен, связи с контроллером не было.
в 19-53 перезапустил руками, заработало.
Понятно. Добавим дополнительный таймаут на уровне опроса, это должно решить проблему.
-
добрый день, можно синхронизировать carel pco compact с ІН? по протоколу Modbus.
Добрый день. Если Modbus TCP, то плагин доступен для скачивания.
Для настройки нужны адреса регистров Modbus для carel pco compact. Ну и план, что собственно Вы хотите синхронизировать.
-
Вошел в череду прерываний связи.
Оператор на даче с весной не справляется. видимо.
и ни разу сама связь сервера с контроллером не восстановилась.
Я, конечно, в перспективе увезу сервер на дачу, и проблема станет не актуальной.
Но если ее не решить, доверять серверу управлять географически распределенными объектами будет боязно.
Это важный момент. Решите его, пожалуйста.
-
Вошел в череду прерываний связи.
Оператор на даче с весной не справляется. видимо.
и ни разу сама связь сервера с контроллером не восстановилась.
Я, конечно, в перспективе увезу сервер на дачу, и проблема станет не актуальной.
Но если ее не решить, доверять серверу управлять географически распределенными объектами будет боязно.
Это важный момент. Решите его, пожалуйста.
Добрый день.
На гитхабе опубликован новый релиз плагина 0.0.7 https://github.com/intrahouseio/intraHouse.plugin-Modbus/releases/tag/v0.0.7
Изменения касаются только логики работы при потере связи.
Параметр плагина "Ожидание ответа на запрос (ms)" для нелокальных соединений желательно увеличить с 1 сек (1000 ms) до 5 и более сек.
-
Спасибо.
Установил.
-
Выдергивание патчкорда пережил нормально.
Осталось дождаться сбоя у оператора. Надеюсь, оператор не обманет в ожиданиях
-
Произошло.
Вижу разницу в поведении наглядно.
Видно, что плагин отключается, и включается, попытки повторяются, пока не прилетит хоть какой нибудь ответ, видимо.
После восстановления связи плагин это заметил, и перезапускаться перестал. Но работа не восстановилась. Ошибки дебагера видны - это ошибки связи.
В информации на микротике видно, что висит старое соединение, с таймаутом 23 часа, и второе новое, которое не может начать работать по каким то причинам.
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
-
Произошло.
Вижу разницу в поведении наглядно.
Видно, что плагин отключается, и включается, попытки повторяются, пока не прилетит хоть какой нибудь ответ, видимо.
После восстановления связи плагин это заметил, и перезапускаться перестал. Но работа не восстановилась. Ошибки дебагера видны - это ошибки связи.
В информации на микротике видно, что висит старое соединение, с таймаутом 23 часа, и второе новое, которое не может начать работать по каким то причинам.
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
Нет, конечно. Плагин не может так держать соединение, чтобы не давать контроллеру его сбросить.
Тем более он сам перезагружается, то есть закрывает со своей стороны.
Судя по логу - TCP соединение устанавливается, а вот по Modbus контроллер не отвечает.
Возможно, нужно радикально увеличить таймаут со стороны плагина, чтобы не дергать контроллер так часто.
В контроллерах обычно есть такой параметр - таймаут для Modbus соединения (и даже иногда его можно настроить, но это не обязательно, хотя бы знать).
-
В моем контроллере на виду его нигде нет.
Описал проблему на форуме поддержки контроллера. Посмотрю, что скажут.
Пока могу по факту значка "авария" на модбас-актуаторе и наличию пинга до контроллера принимать решения о его перезагрузке автоматически.
Но не могу пока смоделировать в каких еще ситуациях такие условия могут совпасть.
Контроллер то работает, климатом управляет, только отображение работы "отваливается".
Будет неправильно свалить его в череду перезагрузок.
-
В моем контроллере на виду его нигде нет.
Описал проблему на форуме поддержки контроллера. Посмотрю, что скажут.
Пока могу по факту значка "авария" на модбас-актуаторе и наличию пинга до контроллера принимать решения о его перезагрузке автоматически.
Но не могу пока смоделировать в каких еще ситуациях такие условия могут совпасть.
Контроллер то работает, климатом управляет, только отображение работы "отваливается".
Будет неправильно свалить его в череду перезагрузок.
Перезагрузка контроллера - это не решение. Нужно попытаться решить вопрос штатно.
Хорошо бы логировать трафик с помощью tcpdump (wireshark, etc.) и затем проанализировать.
-
микротиком собрал в packet sniffer начало взаимодействия (включение плагина). 2 раза.
https://yadi.sk/d/ZOGm_D1kwDq84g
https://yadi.sk/d/A7l6akA5DD9Tpg
смотрелка
192.168.88.46 - сервер IH
192.168.13.25 - контроллер
88.99.91.165 - облачный сервис, контроллер с ним по MQTT взаимодействует.
-
Видно, что время IH задает, а контроллер соглашается (первые пакеты на картинке).
-
Покажите, где IH задает время для контроллера
-
первый пакет.
Источник 192.168.88.46 - это IH.
задает TSVal = 602011810. В милисекундах это 167 часов.
А, наоборот.
Источник контроллер.
Извиняюсь.
-
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
Добрый день, данное время вы можете настроить самостоятельно нажав кнопку "Tracking"
Из документации микротика:Timeout - Time after connection will be removed from connection list. Этот параметр нужен микротику для трекинга.
