SKV - не слушайте никого про case. Case, case и еще раз case - удобней и читаемей.
А для ликвидации пустых шагов - while true do с return/exit в шагах при необходимости
SKV - не слушайте никого про case. Case, case и еще раз case - удобней и читаемей.
А для ликвидации пустых шагов - while true do с return/exit в шагах при необходимости
Речь не идет о исключении CASE и свитч-технологий из обихода) Речь идет об оптимизации выполнения чтения-записи в одной единственной функции/функциональном блоке. В моем примере видно метку "шага" 2: того же самого CASE.
Валенок, вы опытный и мудрый программист, но здесь не хотите вникать снова )
Последний раз редактировалось spectrum48k; 18.09.2015 в 14:42.
Так как я предложил:
pDisp^();
pDisp^();
pDisp^();
Решает проблему с лишними сканами.
Отмечу также, что лишние сканы влияют на время между опросами, а не на время опроса модуля.
Саму идею использования If вместо, case там где нужно, чтобы на том же скане мы переходили на следующий шаг, буду иметь ввиду.
Последний раз редактировалось Спорягин Кирилл; 18.09.2015 в 14:52.
Обязательно изучите modbus.lib, а именно FB приема на наличие таймера таймаута t#3ms на предмет его необходимости и влияния этого таймера скорость работы биб-ки в части завершения ожидания приема буффера данных.
З.Ы. (да где вообще разработчики взяли это время...это не 1,5 и не 3,5 символа)
Последний раз редактировалось spectrum48k; 18.09.2015 в 15:32.
какие у кого решения ищите сами, на вкус и цвет ...
у меня есть свой взгляд на такой опрос и меня он вполне устраивает
я добрался до дома, посмотрел ваш проект, слишком всё заморочено, спецам Ваш код бесполезен, новички в нем не разберутся и зачем он такой нужен
что касается времен опроса при разных временах мин.цикла, они такие как есть,но я уже писал что на одной и той же скорости сам обмен время не поменяет, проблемы только с отображением результата в текущем циикле, причем это сильно зависит от полноты наполнения проекта, на видео которое выкладываю при работе только одного TON-а среднее время было 8мс, добавив второй таймер среднее время увеличилось на 2мс, уже не говорю если это будет полноценный проект. Кроме того на видео показал время свободное от работы процессора, мин.цикл лучше подбирать, чтоб оставался некоторый запас микросекунд. Я не сторонник нуля в мин.цикле, если хочется свободное выполнение для этого есть конфигуратор задач. Еще Вы что то писали про операции обмена после выполнения PLC_PRG, тогда стоит рассмотреть ситуацию с модбасом мастером в конфигураторе и программой в стопе, удивительно на данные из слейва будут читаться, так что по моему мнению искать связь выполнения программы и обмена не стоит и уменьшение ради этого мин.времени цикла бесполезное занятие и вообще это может привести к нестабильному или приему с большим количеством ошибок
ну не Вы же написали эту бибку, Вы ей только пользуетесь и цокаете и чем Вы отличаетесь от меня тогда? Поставил человек 3мс и ладно, не сильно это будет тормозить в отличии от 3,5 символов(да где вообще разработчики взяли это время...это не 1,5 и не 3,5 символа)
ЗЫ для видео увеличил время первого таймера до 300мс, но его можно поставить чуть больше среднего времени
Последний раз редактировалось capzap; 18.09.2015 в 18:22.
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Вынужден расстроить: ей только и не пользуюсь и не пользовался. Перед первым использованием открыл, изучил и передумал использовать. Написал в мае-июне свой луна-паркс блекджеком и плюшками. До этого пользовался конфигуратором. Как я ранее писал, конфигуратор меня очень расстроил. А вообще, я - фанат IOScanner )) Но об этом в другом форуме (se-automation.in.ua).ну не Вы же написали эту бибку, Вы ей только пользуетесь и цокаете и чем Вы отличаетесь от меня тогда? Поставил человек 3мс и ладно, не сильно это будет тормозить в отличии от 3,5 символов
Последний раз редактировалось spectrum48k; 18.09.2015 в 21:17.
да меня это вобще не задевает, чем Вы пользуетесь. Полноценный проект обычно занимает не менее 2мс, пауза между фреймами по стандарту не должна быть меньше этих пресловутых 3,5 символов, но больше то ни кто не запрещает, поэтому 3мс в бибке ни как не скажутся на работе, тем более приведенные здесь статистические данные относятся к 4 байтам, а в рабочих проектах выборка данных на много больше, таким образом гипотетически следующий запрос можно смело посылать в следующем цикле, вот только кто так делает
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
3,5 символа, это вообще по-хорошему интервал для ведомого, перед ответом ведущему. Мастер же не должен ничего ждать, если размер принятого буффера равен ожидаемому размеру. И после проверки CRC, адреса, функции и дальнейшей разборки пакета, должен в этом же вызове накормить следующий буфер отправки. Вот это было бы логично и быстро. А при использовании modbus.lib, давайте при готовом принятом буфере отдадим ~t#10ms основному вызову проекта каждый раз после принятого буфера. Для 8 регистров это будет каких-то t#80ms. Не мешает? Да пользуйтесь на здоровье. Плачьте и колитесь) Кактуса хватит на всех. А если опрос и проект(алгоритм) не разнесены по разным задачам, то это будет вообще паровоз....
повторюсь, я веду речь о модбас rtu, цитата из вики:" Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс, соответственно" ни о какой паузе между запросом и ответом речь не идет,хотя и включает в себя эту ситуацию тоже
что касается должен ли чего то ждать мастер, это обусловленно концепцией контроллеров, если в моем примере обработку ответа поставить в начало поу, так и выйдет получив ответ прога может сразу,в этом же цикле, отправить очередной запрос
а последняя часть Вашего опуса вобще какой то бред, неимеющий ни какого отношения к передаче данных
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Сергей, не спешите приписывать мне патологическое расстройство сознания - вы не психиатр) Мой "бред" как раз опровергает это:
О Вашем примере речи не было, я его даже не смотрел, т.к. Вы не предложили это сделать)поэтому 3мс в бибке ни как не скажутся на работе
Если мои рассуждения не верны по-вашему, Вы можете обосновать свою точку зрения, а не приписывать диагнозы))