Оценка быстродействия проекта для ПР110 [Архив]

Vish57

14.02.2018, 09:13

Доброго времени суток, уважаемые!

Помогите пожалуйста разобраться с быстродействием прибора.

Пояснение сути вопроса:
1. Стоит задача выполнения алгоритма подобного игре "Волк и яйца" (это чтобы не расписывать алгоритм подробно) на ПР110.
2. Входные сигналы изменяются достаточно быстро - до 80 Гц.
3. В проекте используются сетевые целочисленные переменные (протокол MODBUS 19200 8N1).
4. После заливки программы в прибор во вкладке информации о приборе выводится "Среднее время цикла 8 мс".
5. Время фильтрации входных сигналов установлено 1 мс.
6. Прибор некорректно выполняет алгоритм при частоте входных сигналов 60-70 Гц, и корректно работает на частотах 30-40 Гц.
7. При работе с частотами 40-60 Гц корректность не гарантируется.

Понятно, что проблемы возникают из-за недостаточности быстродействия.

В связи с вышеизложенным возникают следующие вопросы:
1. Каким образом можно оценить максимальное время цикла прибора ("Среднее время цикла" это как "Средняя температура по больнице") на этапе разработки и отладки проекта?
2. Где можно найти информацию по временным параметрам ФБ и ФУНКЦИЙ, входящих в библиотеки (чтобы можно было оценить быстродействие цепочек )?
3. Линия задержки обеспечивает задержку сигнала на " 1 такт", а какова величина этого такта?
4. Можно ли в процессе симуляции видеть время прохождения сигнала по цепочке ФБ в реальном приборе и общее время с момента старта симуляции?

Вообще говоря, хотелось бы найти более подробную информацию по работе ФБ, входящих в библиотеки. Как пример - сколько времени (тактов) проходит с момента подачи сигнала
на вход R счетчика до появления "0" на его выходе.

С уважением, Vish57.

capzap

14.02.2018, 09:42

maximov2009

14.02.2018, 09:44

Добрый день. Время цикла зависит от сложности программы, ориентировочно её можно посмотреть при эмуляции, попытавшись установить минимальное время цикла в настройках.
Быстродействие входов так и есть, как Вы определили.
У ПР114 и ПР200 входная частота побольше. 100 Гц свободно тянет. Может на эту платформу переориентируетесь.
С уважением.

Vish57

14.02.2018, 12:30

мне кажется ответы надо искать в параметров входов обрабатывать скоростные импульсы, а не в характеристиках программных элементов, ОЛ сам расчитывает время цикла(одного такта, ни какого отношения к процессорным тактам не имеет), у Вас оно 8мс, за это время выполнятся все элементы занесенные в проект

Для того чтобы были более понятны мои вопросы:

Представим себе гипотетический проект в котором 2 последовательности ФБ:
1-я содержит один инвертор от входа до выхода
2-я содержит 101 инвертор от входа до выхода
Обе цепочки выполняют одну и ту же функцию.

Вопросы:
1. Каково будет "Среднее время цикла" после загрузки программы в прибор?
2. Какова будет максимальная частота входных сигналов обрабатываемых корректно?

capzap

14.02.2018, 12:54

Для того чтобы были более понятны мои вопросы:

Представим себе гипотетический проект в котором 2 последовательности ФБ:
1-я содержит один инвертор от входа до выхода
2-я содержит 101 инвертор от входа до выхода
Обе цепочки выполняют одну и ту же функцию.

Вопросы:
1. Каково будет "Среднее время цикла" после загрузки программы в прибор?
2. Какова будет максимальная частота входных сигналов обрабатываемых корректно?
1. у Вас разве одно и тоже время для обоих проектов получается? А залитый проект в прибор роли не играет, вычиление ОЛ уже выдает то время которое потратит прибор
2. На старые образцы в документации этих параметров нет, это можно поспрашивать только у старожил, которые опытным путем вычисляли частоту, а у современного скоростного пр200, есть об этом пару пунктов и совсем не впечатляющие

Vish57

14.02.2018, 13:23

capzap

14.02.2018, 13:34

если тема эта http://www.owen.ru/forum/showthread.php?t=14934&p=109553&viewfull=1#post109553 то цикл программы 1мс, у Вас 8, можно грубо поделить 250 на 8 и уже не больше 50Гц будет

Ревака Юрий

14.02.2018, 13:35

У меня ПР110, и у него время переключения выходов 10 мс, а про входы ничего не написано. В ветке форума посвященной этому реле утверждалось, что прибор может работать с частотой входных сигналов до 250 Гц.
Собственно поэтому и возник вопрос о быстродействии прибора.

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

Vish57

14.02.2018, 14:09

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

Это все понятно. Я пытаюсь понять как оценить МАКСИМАЛЬНУЮ длительность цикла загруженной программы. В первом сообщении я писал, что в программе присутствуют сетевые переменные.
Естественно, обработка этих переменных требует некоторого времени на их обработку.
Отсюда вопрос - обработка сетевых переменных увеличивает время цикла программы и если да, то насколько?
Отражается ли в величине "среднее время цикла" обработка сетевых переменных?
Ну и еще вопрос - каков порядок обработки входов и ФБ в зависимости от расположения их на холсте?

Ревака Юрий

14.02.2018, 14:18

Это все понятно. Я пытаюсь понять как оценить МАКСИМАЛЬНУЮ длительность цикла загруженной программы. В первом сообщении я писал, что в программе присутствуют сетевые переменные.
Естественно, обработка этих переменных требует некоторого времени на их обработку.
Отсюда вопрос - обработка сетевых переменных увеличивает время цикла программы и если да, то насколько?
Отражается ли в величине "среднее время цикла" обработка сетевых переменных?
Ну и еще вопрос - каков порядок обработки входов и ФБ в зависимости от расположения их на холсте?

Время цикла узнаете после составления алгоритма, предварительно не представляю, как его оценить, после подключения и загрузки проекта в реле, будет видно расчетное время цикла, любые действия заложенные в алгоритм естественно влияют на время цикла, но возможно добавление одной, двух переменных сразу и не окажет заметного влияния, так как у ПР110 процессор более слабый, чем у ПР200 там это влияние будет заметнее, оценить можно на практике. По поводу расположение на холсте, у меня таких данных нет, думаю разницы нет, расчет идет от входов к выходам.

Филоненко Владислав

14.02.2018, 20:12

8 мс это и есть минимальный и максимальный цикл. цикл стабилен +-10%

Vish57

15.02.2018, 08:09

Время цикла узнаете после составления алгоритма, предварительно не представляю, как его оценить, после подключения и загрузки проекта в реле, будет видно расчетное время цикла, любые действия заложенные в алгоритм естественно влияют на время цикла, но возможно добавление одной, двух переменных сразу и не окажет заметного влияния, так как у ПР110 процессор более слабый, чем у ПР200 там это влияние будет заметнее, оценить можно на практике. По поводу расположение на холсте, у меня таких данных нет, думаю разницы нет, расчет идет от входов к выходам.

Если я буду знать время обработки каждого из ФБ, порядок обработки ФБ и длительность внутреннего такта работы программы (период выполнения основного внутреннего цикла программы) я смогу с достаточной точностью рассчитать предполагаемое время цикла работы прибора, что в свою очередь позволит провести оптимизацию алгоритма по быстродействию БЕЗ ЗАГРУЗКИ программы в прибор.
Как пример: удаление 1 RS триггера из алгоритма уменьшает "Среднее время цикла" на 0,1 мс (если я правильно помню, но порядок примерно такой).
Кстати - при загрузке пустого проекта в прибор "Среднее время цикла" составляет 0,55 мс.

Я прекрасно понимаю, что основное назначение ПР110 это управление "большими железяками", и поэтому мои вопросы кажутся запросами перфекциониста.
С другой стороны знание тонкостей работы прибора, "незначительных" с точки зрения "больших железяк", позволит обоснованно применять этот прибор в более "тонких" областях, и, естественно, облегчит разработку новых изделий (сократит период "плясок с бубном" при пусконаладке).

Vish57

15.02.2018, 08:14

8 мс это и есть минимальный и максимальный цикл. цикл стабилен +-10%

Вот эти самые +-10% и являются основным вопросом данной темы.
Если бы в документации на ФБ приводились их временные характеристики, а также время основного цикла программы прибора (не путать с циклом работы алгоритма), вопросы по быстродействию отпали бы сами собой.

capzap

15.02.2018, 08:29

Владислав, Юрий и wal79, раз уж теперь программы строятся по принципу, если элемент занимает много времени его надо выкинуть, не могли бы Вы для меня создать ОЛ с юнит-тестами, мне вот такой подход привычнее, да и Владимир Ситников наверное обрадуется :)

Vish57

15.02.2018, 09:17

Ревака Юрий

15.02.2018, 10:50

Собственно при работе над своим текущем проектом я понял чего не хватает:
1. Очень хотелось бы иметь следующие ФБ: 3И, 4И, 3ИЛИ, 4ИЛИ, 3И-НЕ, 4И-НЕ, 3ИЛИ-НЕ, 4ИЛИ-НЕ, 2И-НЕ, 2ИЛИ-НЕ (например для реализации функции 4ИЛИ-НЕ необходимо поставить ЧЕТЫРЕ!!! ФБ).
Мой опыт в программировании МК говорит мне, что сделать эти ФБ - "как 2 байта переслать".
2. Ну и уже упоминал о введение в режим симуляции меток времени, отражающих реальное (хотя бы приблизительно) время отработки ФБ.
3.Забыл упомянуть еще логический коммутатор, хотя бы на 2 входа.

По первому вопросу зайдите в онлайн базу, часть из макросов есть, остальные открываете на редактирование, добавляете сохраняете как 2ИЛИ-НЕ и используете сколько нужно, по времени займет меньше, чем Вы писали сообщение. Не вижу смысла тратить время на макросы 5И, 8И 30И и т.д
По 3 пункту, опять путь в базу, там есть много всего, даже если не подойдет на 100%, можно открыть добавить необходимое.
По 2 пункту, не совсем понятно, что Вам это даст, в OWENLogic вы не работаете с процессором напрямую, это не тот случай, когда переходя с С на ассемблер вы сможете реально влиять на быстродействие.

Vish57

15.02.2018, 11:51

По первому вопросу зайдите в онлайн базу, часть из макросов есть, остальные открываете на редактирование, добавляете сохраняете ......

Вы меня не поняли. В этой теме я говорю о быстродействии выполнения алгоритма.
Вы предлагаете использовать макросы...
Макрос создается из БИБЛИОТЕЧНЫХ ФБ для удобства работы при разработке алгоритма.
ИМХО макрос будет выполняться за то же время (если не большее), что и набор ФБ непосредственно на холсте.
Если бы в библиотеке существовал упомянутый мной ФБ 4ИЛИ-НЕ, то он выполнялся бы в ЧЕТЫРЕ раза быстрее, чем макрос, выполняющий ту же функцию.
Вышеприведенное утверждение будет справедливо при условии, что обработка одного ФБ производится вызовом 1 функции (как в С ).

Vish57

15.02.2018, 12:07

.....
По 2 пункту, не совсем понятно, что Вам это даст, в OWENLogic вы не работаете с процессором напрямую, это не тот случай, когда переходя с С на ассемблер вы сможете реально влиять на быстродействие.
Я не хочу работать с процессором напрямую...
Я хочу иметь возможность оценить быстродействие алгоритма. Как пример: цепочка из 10 триггеров в счетном режиме будет работать так же как инкрементный счетчик с уставкой 1024, но, наверное, в 10 раз дольше.
Вот для этого и нужен механизм меток времени при симуляции алгоритма. Я понимаю, что это достаточно сложная задача, но было бы хорошо...

Ревака Юрий

15.02.2018, 12:28

Вы меня не поняли. В этой теме я говорю о быстродействии выполнения алгоритма.
Вы предлагаете использовать макросы...
Макрос создается из БИБЛИОТЕЧНЫХ ФБ для удобства работы при разработке алгоритма.
ИМХО макрос будет выполняться за то же время (если не большее), что и набор ФБ непосредственно на холсте.
Если бы в библиотеке существовал упомянутый мной ФБ 4ИЛИ-НЕ, то он выполнялся бы в ЧЕТЫРЕ раза быстрее, чем макрос, выполняющий ту же функцию.
Вышеприведенное утверждение будет справедливо при условии, что обработка одного ФБ производится вызовом 1 функции (как в С ).

Создание индивидуальных блоков встроенных в OL принесет больше вреда чем пользы, а быстродействие работы блока от этого, скорее всего. не увеличится, но потребуется дополнительная память в процессоре для описания новых блоков.
С точки зрения быстродействия пять идентичных элементов взятых из программы и онлайн базы будут работать с одинаковой скоростью.
Что касается проверки влияния, никто Вам не запрещает накопировать в логику n-ое кол-во интересующих блоков, только связать их в логику, что бы они не просто были вставлены, но и соединены в логику, и сравнить время цикла для 100 блоков и затем удалить половину и опять посмотреть время цикла. Но вообще, если вопрос в ресурсах, лучше использовать ПР200, там добавление логики не так быстро влияет на время цикла.

Vish57

15.02.2018, 12:57

Создание индивидуальных блоков встроенных в OL принесет больше вреда чем пользы, а быстродействие работы блока от этого, скорее всего. не увеличится, но потребуется дополнительная память в процессоре для описания новых блоков.
С точки зрения быстродействия пять идентичных элементов взятых из программы и онлайн базы будут работать с одинаковой скоростью.
Что касается проверки влияния, никто Вам не запрещает накопировать в логику n-ое кол-во интересующих блоков, только связать их в логику, что бы они не просто были вставлены, но и соединены в логику, и сравнить время цикла для 100 блоков и затем удалить половину и опять посмотреть время цикла. Но вообще, если вопрос в ресурсах, лучше использовать ПР200, там добавление логики не так быстро влияет на время цикла.

Неужели у Вас при записи алгоритма в прибор копируются ВСЕ ФБ, содержащиеся в библиотеках?
А по поводу перечисленных мной "желательных" ФБ - эти функции входят во ВСЕ серии логических микросхем малой и средней степени интеграции.
Предложенный Вами подход к определению быстродействия ФБ я применяю.
Но он применим для определения времени выполнения алгоритма только в том случае когда известен порядок обработки ФБ, помещенных на холст.
Например: Вход I1->Вход I2->Вход I3->Вход I4->ФБ1(где он расположен?)->ФБ2->.......ФБN->ВыходO1->ВыходO2->ВыходO3->ВыходО4.
Кроме того я упоминал о сетевых переменных - их прием/передача также требуют времени на обработку.
По поводу ПР200 - увы... я ограничен ПР110.

capzap

15.02.2018, 13:08

Неужели у Вас при записи алгоритма в прибор копируются ВСЕ ФБ, содержащиеся в библиотеках?

а не проскакивала мысль, что компиляция творит чудеса и в прибор заливается оптимизированный код, неважно что в ИДЕ он нарисован на холсте или использован готовый блок из библиотеки?
В ОЛ выполняются все блоки нанесенные на холст, нет такого что из-за условия здесь выполняю, а там нет

Vish57

15.02.2018, 13:48

а не проскакивала мысль, что компиляция творит чудеса и в прибор заливается оптимизированный код, неважно что в ИДЕ он нарисован на холсте или использован готовый блок из библиотеки?
В ОЛ выполняются все блоки нанесенные на холст, нет такого что из-за условия здесь выполняю, а там нет

В том-то и дело,что проскакивала....
Вызвало недоумение фраза:
"Создание индивидуальных блоков встроенных в OL принесет больше вреда чем пользы, а быстродействие работы блока от этого, скорее всего. не увеличится, но потребуется дополнительная память в процессоре для описания новых блоков."
На мой взгляд введение новых ФБ в библиотеку несколько (незначительно) увеличит объем ИДЕ и, соответственно, размер дистрибутива и.... все. А быстродействие и гибкость построения алгоритма увеличатся.

capzap

15.02.2018, 14:24

Юрий не разработчик, мы стараемся отговорить Вас как можем. Просто Вам нужно перестраивать свое мышление из МК на плк, когда я заговорил про юнит тесты уже догадался откуда Вы пришли. Еще раз, нет особой разницы как будет тратится процессорное время если это законченный блок или в виде макроса.
Создавать законченный блок ради одного(нескольких единиц) жаждущего/х тоже не рационально
110 модель вряд ли поддерживается ОЛ в полном объеме, она слишком древняя, морально устаревшая, очень много подводных камней всплывет у Вас помимо ентой хотелки, поэтому не тратте время на пустяки.
А я "пошел запасаться попкорном", весна выдастся веселой

Владимир Ситников

15.02.2018, 15:03

На мой взгляд введение новых ФБ в библиотеку несколько (незначительно) увеличит объем ИДЕ и, соответственно, размер дистрибутива и.... все.
Смотрите: в прошивке самого ПР (неважно 110 или 200) находится виртуальная машина, в которую заложены базовые команды. ОЛ не пытается генерировать машинный код для ПР.
ОЛ компилирует схему в промежуточный код.

Например, пресловутый PID регулятор написан на Си и заложен в прошивку.

Вы предлагаете добавить хитроумный блок 4ИЛИ-НЕ? Да, его добавить можно, но в прошивке придётся и на него отвести место (чтобы ПР физически могло выполнять эту "команду").
Но: уверен, что "место в прошивке под блок 4ИЛИ-НЕ" это далеко не самый главный аргумент. Вообще говоря, Юрий верно говорит, что место в ПР (в прошивке) потребуется.
Но ещё придётся написать реализацию этого блока для существующих и готовящихся к выходу моделей ПР. А ещё протестировать и задокументировать этот блок.

Внимание, вопрос: а какая будет польза от такого блока?
То же самое можно сделать из 3-х блоков OR и одного блока NOT. Разница по времени выполнения будет наверняка несущественная. Ну, явно не в 10 раз. Может, и будет "один цельный блок" работать процентов на 5 быстрее. И? Стоит ли оно того, чтобы делать, отлаживать, и потом поддерживать?

А быстродействие и гибкость построения алгоритма увеличатся.
Ну каким образом увеличится гибкость от "встроенного блока 4ИЛИ-НЕ"?

Если бы говорили о блоке "работы с массивом", то ещё, да, можно было бы понять.
Или о возможности "пропускать" ветки схемы.

Но от создания "встроенного" блока 4ИЛИ-НЕ польза (даже, если она и будет) будет мизерной. А вреда будет много.

Ревака Юрий

15.02.2018, 16:33

Спасибо Владимир и capzap? именно это и имелось ввиду.

Vish57

15.02.2018, 17:57

Проделал следующий эксперимент:
1.Загрузил пустой проект - время цикла 0,54 мс
2.Загрузил проект 2ИЛИ - время цикла 0,64 мс
3.Загрузил проект 2ИЛИ-НЕ - время цикла 0,69 мс
4.Загрузил проект 3ИЛИ-НЕ - время цикла 0,79 мс
5.Загрузил проект 4ИЛИ-НЕ - время цикла 0,90 мс

Таким образом время выполнения функции 4ИЛИ-НЕ превышает время выполнения функции 2ИЛИ на 0,26 мс.
Если бы функция 4ИЛИ-НЕ была оформлена в виде ФБ, то их время должно было бы совпадать.

Я понимаю, что в некоторых применениях (например открытие шлюза Саяно-Шушенской ГЭС) этой разницей можно пренебречь.
А вот при использовании в аварийной защите (например скоростные сервоприводы) это уже будет играть существенную роль.

Надеюсь я достаточно обосновал свою позицию по поводу быстродействия выполнения алгоритма, записанного в прибор.

По поводу состава библиотек ФБ в OL: посмотрите палитру компонентов Borland C++, их там столько...

Я не призываю делать что-либо по моему хотению для ПР110, я думаю мои хотелки будут небесполезны и для других семейств ПРххх.

Я не понимаю почему введение в состав библиотеки нового ФБ приведет к увеличению объема прошивки, особенно если в прошивке этот блок не используется.

По поводу:

"Но ещё придётся написать реализацию этого блока для существующих и готовящихся к выходу моделей ПР. А ещё протестировать и задокументировать этот блок.
Внимание, вопрос: а какая будет польза от такого блока?" - встречный вопрос: а какая польза от перехода с WIN7 на WIN10?

По поводу введения временных меток в режиме симуляции ИДЕ: конечно же это не обязательно, можно обойтись и без них, но с ними было бы проще...

Ну и напоследок: я не считаю что "Вам нужно перестраивать свое мышление из МК на плк" большим "шагом вперед", скорее наоборот...

С уважением, Vish57.

capzap

15.02.2018, 18:09

Я понимаю, что в некоторых применениях (например открытие шлюза Саяно-Шушенской ГЭС) этой разницей можно пренебречь.
А вот при использовании в аварийной защите (например скоростные сервоприводы) это уже будет играть существенную роль.

Надеюсь я достаточно обосновал свою позицию по поводу быстродействия выполнения алгоритма, записанного в прибор.

да в очередной раз Вы бред написали, Вы еще на АЭС порекомендуйте ПР ставить
Цикл в ПР не выполняется меньше 1мс, поэтому не важно сколько показывает среднее время
Если перешли на работу с ПР/ПЛК будте любезны использовать законы программирования таких устройств, а не МК, так что совет тоже не в тему
Хотите померяться письками, давайте, в войсках я кроме дырочек на бумажной ленте с другим не работал, но я же не агитирую использовать такую методику
35618

Владимир Ситников

15.02.2018, 18:59

Таким образом время выполнения функции 4ИЛИ-НЕ превышает время выполнения функции 2ИЛИ на 0,26 мс.
Почему должно совпадать?
Как-никак, а процессору как-то нужно будет выполнить эти самые 3 операции ИЛИ и одну операцию НЕ. Откуда уверенность, что время выполнения должно совпасть?

И, да, давайте измерять не на двух-трёх элементах, а на 100-200?
Ну, чтобы уж измерять не шум, а именно работу элементов ИЛИ, НЕ и т.п.

По поводу состава библиотек ФБ в OL: посмотрите палитру компонентов Borland C++, их там столько...
И?

Я не призываю делать что-либо по моему хотению для ПР110, я думаю мои хотелки будут небесполезны и для других семейств ПРххх.
Блок 4ИЛИ-НЕ -- бесполезен. Нужен -- сделайте макрос.
Расширять ПР нужно не добавлением всех возможных блоков в среду, а правильным развитием *функциональности*

Я не понимаю почему введение в состав библиотеки нового ФБ приведет к увеличению объема прошивки, особенно если в прошивке этот блок не используется.
Ответьте на вопрос: каким образом ПР сможет вычислить значение этого 4ИЛИНЕ блока? Монетку что-ли кидать будет? Ну, опишите подробно каким образом оно должно получить значение.

"Но ещё придётся написать реализацию этого блока для существующих и готовящихся к выходу моделей ПР. А ещё протестировать и задокументировать этот блок.
Внимание, вопрос: а какая будет польза от такого блока?" - встречный вопрос: а какая польза от перехода с WIN7 на WIN10?
Польза кому? И при чём тут WIN7/10?
В обновлении на Win10 есть очевидная польза компании Microsoft.
Пользователям же зачастую просто нет выбора. Хочешь безопасную ОС -- обновляйся.

В случае же с ПР и 4ИЛИНЕ, вообще никому нет пользы от добавления такого "встроенного" блока.

Ну и напоследок: я не считаю что "Вам нужно перестраивать свое мышление из МК на плк" большим "шагом вперед", скорее наоборот...
Это единственная правильная мысль в вашем сообщении. Я тоже не предлагаю перестраивать мышление и т.п. Кто хочет -- пусть перестраивает.
По факту же, чтобы хорошо пользоваться инструментом, нужно представлять как он устроен и какие принципы лежат внутри.

Ваш вопрос "сколько времени занимает вычисление схемы, сколько сетевой обмен" сам по себе правильный. Но когда считаете, что "можно добавить новый встроенный блок в ОЛ и для этого потребуется просто доработка ОЛ", то тут вы ошибаетесь.

Vish57

15.02.2018, 21:36

да в очередной раз Вы бред написали, Вы еще на АЭС порекомендуйте ПР ставить
Цикл в ПР не выполняется меньше 1мс, поэтому не важно сколько показывает среднее время
Если перешли на работу с ПР/ПЛК будте любезны использовать законы программирования таких устройств, а не МК, так что совет тоже не в тему
Хотите померяться письками, давайте, в войсках я кроме дырочек на бумажной ленте с другим не работал, но я же не агитирую использовать такую методику
35618
Так ведь и я никого не агитирую! Я просто высказываю свои "хотелки" и пытаюсь обосновать их полезность, не более того...
Писками меряться у меня тоже никакого желания нет (см. предыдущее предложение).
Более того я не отказываюсь "использовать законы программирования таких устройств, а не МК"

Начиная эту тему я хотел получить от техподдержки или от уважаемых форумчан простые ответы на свои простые вопросы примерно так:
1. Время обработки входа (всех входов одновременно) составляет ~0,55 мс.
2. Время обработки одного ФБ типа ИЛИ (как вариант -любого ФБ из библиотеки) составляет ~0,1 мс.
3. Время сетевой переменной составляет ~0,хх мс.
4. Время обработки выхода (всех выходов одновременно) составляет ~0,55 мс.
Этого бы было вполне достаточно!

А теперь по поводу "злополучного" ФБ 4ИЛИ-НЕ, на который ополчился Владимир.

Почему должно совпадать?
Как-никак, а процессору как-то нужно будет выполнить эти самые 3 операции ИЛИ и одну операцию НЕ. Откуда уверенность, что время выполнения должно совпасть?
Поправьте меня, если я не прав: ФБ из библиотеки представляет собой подпрограмму, вызываемую из библиотеки ИДЕ OL при компиляции проекта.
А реализовать можно так:
1. Подпрограмма пишется на С, либо другом языке, либо вообще на ассемблере и ничего не знает о наличии других ФБ в библиотеке OL.
Главное - то, что она правильно выполняет предписанный ей функционал при записи в прибор.
2. Алгоритм работы подпрограммы - выборка значения из массива таблицы истинности, зашитой в память программ процессора, в
соответствии с комбинацией входных сигналов.
Кстати для реализации функций 2ИЛИ, 2ИЛИ-НЕ,3ИЛИ,3ИЛИ-НЕ,4ИЛИ,4ИЛИ-НЕ потребуется только 1 массив на
16 элементов.
И выполняться эта подпрограмма в процессоре будет единицы, а не десятки-сотни микросекунд, и при этом время выполнения любой из
указанных функций будет одинаковым!

С уважением, Vish57

capzap

15.02.2018, 21:48

Начиная эту тему я хотел получить от техподдержки или от уважаемых форумчан простые ответы на свои простые вопросы примерно так:
1. Время обработки входа (всех входов одновременно) составляет ~0,55 мс.
2. Время обработки одного ФБ типа ИЛИ (как вариант -любого ФБ из библиотеки) составляет ~0,1 мс.
3. Время сетевой переменной составляет ~0,хх мс.
4. Время обработки выхода (всех выходов одновременно) составляет ~0,55 мс.
Этого бы было вполне достаточно!

1) Math.max(1,время_цикла)
2) ~Math.max(1,время_цикла)/количество_элементов_в_проекте
3) ХЗ, зависит от скорости, помехи в кaнaле
4) Math.max(1,время_цикла)

злополучный элемент можно воспроизвести на одних константах и арифметике, не используюя ни одного элемента ИЛИ,НЕ, будет слекга громоздко, но зато принципиально не будет использоваться опыт работы с сериями логических микросхем

Владимир Ситников

15.02.2018, 22:38

2. Алгоритм работы подпрограммы - выборка значения из массива таблицы истинности, зашитой в память программ процессора, в
соответствии с комбинацией входных сигналов.
Тут вы ошибаетесь. В ПР не заливается таблица истинности. В ПР заливается программа.
Например, если в ОЛ схеме написано "сложение/умножение чисел", то это вычисление проводит и ПР. "Таблица истинности" для умножителя 32 битных чисел вообще никуда не поместится. Да и согласно теореме Райса (https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_%D0%A0% D0%B0%D0%B9%D1%81%D0%B0) невозможно сказать соответствует ли "таблица истинности" ОЛ схеме.

Кстати для реализации функций 2ИЛИ, 2ИЛИ-НЕ,3ИЛИ,3ИЛИ-НЕ,4ИЛИ,4ИЛИ-НЕ потребуется только 1 массив на
16 элементов.
И выполняться эта подпрограмма в процессоре будет единицы, а не десятки-сотни микросекунд, и при этом время выполнения любой из
указанных функций будет одинаковым!
Какая подпрограмма? В каком процессоре?
Вы о чём вообще?

Я задавал прямой вопрос: "Как, по-вашему, работает ОЛ схема в железе?" Вы тут пишете про таблицу истинности, про массивы. По-вашему, ПР выполняет таблицу истинности, которую генерит ОЛ?

capzap

16.02.2018, 06:29

Vish57

16.02.2018, 07:07

Тут вы ошибаетесь. В ПР не заливается таблица истинности. В ПР заливается программа.
Например, если в ОЛ схеме написано "сложение/умножение чисел", то это вычисление проводит и ПР. "Таблица истинности" для умножителя 32 битных чисел вообще никуда не поместится. Да и согласно теореме Райса (https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_%D0%A0% D0%B0%D0%B9%D1%81%D0%B0) невозможно сказать соответствует ли "таблица истинности" ОЛ схеме.

Какая подпрограмма? В каком процессоре?
Вы о чём вообще?

Я задавал прямой вопрос: "Как, по-вашему, работает ОЛ схема в железе?" Вы тут пишете про таблицу истинности, про массивы. По-вашему, ПР выполняет таблицу истинности, которую генерит ОЛ?

Отвечаю на прямой вопрос - в железе выполняется последовательность микрокоманд, определяемых архитектурой процессора, который даже не подозревает о существовании OL в этой Вселенной, также как и о существовании таблиц истинности, массивов, и т.д. и т.п.
Задача ИДЕ OL - сгенерировать правильную последовательность микрокоманд соответствующую схеме, нарисованной на холсте и потом "залить" ее в прибор.
Подпрограмма - часть последовательности микрокоманд обеспечивающая выполнение заданной функции. В терминологии OL это ФБ библиотеки.
Метод и способ преобразования схемы OL в последовательность микрокоманд определяется разработчиком OL. Вариантов бесконечное множество и их рассмотрение выходит далеко за рамки данной темы.

capzap

16.02.2018, 07:19

Вариантов бесконечное множество и их рассмотрение выходит далеко за рамки данной темы.
представляете, он в курсе, даже тему создавал об этом http://www.owen.ru/forum/showthread.php?t=23754

Vish57

16.02.2018, 07:21

1) Math.max(1,время_цикла)
2) ~Math.max(1,время_цикла)/количество_элементов_в_проекте
3) ХЗ, зависит от скорости, помехи в кaнaле
4) Math.max(1,время_цикла)

злополучный элемент можно воспроизвести на одних константах и арифметике, не используюя ни одного элемента ИЛИ,НЕ, будет слекга громоздко, но зато принципиально не будет использоваться опыт работы с сериями логических микросхем
Спасибо.
Хочу уточнить по п2: получается, что время выполнения ЛЮБОГО ФБ из библиотеки всегда одинаково и не зависит от сложности выполняемой функции, это действительно так?

capzap

16.02.2018, 07:39

Относительно какого устройства, в ПР110 нет вещественных чисел, вся логика сводится в конечном итоге к выполнению простейших элементов, за сколько тактов они выполняются Вы и так знаете. Меньше одной миллисекунды цикл контроллера не выполняется, поэтому закончив обработку логики программы процессор находится в фонов режиме ожидания, пока не придет очередь очередного цикла. Если элементов настолько много, что затраченное на них время больше 1мс, следующий цикл начнется по окончанию предыдущего. Когда говорят +-10% это не совсем верно, когда схема состоит из простых лог.элементов, время будет стабильно, если в схеме присутствуют таймеры, которые основаны на сравнении текущего времени и начального, тут могут быть расхождения от цикла к циклу. Не встречал понятия "прогрева" программы если это не виртуальная машина

У меня вобщем то подозрение, что Вам советовали PRU на базе ПЛК110-М02, а Вы взяли ПР110 и теперь испытываете затруднения не находя требуемого быстродействия работы устройства

Vish57

16.02.2018, 08:39

Да нет!
Все гораздо проще...
Сначала попросили сделать тупой автомат с быстродействием 1-2 сек. Ну я и взял ПР110, чтобы не заморачиваться с питанием, обвязкой, электробезопасностью, корпусом, и т.д.
Ну а после реализации возникла "гениальная" идея (не у меня) привязать работу этого автомата к энкодеру....
Вот тут-то и начались "пляски с бубном"....

Владимир Ситников

16.02.2018, 10:37

Отвечаю на прямой вопрос - в железе выполняется последовательность микрокоманд, определяемых архитектурой процессора, который даже не подозревает о существовании OL в этой Вселенной, также как и о существовании таблиц истинности, массивов, и т.д. и т.п.
Задача ИДЕ OL - сгенерировать правильную последовательность микрокоманд соответствующую схеме, нарисованной на холсте и потом "залить" ее в прибор.
В том-то и дело, что те команды, которые генерирует ОЛ для процессора *абсолютно* непонятны.

И правила работы базовых блоков заложены именно в сам прибор. Из ОЛ поступает программа в виде "какие блоки нужно выполнить и в каком порядке".
Поэтому, добавление нового блока это не просто "научить ОЛ формировать новую последовательность машинных команд", а это и доработка микропрограммы ПР (прошивки ПР) так, чтобы эта прошивка научилась выполнять новый блок. И эту доработку нужно выполнять для всего ряда ПР (не забываем, что они основаны на совершенно разных процессорах).

Подпрограмма - часть последовательности микрокоманд обеспечивающая выполнение заданной функции. В терминологии OL это ФБ библиотеки.
Учитывайте, что "последовательность команд процессора, реализующая выполнение того или иного ФБ" хранится именно в ПР. И она там хранится до того, как в ПР что-то залили. На эту программу можно взглянуть по ссылке "прошивка" со страницы ПР (http://www.owen.ru/catalog/programmiruemoe_rele_owen_pr110/opisanie)
В заливаемой же из ОЛ программе нет команд, понятных железу.

Метод и способ преобразования схемы OL в последовательность микрокоманд определяется разработчиком OL. Вариантов бесконечное множество и их рассмотрение выходит далеко за рамки данной темы.
Вариантов не так-то и много. И это важно.
Например, есть ПР110, ПР114, ПР200. Все они программируются из одной среды. Делать "индивидуальный подход" к каждому реле экономически нецелесообразно, поэтому из "бесконечного множества" стоит рассматривать те, которые позволят унифицировать работу с разнотипным железом.

Владимир Ситников

16.02.2018, 10:49

2) ~Math.max(1,время_цикла)/количество_элементов_в_проекте

Спасибо.
Хочу уточнить по п2: получается, что время выполнения ЛЮБОГО ФБ из библиотеки всегда одинаково и не зависит от сложности выполняемой функции, это действительно так?

Почему же?
capzap, скорее всего, имел ввиду, что "если элементов на схеме мало, то ПР будет выдерживать паузу, чтобы цикл длился 1 мс минимум".
Откуда он это взял -- загадка, но оно неважно.

Длительность выполнения элемента OR (который подключен к входам-выходам, а не висит мёртвым грузом) не зависит от того, сколько этих элементов в схеме.
Поэтому, чтобы узнать длительность работы этого самого OR, нужно взять схему с большим количеством элементов, узнать какая длительность цикла получится и поделить на количество элементов.

Аналогично и для других элементов. Измерьте, посмотрим что будет. Заодно можно будет сравнить с производительностью самого железа. Вроде как обещают, что в ПР110 находится PIC18 18Mhz.

Умножение деление (вроде, доступен же в ПР110 блок умножения целых?), очевидно, должны занимать гораздо больше времени, т.к. процессор там PIC18 (8-и битный), и команд для умножения/деления 32 битных чисел у него нет. Значит, там длинные портянки (http://www.elepal.fi/antennit/pic/muldiv18.html) для этого самого умножения, значит оно работать должно дольше.

Не хотелось бы верить, что интерпретатор ПР110 настолько медленный, что накладные расходы на выполнение блока OR превышают длительность умножения 32bit чисел.

Vish57

16.02.2018, 11:24

Чтож, Владимир, спасибо за разъяснения по организации выполнения программ в ПР110.
На мой взгляд подобный подход имеет место быть, хотя я бы назвал его мягко говоря не очень разумным.
Ну да Бог с ним, спишем это на "тяжелое наследие прошлого"....
А исследовать свойства чужого "железа" у меня нет никакого желания. Потратится куча времени с "нулевым" выхлопом.
Придется по-дедовски отрабатывать на стенде-макете и испытывать.

capzap

16.02.2018, 11:30

Откуда он это взял -- загадка, но оно неважно.
правильнее конечно обратится к ТУ наверное, но я могу на это сослаться

Владимир Ситников

16.02.2018, 11:39

правильнее конечно обратится к ТУ наверное, но я могу на это сослаться

Ясно. Я бегло пробежался по характеристикам -- не нашёл. В РЭ тоже нет.
Ещё раз глянул -- в функциональной схеме (http://www.owen.ru/catalog/programmiruemoe_rele_owen_pr110/68536284) есть указание про "минимальный цикл в 1 мс".

Но всё равно формула Math.max(1,время_цикла)/количество_элементов_в_проекте для "Время обработки одного ФБ типа ИЛИ" это неправильная оценка. Там Math.max лишнее, и рассматривать нужно программы с большим количеством элементов.

Грубо говоря, если в программе всего 1 блок, то время цикла, конечно, будет равно 1мс (должно быть), но сама длительность выполнения операции ИЛИ будет гораздо меньше этой 1 мс.

---

У Vish57 получается цикл меньше 1 мс? Выходит, это ошибка в работе ПР?

Vish57

17.02.2018, 09:46

...
У Vish57 получается цикл меньше 1 мс? Выходит, это ошибка в работе ПР?

Или ошибка в работе ИДЕ OL....
Чему верить-то...?

Время цикла 1 мс при тактовой 18 МГц... м-да.... это-ж какие накладные расходы в программе прибора.... умереть-не встать...

Филоненко Владислав

17.02.2018, 10:07

Вот эти самые +-10% и являются основным вопросом данной темы.
Если бы в документации на ФБ приводились их временные характеристики, а также время основного цикла программы прибора (не путать с циклом работы алгоритма), вопросы по быстродействию отпали бы сами собой.

Основной цикл и есть цикл работы алгоритма. Он максимально стабилен, ПР так сделан специально. И 10% никого смущать не должны, т.к. если Вы делаете алгоритм на 91% ресурсов прибора - Вы уже совершили ошибку. Запас в минимум 30% по времени цикла всегда должен быть. (а лучшие собаководы рекомендуют 2-3 кратный запас)
Он потребуется для "допиливания" кода.
Он покрывает не "квадратность" меандра на входе и всякие другие внезапности.