caxapa.ru :: глянул в их код. доставило check_CRC(). а ещё дисклеймер в камментах с занимательными табличками бито-таймаутов, мол через USB-свистки может нихрена с таймаутами не получиться.

Vit (14.07.2025 13:28 - 14:40, просмотров: 73) ответил Cкpипaч на Вруг кому попадался на глаза работающий пример с pymodbus.client.AsyncModbusSerialClient - помогите утолить жажду знания :)

глянул в их код. доставило check_CRC(). а ещё дисклеймер в камментах с занимательными табличками бито-таймаутов, мол через USB-свистки может нихрена с таймаутами не получиться.

Ответить

- Ткни пальцем, где, плиз :) - Cкpипaч(14.07.2025 13:37)
  - всё в pymodbus-dev/pymodbus/framer/rtu.py Vit(255 знак., 14.07.2025 14:42)
    - 1) return 0, 0, 0, self.EMPTY; 2) 2ms@19200bps - ничего неожиданного, как по мне. - Cкpипaч(14.07.2025 15:34)
      - контрольная сумма на всю длину должна дать ноль. и нормально именно это проверять. а тут сначала закат Солнца вручную, потом вызов табличного расчёта - вроде как для проверки на равно - Vit(14.07.2025 16:09)
        
        У них CRC проверяется "в цикле" на несколько вариантов окончания приема. Напрочь не понял что ты считаешь "закатом вручную". Cкpипaч(1316 знак., 14.07.2025 17:37)
        
        CRC должен считаться на всю длину пакета. и пох на варианты нутрянки. это арифметика. выбоены с последней парой байт (где укладывается CRC) это мрак. при этом кросавчеги намалевали табличный расчёт, который используют только в том маразме. по сути decode должен вызываться после таймаута на разрыв пакета и сам пакет уже есть. его не имеет смысла скрести по частям. ему сразу после транспортной части определяют битость, а не скребутся по расчётам длин исходя из кишок. а уже Vit(578 знак., 14.07.2025 18:17)
        
        Как один из способов определения окончания кадра при кривых времянках. - Nikolay_Po(14.07.2025 18:00)

Кибернетика, автоматика, протоколы