Конфигуратор vs modbus.lib

[capzap]

capzap, пруфлинк, пожалуйста, на достойное решение с поллингом (диспетчером опроса группы ведомых с разным интервалом опроса для каждого)

какие у кого решения ищите сами, на вкус и цвет ...
у меня есть свой взгляд на такой опрос и меня он вполне устраивает

Capzap, я тоже не понимаю, почему Вы так недоброжелательно ко мне настроены.
Я делюсь своими наработками, считая, что это кому-то может пригодиться.
Все что я пишу и выкладываю, я в свое время пытался найти на форуме, но не нашел. Надейюсь, что другим будет проще.

я добрался до дома, посмотрел ваш проект, слишком всё заморочено, спецам Ваш код бесполезен, новички в нем не разберутся и зачем он такой нужен

что касается времен опроса при разных временах мин.цикла, они такие как есть,но я уже писал что на одной и той же скорости сам обмен время не поменяет, проблемы только с отображением результата в текущем циикле, причем это сильно зависит от полноты наполнения проекта, на видео которое выкладываю при работе только одного TON-а среднее время было 8мс, добавив второй таймер среднее время увеличилось на 2мс, уже не говорю если это будет полноценный проект. Кроме того на видео показал время свободное от работы процессора, мин.цикл лучше подбирать, чтоб оставался некоторый запас микросекунд. Я не сторонник нуля в мин.цикле, если хочется свободное выполнение для этого есть конфигуратор задач. Еще Вы что то писали про операции обмена после выполнения PLC_PRG, тогда стоит рассмотреть ситуацию с модбасом мастером в конфигураторе и программой в стопе, удивительно на данные из слейва будут читаться, так что по моему мнению искать связь выполнения программы и обмена не стоит и уменьшение ради этого мин.времени цикла бесполезное занятие и вообще это может привести к нестабильному или приему с большим количеством ошибок

(да где вообще разработчики взяли это время...это не 1,5 и не 3,5 символа)

ну не Вы же написали эту бибку, Вы ей только пользуетесь и цокаете и чем Вы отличаетесь от меня тогда? Поставил человек 3мс и ладно, не сильно это будет тормозить в отличии от 3,5 символов

ЗЫ для видео увеличил время первого таймера до 300мс, но его можно поставить чуть больше среднего времени

[Валенок]

SKV - не слушайте никого про case. Case, case и еще раз case - удобней и читаемей.
А для ликвидации пустых шагов - while true do с return/exit в шагах при необходимости

[spectrum48k]

Речь не идет о исключении CASE и свитч-технологий из обихода) Речь идет об оптимизации выполнения чтения-записи в одной единственной функции/функциональном блоке. В моем примере видно метку "шага" 2: того же самого CASE.

Валенок, вы опытный и мудрый программист, но здесь не хотите вникать снова )

[Спорягин Кирилл]

Речь не идет о исключении CASE и свитч-технологий из обихода) Речь идет об оптимизации выполнения чтения-записи в одной единственной функции/функциональном блоке. В моем примере видно метку "шага" 2: того же самого CASE.

Так как я предложил:
pDisp^();
pDisp^();
pDisp^();

Решает проблему с лишними сканами.
Отмечу также, что лишние сканы влияют на время между опросами, а не на время опроса модуля.

Саму идею использования If вместо, case там где нужно, чтобы на том же скане мы переходили на следующий шаг, буду иметь ввиду.

[spectrum48k]

Обязательно изучите modbus.lib, а именно FB приема на наличие таймера таймаута t#3ms на предмет его необходимости и влияния этого таймера скорость работы биб-ки в части завершения ожидания приема буффера данных.
З.Ы. (да где вообще разработчики взяли это время...это не 1,5 и не 3,5 символа)

[spectrum48k]

ну не Вы же написали эту бибку, Вы ей только пользуетесь и цокаете и чем Вы отличаетесь от меня тогда? Поставил человек 3мс и ладно, не сильно это будет тормозить в отличии от 3,5 символов

Вынужден расстроить: ей только и не пользуюсь и не пользовался. Перед первым использованием открыл, изучил и передумал использовать. Написал в мае-июне свой луна-паркс блекджеком и плюшками. До этого пользовался конфигуратором. Как я ранее писал, конфигуратор меня очень расстроил. А вообще, я - фанат IOScanner )) Но об этом в другом форуме (se-automation.in.ua).

[capzap]

да меня это вобще не задевает, чем Вы пользуетесь. Полноценный проект обычно занимает не менее 2мс, пауза между фреймами по стандарту не должна быть меньше этих пресловутых 3,5 символов, но больше то ни кто не запрещает, поэтому 3мс в бибке ни как не скажутся на работе, тем более приведенные здесь статистические данные относятся к 4 байтам, а в рабочих проектах выборка данных на много больше, таким образом гипотетически следующий запрос можно смело посылать в следующем цикле, вот только кто так делает

[spectrum48k]

да меня это вобще не задевает, чем Вы пользуетесь. Полноценный проект обычно занимает не менее 2мс, пауза между фреймами по стандарту не должна быть меньше этих пресловутых 3,5 символов, но больше то ни кто не запрещает, поэтому 3мс в бибке ни как не скажутся на работе, тем более приведенные здесь статистические данные относятся к 4 байтам, а в рабочих проектах выборка данных на много больше, таким образом гипотетически следующий запрос можно смело посылать в следующем цикле, вот только кто так делает

3,5 символа, это вообще по-хорошему интервал для ведомого, перед ответом ведущему. Мастер же не должен ничего ждать, если размер принятого буффера равен ожидаемому размеру. И после проверки CRC, адреса, функции и дальнейшей разборки пакета, должен в этом же вызове накормить следующий буфер отправки. Вот это было бы логично и быстро. А при использовании modbus.lib, давайте при готовом принятом буфере отдадим ~t#10ms основному вызову проекта каждый раз после принятого буфера. Для 8 регистров это будет каких-то t#80ms. Не мешает? Да пользуйтесь на здоровье. Плачьте и колитесь) Кактуса хватит на всех. А если опрос и проект(алгоритм) не разнесены по разным задачам, то это будет вообще паровоз....

[capzap]

повторюсь, я веду речь о модбас rtu, цитата из вики:" Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс, соответственно" ни о какой паузе между запросом и ответом речь не идет,хотя и включает в себя эту ситуацию тоже
что касается должен ли чего то ждать мастер, это обусловленно концепцией контроллеров, если в моем примере обработку ответа поставить в начало поу, так и выйдет получив ответ прога может сразу,в этом же цикле, отправить очередной запрос
а последняя часть Вашего опуса вобще какой то бред, неимеющий ни какого отношения к передаче данных

[spectrum48k]

повторюсь, я веду речь о модбас rtu, цитата из вики:" Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс, соответственно" ни о какой паузе между запросом и ответом речь не идет,хотя и включает в себя эту ситуацию тоже
что касается должен ли чего то ждать мастер, это обусловленно концепцией контроллеров, если в моем примере обработку ответа поставить в начало поу, так и выйдет получив ответ прога может сразу,в этом же цикле, отправить очередной запрос
а последняя часть Вашего опуса вобще какой то бред, неимеющий ни какого отношения к передаче данных

Сергей, не спешите приписывать мне патологическое расстройство сознания - вы не психиатр) Мой "бред" как раз опровергает это:

поэтому 3мс в бибке ни как не скажутся на работе

О Вашем примере речи не было, я его даже не смотрел, т.к. Вы не предложили это сделать)
Если мои рассуждения не верны по-вашему, Вы можете обосновать свою точку зрения, а не приписывать диагнозы))