Здравствуйте, имеется плк WB7, через Ethernet подключенный к сети с некоторым количеством WB-MIO-E v.2, к каждому из которых сбоку подключен один WBIO-DI-HVD-8. Необходимо просто получать значения с HVD-8 на плк. Для каждого MIO был добавлен свой порт и указаны соответствующие HVD-8 со своими modbus адресами.
При начальной установке контроллера почти все устройства были красными, что удалось частично пофиксить перезагрузкой WB-MIO.
В итоге остается 4 устройства, с которых не получается получить значения на WB7.
Устройства пингуются, но на их mqtt топиках приходит ошибка чтения “r”.
Как “оживить” оставшиеся 4 MIO с HVD-8?
Добрый день.
Что возвращается при чтении с помощью Утилита «modbus_client» — Wiren Board?
Как сконфигурированы настройки шины (скорость, стопбиты, четность) в ethernet порте?
Все ethernet порты сконфигурированы одинаково. На скрине пример
Настройки RS485-1 не менялись, т.е. скорость обмена - 9600, контроль четности - N, число бит данных - 8, стоп биты - 2.
Вот вывод modbus_client (возможно неправильно команду написал, только знакомлюсь со всем этим делом):
modbus_client --debug -mtcp -a133 -r0 -p23 -t0x01 172.16.131.122
Connecting to 172.16.131.122:23
[00][01][00][00][00][06][85][01][00][00][00][01]
Waiting for a confirmation…
ERROR Connection timed out: select
<00>ERROR occured!
У вас настроен в контроллере режим Modbus over TCP. А зачем, собственно? Если не используются устройства не modbus - то смысла нет. Ну и modbus_client с параметром -mtcp работать не будет, соответственно. Предлагаю - настроить как порт контроллера так и сам шлюз в Modbus TCP. Порт лучше использовать стандартный, 502. И проверьте на самом шлюзе, во вкладке “TTL1” параметры шины.
MIO настраивались согласно документации, отсюда и настройки шлюзов и портов. Таким же образом настраивался предыдущий объект, и упомянутых проблем там не наблюдается.
Можете, пожалуйста, подробнее описать настройку устройств для работы через Modbus TCP?
Скрины настроек после того, как настроил на Modbus TCP:
На плк mqtt топики все равно красные.
К данному шлюзу сколько модулей подключено?
К каждому MIO подключен один модуль.
Тогда адрес не должен быть 133:3. Если к WB-MIO с адресом 133 подключен один модуль, то в настройке он будет 133:1.
Адрес везде стоял х:1. Исправил для этого модуля, случайно поставил 3, плк все равно не читает значения.
Не помешает диагностический архив. Может он на новые мысли наведет.
diag_output_ANOYBGGB_2023-10-11-11.31.38.zip (122,7 КБ)
Настроил модуль, который с прежними настройками работал нормально, на работу в Modbus TCP, и он в этом случае тоже нормально работает.
Вот сейчас - верно настроено.
Запустите для проверки на контроллере
modbus_client -mtcp --debug -p502 172.16.171.122 -a133 -t3 -o500 -r290 -c12
root@wirenboard-ANOYBGGB:~# modbus_client -mtcp --debug -p502 172.16.171.122 -a133 -t3 -o500 -r290 -c12
Connecting to 172.16.171.122:502
Connection failed: Connection refused
Точно ли с контроллера доступен этот порт узла?
Порт доступен, проверил и в nmapе и в netstat.
Дайте доступ, пожалуй посмотреть будет проще.
Давайте мы бесплатно поменяем вам оборудование. Курьер привезёт новое оборудование и заберёт старое:
- WB-MIO-E - 4 шт.
Для возврата напишите, пожалуйста, письмо на info@wirenboard.com.
В письме укажите:
- ссылку на эту тему,
- серийный номер устройств, если есть,
- ваш действующий телефон, адрес доставки, ФИО получателя.
Проблема с “мертвыми” MIO решилась заменой на имеющиеся другие модули MIO.
Однако, есть ещё одна проблема, в связи с которой мы не отправили запрос на обмен оборудования.
При перезагрузке плк, или wb-mqtt-serial, или изменении wb-mqtt-serial.conf, некоторые MIO “отваливаются”, возникает ошибка чтения на их топиках. Это исправляется перезагрузкой самих MIO (что вообще не должны делать во время работы) до следующей перезагрузки плк и т.д.
Помимо этого, не на всех страницах настройки “отвалившихся” MIO в статусе пишет ошибку. Часть из них имеют статус listen, который изменяется на connected после исправления ошибки на другом определенном MIO. Количество “спящих” и “отвалившихся” MIO после каждой перезагрузки драйвера разное, ровно как и количество спящих, которые восстанавливают работу после исправления ошибки на конкретном MIO.
В чем же причина такого поведения?
Какая версия wb-mqtt-serial?
выложите пожалуйста диагностический архив.