К контроллеру подключено два устройства(с разными ip, но по факту всё шлётся с одного плк) по modbus-tcp, одно устройство стабильно опрашивается и отображаются верные значения. Второе устройство периодически начинает показывать 0 у всех параметров, причём до этого такой проблемы не было. Если зайти в mqtt-serial и поменять адрес с 1(стандартного адреса tcp) на 2 и обратно, то параметры начинают приходить, но спустя какое-то время снова начинают приходить 0. В чём может быть проблема?
Добрый день!
Уточните, пожалуйста, вот этот пункт:
К контроллеру подключено два устройства(с разными ip, но по факту всё шлётся с одного плк)
К сожалению, я не понимаю, что имеется в виду. Можете нарисовать простой эскиз и дать его описание? Или фотографию?
Так же прошу в момент, когда приходят нули, выполнить следующие команды и прислать их вывод:
journalctl -u wb-mqtt-serial -f
ss -tn
Так же, пришлите, пожалуйста, скриншот, чтобы я понял, что вы меняете в этой части:
Если зайти в mqtt-serial и поменять адрес с 1(стандартного адреса tcp) на 2 и обратно
Добрый день,
По поводу вопроса К контроллеру подключено два устройства. Я имею ввиду что пришлось делать это как два разных конфига для устройств, так как параметры приходят с двух айпи адресов, но всё отправляет по modbus tcp другой контроллер плк beckhoff.
Сейчас с параметрами всё нормально, но недавно были 0, к сожалению я не мог в тот момент сделать скрин команды journalctl -u wb-mqtt-serial -f. Вот что она выдаёт сейчас:
Также вторая команда ss -tn:
Скриншот того что я менял, имелся ввиду адрес на веб интерфейсе с 1 на 2 и обратно, то есть просто:
И потом:
К сожалению, я до сих пор не понимаю. Пришлите, пожалуйста, эскиз, на котором будет нарисован контроллер WB, контроллер beckhoff, любое другое оборудование и их соединения с указанием ip-адресов.
Понял, это адрес Device (Unit) ID.
Смиренно прошу эскиз )
Помимо эскиза пришлите, пожалуйста, диагархив.
Подскажите, проблема ещё актуальна?
Добрый день, проблема актуальна, не было возможности получить архив с контроллера, только сейчас смогли. Я прикрепил диагностический архив.
приложен диагностический архив, доступен только сотрудникам поддержки
(302,0 КБ)
Насчёт устройств, которые подключены к WB7:
неас есть два Slave устройства в нашей TCP - мастером выступает Wb7
Это панель Beckhoff и ПЛК Beckhoff
Они по своим мастер портам собирают инфу и передают её в диспетчерскую
Мы поставили свою систему для передачи данных на уровень выше (в облако)
На ПЛК и Панели были выделены Slave Modbus/TCP порты и объявлены необходимые переменные (со стороны другой подрядной организации)
Мы по этим переменным опрашиваем регистры и вот у нас есть то 0 то 1 и как только рестартим wb-mqtt-serial на WB7 все приходит в норму
Добрый день.
По устройствам: ПЛК Beckhoff — 172.16.200.80:502 (slave_id 1), панель Beckhoff — 172.16.200.88:502 (slave_id 2). По логам wb-mqtt-serial за все дни, что есть в архиве, картина однозначная: с ПЛК (.80) вообще нет проблем — ни одного таймаута, ни одного обрыва соединения за всё время. Все 2791 таймаут и 603 обрыва связи — только по панели (.88). Так что проблема локализована именно на панели, а не в конфигурации WB7 или в сети.
Отдельно хотел уточнить момент из вашего наблюдения — про то, что смена Unit ID и рестарт wb-mqtt-serial временно чинят связь. По логам это не выглядит как надёжный фикс, скорее как совпадение по времени.
В архиве есть плановые перезапуски wb-mqtt-serial каждые 6 часов (00:49, 06:49, 12:49, 18:49 5 июля). И вот что показательно:
-
После рестарта в 00:49 — обрывы по панели (
172.16.200.88) возобновились уже через несколько секунд: 00:49:03, 00:49:11, 00:49:29 и далее в течение ещё нескольких часов. -
После рестарта в 18:49 — был один обрыв, и всё, проблема больше не повторялась.
То есть один и тот же по своей природе рестарт в одном случае не дал вообще никакого эффекта, а в другом совпал с полным исчезновением проблемы. Если бы рестарт действительно “лечил” зависшую сессию на стороне WB, эффект был бы одинаковым каждый раз. Раз эффекта нет — значит, выздоровление наступает само по себе на стороне панели, а рестарт WB7 просто иногда попадает по времени в этот момент.
Технически рестарт wb-mqtt-serial закрывает все TCP-сокеты и поднимает их заново с нуля — но если панель сама ещё не отпустила своё внутреннее состояние (перегружен цикл контроллера, занята очередь Modbus-запросов, конфликт с другим мастером-диспетчерской), новое соединение от WB7 будет приниматься на уровне TCP, но запросы к регистрам всё равно продолжат падать по таймауту — что мы и видим в логе сразу после рестарта в 00:49.
Поэтому предлагаю сместить фокус диагностики на саму панель (172.16.200.88):
-
Сколько мастеров сейчас одновременно опрашивают именно панель по Modbus/TCP — только WB7, или ещё диспетчерская/другая SCADA? ПЛК (
172.16.200.80), судя по всему, опрашивается без конкурентов и потому стабилен; если панель одновременно держат несколько мастеров, возможен конфликт за ограниченное число TCP-сессий или очередь запросов на её стороне — это и объяснило бы избирательность проблемы. -
Есть ли возможность посмотреть логи или загрузку самой панели в моменты обрыва — не перегружен ли её цикл в эти периоды.
Пришлите, что удастся получить — разберёмся дальше.