Цитата:
Сообщение от tvf
Ни кто это и не отрицает. Речь шла об информировании слейва, что мастер считал из него все данные корректно. Обоюдный контроль связи, это не только контроль записи в слейв, но и контроль чтения из слейва. Мастер то определит, надо еще сообщить об этом слейву.
|
В том и смысл heartbeat, что данные передаются постоянно с определенной периодичностью, например один раз в секунду или один раз в пять секунд. Это задание состояния управляемому объекту, задание регулируемого параметра, контроль состояния, контроль параметра, контроль аварийного регистра. Даже если проходит 10% пакетов, рано или поздно вся информация доходит. Соответственно время прихода информации удлинняется. При этом запросы портятся примерно одинаково, так что портится и heartbeat (в моем случае unix_time).
Если задание или уставка не меняется, она все равно передается вместе и с периодичностью heartbeat. Слейв уже сам решает, что делать с данными - они пришли но не изменились.
Цитата:
Сообщение от tvf
Контроль записи в слейв с 2 доп. переменными требут как минимум записывать все переменные одним запросом. А если запросов на запись 2 и более? Как вы это делали?
|
Все точно так же. Запросы портятся примерно одинаково.
Цитата:
Сообщение от tvf
Ну и вопрос сконтрольной суммой. Простое суммирование не даст 100% гарантии. CRC16 на FBD реализовывать?
|
CRC уже реализовано в протоколе модбас. Поэтому если данные приняты, соответственно они с очень большой долей вероятности правильные (неправильные данные отбрасываются). Т.е проверка правильности данных лежит на протоколе.
Определение, что какие то данные передаются либо за блоком Device(link) либо за heartbeat. В случае с heartbeat ввиде unix_time имеем дополнительную проверку в виде попадания времени в, допустим 6 часовое окно. Плюс есть источник синхронизации своего времени.