Добрый день. Ситуация следующая. За 3 дня работы никаких провалов в чтении регистров шлюза через RS-485(вход 1 в WB) не было. Данные считываются. Но, это 6 WB с такой версией:
Шлюз был подключён напрямую к входу WB.
Когда у себя шлюз напрямую подключаю к порту (пробовал и к первому тоже) - он работает, но в журнале регистрации довольно часто сыплются ошибки (что раздражает, но в целом все работает).
Отказ случился (у меня) когда на тот же порт последовательно подключил еще устройства WB, шлюз при этом оказался последним в цепочке. За шлюзом размещена еще группа контактов с терминатором (15 сантиметров кабеля) для подключения второго такого-же шлюза для второго котла (были такие планы).
Может, в этом дело? @Vladimir_Nev_Sup корректно работает модуль на 115200, или лучше не использовать эту скорость?
Пробовал переключать обмен на родную для шлюза скорость 19200 - результат аналогичный.
С остановленным опросом устройств WB - шлюз работает.
Включаю опрос любого устройства WB - шлюз сам не работает (при длительном наблюдении все же заметил, что контролы иногда не надолго чернеют) и устройства WB обновляются с долгим периодом (но не отваливаются).
Какая у вас версия ПО ( Release name)?
unstable.latest
приложен диагностический архив, доступен только сотрудникам поддержки
(401,4 КБ)
На 115200 одиночно модуль работает корректно до 200мс период опроса. В связке мы не проверяем.
Ещё 1 эксперимент: другая версия ПО wb и последний шаблон для шлюза, длина линии около 10 м. На линии помимо шлюза есть ещё 1 устройство:
Опрос так же идёт, без красный значений на 19200.
-
Второе устройство не просто висит, но еще и опрашивается?
В моем случае, работа нарушалась при включении опроса других устройств, а пока они просто подключены к шине - шлюз работал. -
Второе устройство производства WB с быстрым модбасом?
В моем случае, устройство WB с последней версией прошивки, доступной в testing репозитории. -
Версия ПО, довольно старая стабильная, можно протестировать на текущей версии testing с включенным опросом других устройств?
Обновить я не могу WB, на нём выполняется другая работа. Быстрый Модбас не используется, поэтому провести ваш эксперимент 1:1 не получится. Но ошибок я не увидел в своих тестах. А вот вас как придёт шлюз попрошу поставить вот этот шаблон для эксперимента. Он старый. Но позволяет вручную выставлять все необходимые тайминги. Потому что таймингами можно легко испортить работу шлюза.
config-eBusModbus.json (2,6 КБ)
Я то, конечно проверю работу шлюза с предложенным шаблоном.
Но можно все таки не игнорировать задаваемые вопросы, а давать на них ответы?
Возможно Вам они кажутся незначительными, однако я хочу понимать в каких условиях проверялась работа, принадлежащего мне выпущенного Вашей компанией устройства.
Единственно убрал из шлюза терминальный резистор. Если на тех WB устройствах он уже есть, это может гасить шину и искажать пакеты. Если нет, то придётся подключать внешний на 120 Ом.
Да, я устанавливал терминирующий резистор.
Не знал, что в шлюзе уже установлен такой.
В документации на шлюз, размещенной на сайте Невотон написано:
На верхней торцевой поверхности находятся:
– клеммная колодка 1 (1) для подключения проводов интерфейса RS-485 Modbus,
входных сигнальных проводов и терминального резистора.
Исходя из этой информации и вешал терминальный резистор - хорошо бы поправить.
Скажу тем, кто писал инструкцию, исправят эту отсебятину. 
Добрый день! Появилась ли какая-либо информация?
Добрый день!
Добрался до подключения устройства. Оно все так же “не работает”.
Эксперименты проводил с терминаторами на обоих концах шины, на одном из них, совсем без них - вообще не заметил разницы. Т.е. либо работает либо нет.
Вариант шаблона предложенный представителем НЕВОТОН, помогает в том плане , что обмен со шлюзом идет, но все остальные устройства обновляются с большой задержкой.
Решил попробовать работу устройства с не WB устройством, собственной сборки. Помог параметр группового чтения регистров … (быстрее обновляться стало).
Все устройства, во всех экспериментах физически подключены к шине. Т.е. отключается или подключается только опрос устройств в настройках, чего оказывается достаточно что бы шлюз работал или нет описанными способами.
Точнее:
- Когда включен опрос только самого шлюза он работает (видно по отсутствию “красноты” и по логу - тоже, на сколько я могу в этом что-то понимать)
- Когда включен опрос шлюза и еще одного устройства собранного “на коленке” - устройство работает и шлюз работает на половину. Т.е. обновление времени работы устройства обновляется раз 2-3 секунды, а у шлюза все время красный только один канал (1002 holding). Пробовал отключать опрос этого регистра - красным становится другой канал (1004 holding).
- Включаю опрос к этому зоопарку еще одно устройство производства WB (WB-MWAC) - шлюз перестает работать (все каналы красные), время работы устройства обновляется примерно раз в 20 секунд.
Отключил работу всех портов кроме того к которому подключены устройства, включил вывод отладочных сообщений, логи прилагаю.
Только Щлюз.log (93,6 КБ)
Шлюз и не WB устройство.log (47,9 КБ)
Шлюз плюс не WB устройство плюс WB MWAC.log (203,8 КБ)
Мучает вопрос, почему во втором случае ошибка чтения постоянно только у одного регистра?
Что такое может делаться на шине, когда подключаются устройства WB?
Используемый шаблон:
nevoton-beg.json (15,6 КБ)
Подключил контроллер к облаку wirenboard.cloud.
Т.е можно пощупать по SSH подключению.
Если ближе к концу недели - смогу по видео связи телеграмм показать, что да как подключено
Добрый день!
Дошли руки - доразобрался.
Модуль не совместим с Быстрым Modbus-сом.
При отключении быстрого Modbus (установив в шаблоне все sporadic=false) работа модуля восстанавливается (по крайней мере обмен идет).
При всем этом есть ощущение, что в работе сериал драйвера есть какая-то “гадость” уж больно странным выглядит постоянная ошибка на одном из контролов (если бы на разных можно было-бы фантазировать по поводу плохой шины или там еще чего-то, а так пространства для фантазий не осталось).
Что касается самого шлюза, то есть подозрение, что он не полностью поддерживает стандартный Modbus, потому как реагирует на процессы арбитража устройств - непонятно зачем. Еще есть вероятность, что он использует тот-же код функции расширения для своих целей и соответственно - пытается что-то ответить, чем “ломает” арбитраж слейвов.
Разбирательство на этом этапе завершаю, буду думать как выкручиваться.
1 лайк