Пакет запроса данных от слэйва, посылает мастер:
1 байт - адрес слэйва, у кого запрашиваем.
2 байт - номер функции, сообщаем, какие данные хотим получить, из какой области:флаги, Di, Ai, holding reg.
3 байт - старший байт от integer, определяющий адрес начального регистра
4 байт - младший байт от integer, определяющий адрес начального регистра
5 байт - старший байт от integer, определяющий количество запрашиваемых регистров. При правиле - максимум байт данных в пакете 253 равен 0.
6 байт - младший байт от integer, определяющий количество запрашиваемых регистров.
7 байт - старший байт CRC, контрольная сумма, выполненая с использованием всех предыдущих байт по алгоритму CRC16
8 байт - младший байт CRC
CRC к данным не относится, отсутствует при обмене по ТСР, это два дополнительных байта к упомянутым выше 253-м байтам.
Ответ от слэйва при запросе одного регистра.
1 байт - мой адрес, это у меня спрашивали, я и отвечаю.
2 байт - номер функции, на которую я отвечаю.
3 байт - сейчас будет вот такое количество байт из запрошенных регистров, 2 х количество регистров
4 байт - старший байт регистра
5 байт - младший байт регистра
6 байт - старший байт CRC
7 байт - младший байт CRC
Получаем, распределяем в соответствующие ячейки.
Это значит, для получения данных одного integer, самого распространённого у нас, мы отправляем 8 байт и получаем 7.
На два байта информации.
Вот так работает мастер модбас в Flprog, один в один.
При неполучении данных в установленное время, как правило, 1000мс, формируется новый запрос для следующего регистра.
Если у Вас в проекте несколько регистров в нескольких слэйвах, то при отключении одного устройства, его регистры продолжают
опрашиваться, умножая время "зависания", 1000мс, на количество регистров в устройстве.
Есть, конечно-же, возможность, получать данные с нескольких регистров сразу, в один запрос.
И слэйв FLProg это умеет!!!
Но вся проблема в том, что это не совсем будет корретно работать, из-за того, что пользователи не всегда создают регистры подряд.
Тогда, при запросе регистра, которого нет, слэйв вернёт ошибку.
Иногда пропуск регистра возникает из-за того, что пользователь его создал, но в проекте не использовал
- компилятор не вставит его в код программы, будет пропуск.
Однако, если нормально отнестись к созданию регистров, рациональному их использованию в программе - всё можно поправить.
Рационально - не слать флоаты, т.к. процес их разборки - сборки не слишком быстр, вместо них использовать х10 или 100 integer.
Собирать дискретные сигналы в вибе битов в integer, блоки то есть для сборки и разборки.
Для опроса нескольких регистров, иногда всех, с одного устройства в один запрос в других системах используют так называемые каналы.
Параметры канала: тип используемой функции, начальный адрес, количество регистров.
Привязку полученных данных регистров к переменных осуществляют отдельно.
Что получаем на выходе?
Например, опрашиваем 10 регистров, при отвале слэйва - задержка перед опросом следующего 1000мс.
Количество байт: запрос 8 байт(один!!!), ответ 25 байт(тоже один!). всё.
Как я вижу, сложность в связке данных в полученном массиве и переменных проекта - памяти у 328 не шибко. в stm32 проблем никаких.
Для примера приведу проект, сделанный по просьбе одного нашего форумчанина, в котором можно опрашивать несколько устройств,
задавая их адреса, начальные регистры через входы блоков, не константы. Опрашиваются по два регистра. На выходах данные в виде байтов.
При желании можно сделать вообще любого типа, и с любым количеством, но я считаю оптимальным тип integer - с ним можно всё.
Так-же там присутствует выход новые данные, 1 на 1 цикл. Можно использовать как сигнал "данные актуальны", можно как ....
Для упрощения построения алгоритма, и кода соответственно, использовать слэйвы с одинаковым количеством регистров,
ненужные обязательно задействовать на платах, хоть отдельно взятой, хоть для дублирования - главное, чтобы компилятор прописал их в коде.
Как использую данную концепцию я?
СпойлерПоказать
нужные мне разбросаны по всей, где-то рядом парочка другие через один-два,
И ещё - ВСЕГДА использовать модули связи без эха, а то посмотришь какие схемы 485 предлагают в нете, то аж жуть, как представлю, что
творится в буфере приёма.
Ещё один момент - отправка данных в слэйв.
Вопрос совсем не тривиальный, как кажется на первый взгляд, говорю по собственному опыту.
Для этого нужно встроить отправку в проццес опроса, прервав его на время отправки данных и получения подтверждения доставки.
(конфигурация ,архитектура)
