Добрый день!
Периодически на больших объектах сталкиваемся с кривыми данными. Под подозрением коллизии в crc32. Есть ли какие-нибудь предположения и идеи в чем может быть проблема и как можно исправить?
выкладывайте все логи, будем смотреть…
Надо понимать, что вероятность иметь правильную crc16 при ошибке в приёме бита с данными - это собственно 2^-16. При этом ошибка должна попасть ещё на часть ответа с данными, а не на заголовок - это ещё x2.
Поэтому если у вас на одну штуку кривых данных не приходится десятки тысяч пакетов с битой crc (а это будет в логах wb-mqtt-serial), то скорее всего дело в чём-то ещё.
ну это всё request timed out - отсутствие ответа. Были бы про неправильный crc.
А, смысл понял. Буду изучать дальше. Спасибо!
Таймаут может случиться по трем причинам:
- данные мастер отправил, но слейв их не получил (помеха повредила бит, например)
- данные слейв получил но не ответил
- Слейв ответил, но мастер не получил
Столкнулся с такой проблемой (дивайс - см. топик про расходомер с нестандартными командами).
Некое время слейв отвечает штатно, затем (может пройти несколько дней) “зависает” и отваливается по таймаутам.
При этом, если отключить WB6 от питания (reboot, poweroff НЕ помогают), коммуникация восстанавливается. Ведомый прибор при этом не трогаю.
Есть ли какие-то дыры, дающие вероятность “железного залипания” шины RS485 и как их избегать? Встроены ли клемпы по A и B проводам, на какое они напряжение? Или лучше дополнительно защититься электрически? Все глюки на данный момент происходили со слейвами, запитанными самостоятельно. Те, кто кормятся от того же источника, что и WB, ни разу не висли. Зависал и гальваноизолированный интерфейс (/dev/ttyMOD1), и штатные.
Спасибо за тык в нужное место, если вопрос уже обсуждался.
Хм. А земли-то контроллера (или земля изолированного интерфейса) с землей ("-" питания) расходомера соединены? Понимаю что вопрос банальный, но…
К сожалению, ответ тоже банальный.
Если надо какие ограничители навтыкать, я сделаю, конечно, но наврядли их нет в базе.
Так… Вообще - ну не должно та быть. Сейчас устройство (расходомер) подключено к какому порту?
Подключено ли что-нибудь вместе с ним? Где-то мелькало что устройство “висло” держа своим передатчиком линии порта.
предлагаю при следующем инциденте попробоапть отключить именно провода от порта и попробовать подключить к порту что-то другое - для проверки.
Я еще разок проверю удаленно, ибо с тестером туда ехать пока не получается. Близнец расходомера годами пашет с промышленным контроллером и не икал пока. Не показатель, конечно.
А проверю вот что. Ни reboot, ни poweroff ситуацию не меняли, но разочек контроллер ребутнулся по вочдогу (service nginx stop поставило его в клинч) и шина заработала. Случайность, нет - не знаю.
Нет, это было совпадение, увы.
Кроме расходомера на шине ничего не висит, длина кабла метров 40, экранирован с заземлением у wb6, 9600бпс.