8 мс это и есть минимальный и максимальный цикл. цикл стабилен +-10%
8 мс это и есть минимальный и максимальный цикл. цикл стабилен +-10%
Тролль-наседка, добрый, нежный и ласковый
Если я буду знать время обработки каждого из ФБ, порядок обработки ФБ и длительность внутреннего такта работы программы (период выполнения основного внутреннего цикла программы) я смогу с достаточной точностью рассчитать предполагаемое время цикла работы прибора, что в свою очередь позволит провести оптимизацию алгоритма по быстродействию БЕЗ ЗАГРУЗКИ программы в прибор.
Как пример: удаление 1 RS триггера из алгоритма уменьшает "Среднее время цикла" на 0,1 мс (если я правильно помню, но порядок примерно такой).
Кстати - при загрузке пустого проекта в прибор "Среднее время цикла" составляет 0,55 мс.
Я прекрасно понимаю, что основное назначение ПР110 это управление "большими железяками", и поэтому мои вопросы кажутся запросами перфекциониста.
С другой стороны знание тонкостей работы прибора, "незначительных" с точки зрения "больших железяк", позволит обоснованно применять этот прибор в более "тонких" областях, и, естественно, облегчит разработку новых изделий (сократит период "плясок с бубном" при пусконаладке).
Владислав, Юрий и wal79, раз уж теперь программы строятся по принципу, если элемент занимает много времени его надо выкинуть, не могли бы Вы для меня создать ОЛ с юнит-тестами, мне вот такой подход привычнее, да и Владимир Ситников наверное обрадуется
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Собственно при работе над своим текущем проектом я понял чего не хватает:
1. Очень хотелось бы иметь следующие ФБ: 3И, 4И, 3ИЛИ, 4ИЛИ, 3И-НЕ, 4И-НЕ, 3ИЛИ-НЕ, 4ИЛИ-НЕ, 2И-НЕ, 2ИЛИ-НЕ (например для реализации функции 4ИЛИ-НЕ необходимо поставить ЧЕТЫРЕ!!! ФБ).
Мой опыт в программировании МК говорит мне, что сделать эти ФБ - "как 2 байта переслать".
2. Ну и уже упоминал о введение в режим симуляции меток времени, отражающих реальное (хотя бы приблизительно) время отработки ФБ.
3.Забыл упомянуть еще логический коммутатор, хотя бы на 2 входа.
Последний раз редактировалось Vish57; 15.02.2018 в 09:20.
По первому вопросу зайдите в онлайн базу, часть из макросов есть, остальные открываете на редактирование, добавляете сохраняете как 2ИЛИ-НЕ и используете сколько нужно, по времени займет меньше, чем Вы писали сообщение. Не вижу смысла тратить время на макросы 5И, 8И 30И и т.д
По 3 пункту, опять путь в базу, там есть много всего, даже если не подойдет на 100%, можно открыть добавить необходимое.
По 2 пункту, не совсем понятно, что Вам это даст, в OWENLogic вы не работаете с процессором напрямую, это не тот случай, когда переходя с С на ассемблер вы сможете реально влиять на быстродействие.
С уважением, Ревака Юрий.
Инженер группы технической поддержки компании "ОВЕН"
e-mail: yu.revaka@owen.ru
Шаблон описания ошибки ПР или OL http://ftp-ow.owen.ru/softupdate/OWE...s/Shablon.docx
Видео уроки по ПР200 и OWEN Logic http://edu.owen.ru/series/pr200_rev/
Другие видеоролики по тематике ПР https://www.youtube.com/channel/UCj4...H5H3d_t6iDlQOQ
Вы меня не поняли. В этой теме я говорю о быстродействии выполнения алгоритма.
Вы предлагаете использовать макросы...
Макрос создается из БИБЛИОТЕЧНЫХ ФБ для удобства работы при разработке алгоритма.
ИМХО макрос будет выполняться за то же время (если не большее), что и набор ФБ непосредственно на холсте.
Если бы в библиотеке существовал упомянутый мной ФБ 4ИЛИ-НЕ, то он выполнялся бы в ЧЕТЫРЕ раза быстрее, чем макрос, выполняющий ту же функцию.
Вышеприведенное утверждение будет справедливо при условии, что обработка одного ФБ производится вызовом 1 функции (как в С ).
Я не хочу работать с процессором напрямую...
Я хочу иметь возможность оценить быстродействие алгоритма. Как пример: цепочка из 10 триггеров в счетном режиме будет работать так же как инкрементный счетчик с уставкой 1024, но, наверное, в 10 раз дольше.
Вот для этого и нужен механизм меток времени при симуляции алгоритма. Я понимаю, что это достаточно сложная задача, но было бы хорошо...
Создание индивидуальных блоков встроенных в OL принесет больше вреда чем пользы, а быстродействие работы блока от этого, скорее всего. не увеличится, но потребуется дополнительная память в процессоре для описания новых блоков.
С точки зрения быстродействия пять идентичных элементов взятых из программы и онлайн базы будут работать с одинаковой скоростью.
Что касается проверки влияния, никто Вам не запрещает накопировать в логику n-ое кол-во интересующих блоков, только связать их в логику, что бы они не просто были вставлены, но и соединены в логику, и сравнить время цикла для 100 блоков и затем удалить половину и опять посмотреть время цикла. Но вообще, если вопрос в ресурсах, лучше использовать ПР200, там добавление логики не так быстро влияет на время цикла.
С уважением, Ревака Юрий.
Инженер группы технической поддержки компании "ОВЕН"
e-mail: yu.revaka@owen.ru
Шаблон описания ошибки ПР или OL http://ftp-ow.owen.ru/softupdate/OWE...s/Shablon.docx
Видео уроки по ПР200 и OWEN Logic http://edu.owen.ru/series/pr200_rev/
Другие видеоролики по тематике ПР https://www.youtube.com/channel/UCj4...H5H3d_t6iDlQOQ
Неужели у Вас при записи алгоритма в прибор копируются ВСЕ ФБ, содержащиеся в библиотеках?
А по поводу перечисленных мной "желательных" ФБ - эти функции входят во ВСЕ серии логических микросхем малой и средней степени интеграции.
Предложенный Вами подход к определению быстродействия ФБ я применяю.
Но он применим для определения времени выполнения алгоритма только в том случае когда известен порядок обработки ФБ, помещенных на холст.
Например: Вход I1->Вход I2->Вход I3->Вход I4->ФБ1(где он расположен?)->ФБ2->.......ФБN->ВыходO1->ВыходO2->ВыходO3->ВыходО4.
Кроме того я упоминал о сетевых переменных - их прием/передача также требуют времени на обработку.
По поводу ПР200 - увы... я ограничен ПР110.