Доброго времени суток.
Написал свой шаблон для вентустановки Turkov Capsule. Иногда при чтении регистров возникает ошибка
input: 257> is now marked as unavailable: Serial protocol error: illegal data value
В результате топик в панели помечается красным даже если дальше с его чтением и записью проблем нет. Как снять пометку топика?
P.S. При нажатии Ctrl+Entet Происходит автоматическое сохранение сообщения на форуме и уже по ошибке создал недописанное сообщение. Просто в некоторых мессенджерах эта комбинация делает перевод на новую строку. Кажется здесь лучше отключить это комбинацию клавишь.
Дробрый день!
А это происходит только с определенным регистром?
Хотел бы попросить вас сделать и прислать диагностический архив, который вы снимете после “покраснения”.
Создание архива описано в документации.
То, что дальше значения читаются из регистра, а топик остается красным, выглядит непонятным пока – при повтороном успешном чтении красный должен сбрасываться, а в моем понимании после 257> is now marked as unavailable чтения из регистра не будут выполняться до перезапуска wb-mqtt-serial.
Топик остается красным до тех пор пока значение /ваш/топик/meta/error будет r, если туда записать пустое значение, то “покраснение” сбросится.
Еще я бы попросил бы вас показать шаблон – illegal data value не должно появляться при правильном шаблоне. Что-то вентустановка отдает не предусмотреннное вашим шаблоном. Думаю, с этого стоит начать – разобраться, какие значения вызывают “покраснение”.
Проблема возникает с разными регистрами. Приложил диагностический архив и шаблон.
turkov-capsule.json (3,6 КБ)
приложен диагностический архив, доступен только сотрудникам поддержки
(281,8 КБ)
Спасибо за диагностику!
Пока вижу, что коммуникации с вентустановкой по RS-485 очень часто завершаются ошибками, там и “invalid crc”, и " request timed out".
Шаблон выглядит корректно, спасибо – проблема не в нем (увидел только опечатку: “name”: “sezpn”,)
Предлагаю сначала разобраться с RS-485. Какой длины линия идет к вентустановке до контроллера? На ней, кроме котнтроллера и WB-MSW v.4? физически нет никаких устройств? Топология – шина? Есть ли терминатор на конце?
Самое простое, с чего можно начать, этонастроить “Минимальный интервал между запросами к устройству” – сделать его 100-200 мс, и “Задержка между сообщениями” – ее сделать 30-100 мс.
Потом стоит попробовать уменьшить скорость обмена данными до 9600 бит/с и посмотреть, насколько с такими параметрами будет много ошибок.
Задержку установил. Скорость порта снизил.
На линии всего 2 устройства, оба подключены через WB HUB, Длина подключения для обоих устройств не большая, оба находятся рядом со щитом (линия до каждого в пределах 3х метров). Терминаторов на концах нет. Наблюдаю за ошибками (пока их нет за 10 мин после перезапуска сервиса). Но такая скорость конечно маловата, хотелось бы побыстрее.
Но это все конечно не отвечает на вопрос, почему не очищается топик наличия ошибки чтения.
UPD:
Ошибки полностью не исчезли, но стали возникать реже (примерно раз в час).
Первоначальная проблема так и не ушла. Да ошибок на шине стало меньше, но все равно в итоге один топик покраснел.
Попробовал воспроизвести вашу проблему, но понимаю, что мне не зватает информации.
Хочу попросить вас включить отладку на порту, дождаться покраснения, дождаться восстановления обмена данными (из покрасневшего регистра) и прислать диагностический архив снова.
В веб-интрефейсе в Настройки -> Конфигурационные файлы -> Настройка драйвера Serial-устройств выберите Настройки wb-mqtt-serial, поставьте галочку Включить отладочные сообщения и нажмите Сохранить настройки.
Включил сбор отладочных сообщений. Дождался “покраснения”. Заметил что сейчас покраснение не снимается с intput регистров, с holding регистрами есть только “мигание”. При этом при попытке прочитать значение регистра через modbus_client_rpc значение считается без проблем. (смотре на примере регистра 0x0112).
modbus_client_rpc -m rtu --debug -b 9600 -pnone -s 1 /dev/ttyMOD2 -a 49 -r0x0112 -t 4
приложен диагностический архив, доступен только сотрудникам поддержки
(206,3 КБ)
Прошло немного времени и holding регистры тоже покраснели без поворотно, при том что значения туда записываются. Конкретно в этом архиве есть работа с регистром 0x0005.
приложен диагностический архив, доступен только сотрудникам поддержки
(206,2 КБ)
Спасибо большое! Изучу, вернусь с ответом!
Добрый день! Извините, пожалуйста, за долгую задержку с ответом.
Не получилось воспроизвести на стенде, хочу попросить вас показать для покрасневего контрола вывод mosquitto_sub -v -t '/devices/<устройство>/controls/<контрол>/meta/error'
Еще один возможный способ борьбы с некорректными чтениями – добавить в настройках устройства параметр “Дополнительная задержка перед записью в порт (мкс)” и установить его в значение 4500.
Задержку добавил. Продолжаю наблюдение.
Еще раз просмотрел ваши архивы, пытаясь понять, как происходит так, что флаг ‘r’ не сбрасывается, даже если чтение успешно, и не понимаю пока.
Вот запрос на чтение, например:
Jan 14 12:27:25 ... /dev/ttyMOD2: Write: 31 03 00 03 00 01 71 fa
Вот таймаут:
Jan 14 12:27:26 ... WARNING: [modbus] failed to read 1 holding(s) @ 3 of device modbus:49: Serial protocol error: request timed out
Через две секунды уже читается успешно
Jan 14 12:27:28 ... /dev/ttyMOD2: Write: 31 03 00 03 00 01 71 fa
Jan 14 12:27:28 ... /dev/ttyMOD2: ReadFrame: 31 03 02 00 00 f8 40
Но задержки, правда, большие:
Jan 14 12:27:28 ... Poll time for <modbus:49:holding: 3> is too long: 49 ms ... AverageResponseTime=31066 us ...
Пока подозреваю, что да, вентустановка отвечает длольше, чем от нее ожидается, и можно таймингами будет исправить ситуацию.
Добрый день! Получилось ли у вас исправить ситуацию с покраснением топиков?
Добрый день. Полностью победить не удалось. Проблема ошибки чтения стала возникать реже, но за несколько дней все равно все регистры несколько раз читаются с ошибкой и помещаются как недоступные. При этом дальше устройство работает нормально, на запись в него все работает корректно, а вот чтение не происходит. Ошибка с тем что не снимается пометка не решена.
Сейчас в голову пришла мысль что счетчик ошибочных чтений у вас не сбрасывается после того как удалось в итоге прочитать значение. Тогда независимо от того есть ли успешные чтения, топик перестаёт читаться в случае если превышен порог допустимого количества ошибок.
Вот это да, странно, что ведет себя не так, как ожидается. Скажите, у вас есть возможность подключить контроллер к облаку и дать доступ к нему? Хотелось бы понаблюдать, посбрасывать ошибку и посмотреть на поведение. Не понимаю пока, почему так.
Облаком по параноидальным причинам не пользуюсь, но если нужно для отладки, думаю можно подключить, только нужна будет потом инструкция как его отключить.
После подключения получить противоречивое сообщение:
Вроде подключился успешно, но написано что это ошибка.
Какая-то прямо классика айтишного юмора получилась: “task failed successfully”!
Уточню у разрабочиков, как это интерпретировать.
Но после этого попасть на контроллер через облако вы можете?
Понимаю и разделяю ваши опасения. Мы очень стараемся, чтобы облако было надежным и безопасным и беспокоимся о репутации. Я сам серьезно беспокоюсь о безопасности, но нашему облаку доверяю вполне – ну, отчасти потому, что вижу все изнутри, конечно.
У нас в документации по облаку есть раздел, как отключиться от облака совсем: Отключение контроллера от облака
Если ваш контроллер теперь доступен через облако, пришлите, пожалуййста мне в личное сообщение приглашение в вашу организацию. Инструкция:
Пригласите, пожалуйста, пользователя support@wirenboard.com в организацию на облачном сервисе.
Логин, пароль от SSH пришлите личным сообщением, если они нестандартные.
Для этого в настройках организации нажмите кнопку “Пригласить”
И укажите почтовый адрес:
После этого поддержка получит доступ к вашему контроллеру для диагностики.
Не забудьте удалить потом доступ.
Контроллер в облаке виден. Приглашение отправил.
Спасибо, вижу, есть доступ. Сегодня буду наблюдать, из активных действий предполагаю только сбрасывать флаг ошибки. Если потребуется что-то сделать еще – согласую здесь с вами.
