Имеем на линии ряд устройств, в том числе ваше реле.
К сожалению, выявили конфликт. В линии у нас есть устройства, у которых тоже присутствуют свои “кастомные” команды.
Пример:
FD 8E A8 87 F4 F1 63 0A 45 75 04 4D 5A 3B A6 9E 0B
FD 79 FB 15 F6 26 40 1C 58 29 00 50 BC 45 79 E6 5C
Подобные команды вызывают реакцию от реле. И реле тоже начинает посылать в линию данные, несмотря на то, что к нему (по его адресу) обращения нет и эти данные от реле не ожидаются. Как результат - на линии сразу несколько устройств болтают.
Изучив вашу документацию, прихожу к выводу, что это может быть связано с вашим расширением Modbus, например сканером, который тоже использует 0xFD.
Подскажите, пожалуйста, можно ли как-то программно отключить все расширенные команды у реле, оставив только стандартный Modbus?
А что за устройства, если не секрет?
Вообще очень интересно, если выложите сюда диагностический архив либо лог обмена.
Если используете не с нашим контроллером - тогда спрошу у разработчиков.
После включения устройства все “дополнительные” возможности выключены, всегда. И они включаются именно мастером. Причем по “стандартному” modbus Как раз поэтому и интересно - как они включаются. Да, если у еще одного устройства используется 0xfd 46 - то возможно, конечно. Маловероятно, но возможно.
Поэтому нам бы знать что за устройство - для проверки.
Мастер регулярно посылает команды с FD. Допускаю, что когда-то могла промелькнуть последовательность:
FD 46 {10-20 других байт} CRC
Реле могло на это среагировать?
Его же явно должны были не устроить следующие байты? Оно ожидает команду совершенно другой длины и проверяет CRC?
Сейчас главная проблема, что реле реагирует на эти команды и мешает опросу. Как мы можем заблокировать любую активность реле, кроме стандартны Modbus ответов на запросы по адресу устройства?
Разработчики провели тест, да, реле может отвечать на не совсем корректные команды сканирования.
Ждем исправления.
А какое оборудование все ж используете? Мы, возможно, заказали б себе экземпляр и проверили.
Есть возможность нам сейчас это решить? Нас устроит полное отключение всех сторонних функций кроме стандартного Modbus.
Оборудования много собственного, разного. Там так же используется свои расширения протокола.
Но оборудования этого, повторюсь, уже очень много, и из-за 1 реле на объекте переделать его не представляется возможным.
Ранее реле не вызывали таких проблем. А теперь, увы, прям сильно подпортили нам жизнь.
Это баг в прошивке, будем искать причину и исправлять. Разработчики обещали заняться в начале недели. Сейчас единственный вариант, посадить наши устройства на отдельную шину.
Всё таки расскажите, пожалуйста, какие устройства тоже используют расширение протокола? Нам просто интересно.
Мы сожалеем, что такое случилось. Спасибо за сообщение об ошибке, исправим и сделаем отдельные интеграционные тесты на будущее, которые будут такое поведение выявлять до того, как прошивки попадут к пользователям.
Решили попробовать решить вопрос иначе - поменять скорость работы реле.
У реле была стандартная скорость 9600:
Запрос: B9 03 006E 0001 FE AF // 006E - регистр скорости из документации
Ответ: B9 03 02 00 60 18 77
Т.е. в регистре 96. В доке указано, что скорость x100 бод. Выбрали следующую 38400. И записали 384:
B9 06 006E 0180 F3 5F
B9 06 00 6E 01 80 F3 5F
После данных манипуляций реле перестало отвечать. Пробовали:
9600N1
9600N2
38400N1
38400N2
И ещё ряд вариантов. Тишина. Пробовали перезагружать и переподключать. Тихо.
Или, в доке написано что-то что ввело нас в заблуждения, и писать 384 было нельзя… Или, есть ощущение, что есть ещё один баг со скоростью.
Как воскресить устройство?
Есть ПК win. Какая прошивка в репозитории (S3 Bucket Listing Generator) подходит для устройства WB-MRM2-mini v.2?
Ребят, да всё понимаю. Вопрос не в этом. Вопрос, как решить вопрос.
Возможно есть какой-то режим, который отключит это расширение. Или, возможно, мы можем использовать прошивку без этих возможностей?
Добрый день! Проблему в прошивке нашли исправили. В ближайшее время прогоним тесты и сделаем релиз.
По поводу восстановления настроек есть такой рецепт: подключате питание на устройство, и пока оно 2 секунды мигает, можно ему на 0 адрес на 9600N2 выслать команду записи 6 значения 1 в регистр 1000 - тогда оно сбросит настройки связи. если есть утилита wb-mcu-fw-flasher то это делается ключем -uтут подробнее.
Для того чтобы понять какая у вас прошивка хорошо бы прочитать текстовую строчку из ASCII символов, которая лежит по одному символу в регистре, начиная с регистра 290, нужно прочитать 12 регистров. Пока устройство в загрузчике (2 секунды мигает светодиодом после подачи питания) их также можно прочитать на 9600 по адресу 0, ну или по адресу который настроен на устройстве (0хB9), только загрузчик отдает их только если в запросе количество 12.
Как вариант можете сказать аппаратную ревизию которая написана на наклейке устройства и мы вам скажем какая там была сигнатура.
Спасибо за информацию.
А что скажете про проблему скорости? Тоже баг прошивки?
Рецепт не помог.
Сделали так. Отправили:
00 06 03E8 0001 C9 AB
В ответ: 00 06 03 E8 00 01 C9 AB
Но устройство не ожило. Пробовали и 1-й адрес, и адрес с его этикетки. И 9600N1, и 9600N2.
Попробовали так: 00 06 1000 0001 4D 1B
Ответа вообще нет.
По причине отсутствия ответов от устройства прочитать код не получается.
На этикетке значится следующая информация:
Addr: 185
HW: v2.3S
FW: 1.20.3
159830
Да, верно.
Прочитайте 12 holding регистров, именно 12 одним запросом, начиная с 290 (десятичный) регистра. Используйте Modbus адрес 1. Ну дважды, в промежуток до 2 секунд после подачи питания и после.
на счет скорости проблем быть не должно. эта функциональнасть проверяется автоматическими тестами на каждой прошивке.
проверил сейчас ваш кейс
root@wirenboard-AWGZLBR4:~# modbus_client --debug -mrtu -s2 -pnone /dev/ttyRS485-2 -a 185 -t 3 -r 110
Opening /dev/ttyRS485-2 at 9600 bauds (N, 8, 2)
[B9][03][00][6E][00][01][FE][AF]
Waiting for a confirmation...
<B9><03><02><00><60><18><77>
SUCCESS: read 1 of elements:
Data: 0x0060
root@wirenboard-AWGZLBR4:~# modbus_client --debug -mrtu -s2 -pnone /dev/ttyRS485-2 -a 185 -t 6 -r 110 384
Data to write: 0x180
Opening /dev/ttyRS485-2 at 9600 bauds (N, 8, 2)
[B9][06][00][6E][01][80][F3][5F]
Waiting for a confirmation...
<B9><06><00><6E><01><80><F3><5F>
SUCCESS: written 1 elements!
root@wirenboard-AWGZLBR4:~# modbus_client --debug -mrtu -s2 -pnone /dev/ttyRS485-2 -a 185 -t 3 -r 110 -b 38400
Opening /dev/ttyRS485-2 at 38400 bauds (N, 8, 2)
[B9][03][00][6E][00][01][FE][AF]
Waiting for a confirmation...
<B9><03><02><01><80><18><6F>
SUCCESS: read 1 of elements:
Data: 0x0180
могут ли быть проблемы с применением скорости работы порта ? не хотите попробовать утилиту modbus_client ? здесь подробное описание и как скачать.
загрузчик подтвердил сброс скорости. после этого точно должны быть настройки 9600N2 адрес 1.
устройство одно на шине ? есть ли растягивающие шину резисторы ? другие устройства отвечают на этих настройках если подключить их вместо того, которое перестало отвечать ?
Только что проверил на WB-MRM2-mini, пытался записывать разные значения в регистр скорости. Если случайно записать значение не из списка - не записывается. Предполагаю какую-то проблему с самим реле.
Давайте мы бесплатно поменяем вам оборудование. Курьер привезёт новое оборудование и заберёт старое:
Для записи использовали команду:
B9 06 006E 0180 F3 5F
0x180 = 384. Это число есть в списке, поэтому, вероятно реле его и приняло?
Вы говорите о решении проблемы со скоростью. Но в скорость мы полезли только чтобы попытаться решить основную проблему - нездоровую реакцию реле на чужие команды с 0xFD. Эта проблема уже решилась?
Возможно быстрее решить проблему пере прошивкой, чтобы не гонять в пустую курьеров?
Как раз после (успешного) выполнения модуль начинает работать на 9600 8N2 и имеет адрес 1.
Тут еще может быть что у модуля нет основной прошивки, только bootloader. Тогда - он не будет реагировать на команды, но те же 12 регистров с 290 адреса - можно будет прочитать.