Коллизии в данных по modbus

Добрый день!
Периодически на больших объектах сталкиваемся с кривыми данными. Под подозрением коллизии в crc32. Есть ли какие-нибудь предположения и идеи в чем может быть проблема и как можно исправить?

выкладывайте все логи, будем смотреть…

Надо понимать, что вероятность иметь правильную crc16 при ошибке в приёме бита с данными - это собственно 2^-16. При этом ошибка должна попасть ещё на часть ответа с данными, а не на заголовок - это ещё x2.

Поэтому если у вас на одну штуку кривых данных не приходится десятки тысяч пакетов с битой crc (а это будет в логах wb-mqtt-serial), то скорее всего дело в чём-то ещё.

В день 1000 записей с ошибками, судя по логу. В debug логи пока не писал.
modbus.txt (160.6 КБ)

ну это всё request timed out - отсутствие ответа. Были бы про неправильный crc.

А, смысл понял. Буду изучать дальше. Спасибо!

Таймаут может случиться по трем причинам:

  • данные мастер отправил, но слейв их не получил (помеха повредила бит, например)
  • данные слейв получил но не ответил
  • Слейв ответил, но мастер не получил

Столкнулся с такой проблемой (дивайс - см. топик про расходомер с нестандартными командами).
Некое время слейв отвечает штатно, затем (может пройти несколько дней) “зависает” и отваливается по таймаутам.
При этом, если отключить WB6 от питания (reboot, poweroff НЕ помогают), коммуникация восстанавливается. Ведомый прибор при этом не трогаю.

Есть ли какие-то дыры, дающие вероятность “железного залипания” шины RS485 и как их избегать? Встроены ли клемпы по A и B проводам, на какое они напряжение? Или лучше дополнительно защититься электрически? Все глюки на данный момент происходили со слейвами, запитанными самостоятельно. Те, кто кормятся от того же источника, что и WB, ни разу не висли. Зависал и гальваноизолированный интерфейс (/dev/ttyMOD1), и штатные.

Спасибо за тык в нужное место, если вопрос уже обсуждался.

Хм. А земли-то контроллера (или земля изолированного интерфейса) с землей ("-" питания) расходомера соединены? Понимаю что вопрос банальный, но…

К сожалению, ответ тоже банальный.
Если надо какие ограничители навтыкать, я сделаю, конечно, но наврядли их нет в базе.

Так… Вообще - ну не должно та быть. Сейчас устройство (расходомер) подключено к какому порту?
Подключено ли что-нибудь вместе с ним? Где-то мелькало что устройство “висло” держа своим передатчиком линии порта.
предлагаю при следующем инциденте попробоапть отключить именно провода от порта и попробовать подключить к порту что-то другое - для проверки.

Я еще разок проверю удаленно, ибо с тестером туда ехать пока не получается. Близнец расходомера годами пашет с промышленным контроллером и не икал пока. Не показатель, конечно.

А проверю вот что. Ни reboot, ни poweroff ситуацию не меняли, но разочек контроллер ребутнулся по вочдогу (service nginx stop поставило его в клинч) и шина заработала. Случайность, нет - не знаю.

Нет, это было совпадение, увы.
Кроме расходомера на шине ничего не висит, длина кабла метров 40, экранирован с заземлением у wb6, 9600бпс.