FlProg

Вопрос использующим или знающим.
Если группируем теги, то запрос на чтение всех сразу? И как формируется запрос если в группе несколько групп? Отправлено спустя 10 минут 18 секунд:
Если я хоть что то понял, то запросы по группам? Итого 4 объединенных по тегам запроса каждый период заданного опроса?
[spoiler][/spoiler]

Отправлено спустя 7 минут 52 секунды:
Увеличил время опроса до 1 секунды для уточнения деталей. Похоже так и есть. Объединенный запрос для тегов в группе. Расположение группы, не влияет на объединение.
Всем спасибо за внимание, тему можно закрывать
[spoiler][/spoiler]

У тега есть опция - последний в групповом запросе. Разбивает на несколько посылок.
Применение - буфер у слэйва меньше чем мы хотим считать всего.
Есть устройства, где адреса подряд, а считывать можно только по одному.

Отправлено спустя 27 минут 8 секунд:
По скрину, последнему, видно, как слэйв матерится
Но не могу понять ответ.
Там, где с адреса 0 19 регистров запрос.
Или это долго идут ответы...

Sancho писал(а): 03 июл 2020, 14:39 У тега есть опция - последний в групповом запросе. Разбивает на несколько посылок.
Применение - буфер у слэйва меньше чем мы хотим считать всего.
Есть устройства, где адреса подряд, а считывать можно только по одному.

Александр, я еще очень далек от таких подробностей. Пока из разряда - "нифига не понятно, но интересно"
Меня интересуют очень два вопроса:
поддерживает ли Flprog групповые запросы (если да, то какой "длинны")
как добиться адекватной работы от контроллера (если дело только в нем) с большим (до 100 int хотя бы) кол-вом тегов
Оптимизацию по упаковке/распаковке рассматривать не будем. Причем проблема (по крайней мере на avr) не лечится ни скоростью порта, ни переходом на tcp
Только сегодня опять собирал тестовый вариант и что на 9600, что на 115200 время обмена 19 int ~200ms.
Фигово когда не понимаешь где копать...

[ref]Ingwar[/ref], Игорь.
По умолчанию у 328 в библиотеке буфер хардсериал приёма и передачи составляет по 64 байта.
Для режима слэйв
приёмного хватает практически всегда.
передача по MB - байты - 1 адрес, 1 номер функции, 1 кол-во байт в ответе, 2 CRC, остальное - для данных, а именно 59 байт.
т.о. максимум 59/2=29 int.
Все адреса в таком случае идут без пропусков, имеем один групповой запрос.
FLP поддерживает все режимы MB, и даже генерацию ответа с ошибками.
Если у Вас кол-во интов более 29, даже и идут подряд, в ОРС нужно в необходимом месте тэга установить "последний тэг в групповом запросе". После этого ОРС разобьёт запрос на два, три и т.д.
"Буферы" MB и serial это разные массивы.

Отправлено спустя 10 минут 28 секунд:
Если Вы создали тэг с адресом, например, 6, но не использовали его в проекте, FLP не создаст его в коде и Вы будете получать ошибки при его штучном опросе или при групповом, в котором будете пытаться его опросить!

Sancho писал(а): 03 июл 2020, 15:51 По умолчанию у 328 в библиотеке буфер хардсериал приёма и передачи составляет по 64 байта.

А почему тогда TCP не решает проблему? Это же не serial.

Отправлено спустя 1 минуту 23 секунды:
Или там свой "кастрированный" буфер?

Отправлено спустя 14 минут 23 секунды:

Sancho писал(а): 03 июл 2020, 15:51 Если у Вас кол-во интов более 29

И опять же, в выложенном скрине было 19 int, 8 coil, 3 float, 3 long, соответственно каждый запрос укладывался в буфер. Но время ответа было - 2 по 84 ms и 2 по 189ms независимо от скорости порта... как так?

Игорь, можно тестовый проект в личку?

Sancho писал(а): 03 июл 2020, 17:18 можно тестовый проект в личку?

Смогу только в понедельник...