а не проскакивала мысль, что компиляция творит чудеса и в прибор заливается оптимизированный код, неважно что в ИДЕ он нарисован на холсте или использован готовый блок из библиотеки?Сообщение от Vish57
В ОЛ выполняются все блоки нанесенные на холст, нет такого что из-за условия здесь выполняю, а там нет
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
В том-то и дело,что проскакивала....
Вызвало недоумение фраза:
"Создание индивидуальных блоков встроенных в OL принесет больше вреда чем пользы, а быстродействие работы блока от этого, скорее всего. не увеличится, но потребуется дополнительная память в процессоре для описания новых блоков."
На мой взгляд введение новых ФБ в библиотеку несколько (незначительно) увеличит объем ИДЕ и, соответственно, размер дистрибутива и.... все. А быстродействие и гибкость построения алгоритма увеличатся.
Смотрите: в прошивке самого ПР (неважно 110 или 200) находится виртуальная машина, в которую заложены базовые команды. ОЛ не пытается генерировать машинный код для ПР.
ОЛ компилирует схему в промежуточный код.
Например, пресловутый PID регулятор написан на Си и заложен в прошивку.
Вы предлагаете добавить хитроумный блок 4ИЛИ-НЕ? Да, его добавить можно, но в прошивке придётся и на него отвести место (чтобы ПР физически могло выполнять эту "команду").
Но: уверен, что "место в прошивке под блок 4ИЛИ-НЕ" это далеко не самый главный аргумент. Вообще говоря, Юрий верно говорит, что место в ПР (в прошивке) потребуется.
Но ещё придётся написать реализацию этого блока для существующих и готовящихся к выходу моделей ПР. А ещё протестировать и задокументировать этот блок.
Внимание, вопрос: а какая будет польза от такого блока?
То же самое можно сделать из 3-х блоков OR и одного блока NOT. Разница по времени выполнения будет наверняка несущественная. Ну, явно не в 10 раз. Может, и будет "один цельный блок" работать процентов на 5 быстрее. И? Стоит ли оно того, чтобы делать, отлаживать, и потом поддерживать?
Ну каким образом увеличится гибкость от "встроенного блока 4ИЛИ-НЕ"?
Если бы говорили о блоке "работы с массивом", то ещё, да, можно было бы понять.
Или о возможности "пропускать" ветки схемы.
Но от создания "встроенного" блока 4ИЛИ-НЕ польза (даже, если она и будет) будет мизерной. А вреда будет много.
Проделал следующий эксперимент:
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.
да в очередной раз Вы бред написали, Вы еще на АЭС порекомендуйте ПР ставить
Цикл в ПР не выполняется меньше 1мс, поэтому не важно сколько показывает среднее время
Если перешли на работу с ПР/ПЛК будте любезны использовать законы программирования таких устройств, а не МК, так что совет тоже не в тему
Хотите померяться письками, давайте, в войсках я кроме дырочек на бумажной ленте с другим не работал, но я же не агитирую использовать такую методику
ai_aykzwazpcg0exemwstjskuxu.png
Последний раз редактировалось capzap; 15.02.2018 в 18:30.
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Так ведь и я никого не агитирую! Я просто высказываю свои "хотелки" и пытаюсь обосновать их полезность, не более того...
Писками меряться у меня тоже никакого желания нет (см. предыдущее предложение).
Более того я не отказываюсь "использовать законы программирования таких устройств, а не МК"
Начиная эту тему я хотел получить от техподдержки или от уважаемых форумчан простые ответы на свои простые вопросы примерно так:
1. Время обработки входа (всех входов одновременно) составляет ~0,55 мс.
2. Время обработки одного ФБ типа ИЛИ (как вариант -любого ФБ из библиотеки) составляет ~0,1 мс.
3. Время сетевой переменной составляет ~0,хх мс.
4. Время обработки выхода (всех выходов одновременно) составляет ~0,55 мс.
Этого бы было вполне достаточно!
А теперь по поводу "злополучного" ФБ 4ИЛИ-НЕ, на который ополчился Владимир.
Поправьте меня, если я не прав: ФБ из библиотеки представляет собой подпрограмму, вызываемую из библиотеки ИДЕ OL при компиляции проекта.Почему должно совпадать?
Как-никак, а процессору как-то нужно будет выполнить эти самые 3 операции ИЛИ и одну операцию НЕ. Откуда уверенность, что время выполнения должно совпасть?
А реализовать можно так:
1. Подпрограмма пишется на С, либо другом языке, либо вообще на ассемблере и ничего не знает о наличии других ФБ в библиотеке OL.
Главное - то, что она правильно выполняет предписанный ей функционал при записи в прибор.
2. Алгоритм работы подпрограммы - выборка значения из массива таблицы истинности, зашитой в память программ процессора, в
соответствии с комбинацией входных сигналов.
Кстати для реализации функций 2ИЛИ, 2ИЛИ-НЕ,3ИЛИ,3ИЛИ-НЕ,4ИЛИ,4ИЛИ-НЕ потребуется только 1 массив на
16 элементов.
И выполняться эта подпрограмма в процессоре будет единицы, а не десятки-сотни микросекунд, и при этом время выполнения любой из
указанных функций будет одинаковым!
С уважением, Vish57
1) Math.max(1,время_цикла)
2) ~Math.max(1,время_цикла)/количество_элементов_в_проекте
3) ХЗ, зависит от скорости, помехи в кaнaле
4) Math.max(1,время_цикла)
злополучный элемент можно воспроизвести на одних константах и арифметике, не используюя ни одного элемента ИЛИ,НЕ, будет слекга громоздко, но зато принципиально не будет использоваться опыт работы с сериями логических микросхем
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Тут вы ошибаетесь. В ПР не заливается таблица истинности. В ПР заливается программа.
Например, если в ОЛ схеме написано "сложение/умножение чисел", то это вычисление проводит и ПР. "Таблица истинности" для умножителя 32 битных чисел вообще никуда не поместится. Да и согласно теореме Райса невозможно сказать соответствует ли "таблица истинности" ОЛ схеме.
Какая подпрограмма? В каком процессоре?
Вы о чём вообще?
Я задавал прямой вопрос: "Как, по-вашему, работает ОЛ схема в железе?" Вы тут пишете про таблицу истинности, про массивы. По-вашему, ПР выполняет таблицу истинности, которую генерит ОЛ?
Последний раз редактировалось Владимир Ситников; 15.02.2018 в 22:50.
Почему должно совпадать?
Как-никак, а процессору как-то нужно будет выполнить эти самые 3 операции ИЛИ и одну операцию НЕ. Откуда уверенность, что время выполнения должно совпасть?
И, да, давайте измерять не на двух-трёх элементах, а на 100-200?
Ну, чтобы уж измерять не шум, а именно работу элементов ИЛИ, НЕ и т.п.
И?
Блок 4ИЛИ-НЕ -- бесполезен. Нужен -- сделайте макрос.
Расширять ПР нужно не добавлением всех возможных блоков в среду, а правильным развитием *функциональности*
Ответьте на вопрос: каким образом ПР сможет вычислить значение этого 4ИЛИНЕ блока? Монетку что-ли кидать будет? Ну, опишите подробно каким образом оно должно получить значение.
Польза кому? И при чём тут WIN7/10?
В обновлении на Win10 есть очевидная польза компании Microsoft.
Пользователям же зачастую просто нет выбора. Хочешь безопасную ОС -- обновляйся.
В случае же с ПР и 4ИЛИНЕ, вообще никому нет пользы от добавления такого "встроенного" блока.
Это единственная правильная мысль в вашем сообщении. Я тоже не предлагаю перестраивать мышление и т.п. Кто хочет -- пусть перестраивает.
По факту же, чтобы хорошо пользоваться инструментом, нужно представлять как он устроен и какие принципы лежат внутри.
Ваш вопрос "сколько времени занимает вычисление схемы, сколько сетевой обмен" сам по себе правильный. Но когда считаете, что "можно добавить новый встроенный блок в ОЛ и для этого потребуется просто доработка ОЛ", то тут вы ошибаетесь.
Ваши права
