ошибка контрольной суммы в ответе

[In_Da_Cher_A]

ODD, Even 1 или 2 стоп бита как бы к протоколу(ам) отношения не имеют,

с чего бы это

это проверка целостности

целостности чего?

[In_Da_Cher_A]

Even 1 или 2 стоп бита

так вот они вроде как раз для того, чтобы не использовать контроль чётности

скорее железо и прошивка самого прибора не успевает что-то отрабатывать и обрабатывать

железо и прошивка работает с данными, им вообще наплевать, если данные нормальные, а вот если данные "ломаются" по дороге, то вот тогда и будет "ошибка контрольной суммы"

[Валенок]

целостности чего?

Конкретного байта.
И да - я тоже всегда юзаю 8n1

.. железо и прошивка самого прибора не успевает что-то отрабатывать и обрабатывать.

Если Вы про 8AC, то коли нечто от него таки приходит в ответ - успевает. А учитывая #1 последний абзац и #15 5) - слишком успевает ))
Если мы про модбас, то на 115200 минимально - в 2 раза больше.

[Валенок]

to Денис Гладышев
А есть возможность привести побайтный состав запросов/ответов к 8AC ?
особенно тех которые битые по ответу

[melky]

Ну есть проверки целостности байта до протокола и уже на уровне протокола, вместо Modbus может быть что угодно.
Кстати да, если 8АС отвечает, то она то точно успела принять запрос и он корректный.
з.ы. у меня как-то вместе 8АС и МЭ110-1М вместе не работали на одной линии, кажется в МЭ пришлось ждать обновления прошивки, после чего все заработало. Опрос тогда был со стороны ПЛК100 через конфигурацию.
Может и тут какой-то из модулей "фонит" в линии?

[melky]

Вариант, что не хватает времени принять весь ответ от 8АС и нет проверки длины ответа, сразу попытка проверять контрольную сумму?

[In_Da_Cher_A]

Конкретного байта.

данных? значит это имеет прямое отношение к протоколу, хотя коллега melky утверждает, что нет
вот я читаю описание протокола

Структура данных в режиме RTU
В режиме RTU данные передаются младшими разрядами вперед (рис. 2.26).

По умолчанию в RTU режиме бит паритета устанавливают равным 1, если количество двоичных единиц в байте нечетное, и равным 0, если оно четное. Такой паритет называют четным (even parity) и метод контроля называют контролем четности.

Screenshot_66.png
Рис. 2.26. Последовательность битов в режиме RTU; МЗР – младший значащий разряд. При отсутствии бита паритета на его место записывается второй стоп-бит

При четном количестве двоичных единиц в байте бит паритета может быть равен 1. В этом случае говорят, что паритет является нечетным (odd parity).

Контроль четности может отсутствовать вообще. В этом случае вместо бита паритета должен использоваться второй стоповый бит. Для обеспечения максимальной совместимости с другими продуктами рекомендуется использовать возможность замены бита паритета на второй стоповый бит.

Ведомые устройства могут воспринимать любой из вариантов: четный, нечетный паритет или его отсутствие.

Структура Modbus RTU сообщения
Сообщения Modbus RTU передаются в виде кадров, для каждого из которых известно начало и конец. Признаком начала кадра является пауза (тишина) продолжительностью не менее 3,5 шестнадцатеричных символов (14 бит). Кадр должен передаваться непрерывно. Если при передаче кадра обнаруживается пауза продолжительностью более 1,5 шестнадцатеричных символа (6 бит), то считается, что кадр содержит ошибку и должен быть отклонен принимающим модулем. Эти величины пауз должны строго соблюдаться при скоростях ниже 19200 бит/с, однако при более высоких скоростях рекомендуется использовать фиксированные значения паузы, 1,75 мс и 750 мкс соответственно.

Контроль ошибок
В режиме RTU имеется два уровня контроля ошибок в сообщении:

контроль паритета для каждого байта (опционно);

контроль кадра в целом с помощью CRC метода.

CRC метод используется независимо от проверки паритета. Значение CRC устанавливается в ведущем устройстве перед передачей.
При приеме сообщения вычисляется CRC для всего сообщения и сравнивается с его значением, указанным в поле CRC кадра. Если оба значения совпадают, считается, что сообщение не содержит ошибки.

Стартовые, стоповые биты и бит паритета в вычислении CRC не участвуют.

а у автора - ошибка контрольной суммы в ответе
сдаётся мне, что проблема совсем не в модуле

[Валенок]

Вариант,...

Ну на фоне того что 8AC слишком шустрый:

.. из отличительного по сравнению с другими модулями то, что длительность между концом передачи мастера и началом ответа слейва на ПОРЯДОК меньше, чем у остальных блоков..

вытекает что мастер не успевает переключается в чтение. И проблема - в мастере.
Да и подтверждается другим мастером:

было странным то, что с одним единственным СПК107 (стареньким) модуль не выдавал ошибки по контрольной сумме и все было ОК..

Но мастер имеет право предъявить про непротокольную шустрость ))


Но! Не бьётся с этим:

.. помогло изменение с ODD на None...

... в режиме None данный промежуток такой же, но ошибок по контрольной сумме не наблюдается).

--
поэтому и попросил п#24

[Валенок]

данных?

Причем тут данные ? Сказано же - конкретного байта. К остальным - пофиг.

[Васильев]

1. в одном мануале от овен написано, что аппаратно не поддерживается контроль четности
(надо поискать)
2. в проекте (который я думаю решил) при обмене периодически возникала ошибка кс,
модули на дин рейке рядом, соединение хорошими обычными одножильными проводами
банальное решение - простая витая пара из кабеля UTP и терминальный резистор 120 ом и нет ни одной ошибки кс.