Оптимизация OWEN LOGIC

[sdy]

Анатолий, сказать можно что угодно, меня убедят только доказательства.

Держите, "Фома не верующий".

ТЗ и документацию выкладывать не буду, всё-таки интеллектуальная собственность, а без них понять что и как сложнее чем заново написать.

Не влезал растиражированный макрос LightCtrlV, он кстати не финальный, там еще в 2 раза больше блоков должно быть для сетевого управления, но проект пока подморожен.

Отдельно отмечу, то что вы видите, это только одно из нескольких реле. Функционал собирается как конструктор из разных кирпичиков ("макросов") и констант настройки.

Какой памяти не хватало?
ОЗУ? Переменные? Стек?

Нет, банально места по кол-ву функциональных блоков. Т.к. каждое повтороное упоминание макроса ведет к добавлению его блоков в программу повторно.

[Сергей0308]

Держите, "Фома не верующий".

ТЗ и документацию выкладывать не буду, всё-таки интеллектуальная собственность, а без них понять что и как сложнее чем заново написать.

Не влезал растиражированный макрос LightCtrlV, он кстати не финальный, там еще в 2 раза больше блоков должно быть для сетевого управления, но проект пока подморожен.

Отдельно отмечу, то что вы видите, это только одно из нескольких реле. Функционал собирается как конструктор из разных кирпичиков ("макросов") и констант настройки.



Нет, банально места по кол-ву функциональных блоков. Т.к. каждое повтороное упоминание макроса ведет к добавлению его блоков в программу повторно.

Так ясно же написано ограничение в штуках:

Ресурсы ПР114.PNG

Кто не даёт взять ПР200, там я кстати не нашёл таких ограничений(по количеству ФБ, функций) и других ресурсов гораздо больше, например энергонезависимых переменных почти на порядок больше! И как Вы пишите окончательный вариант с сетевыми переменными, тогда это и дешевле выйдет! Ещё и оптимизировать никто не запрещает, например, если время некритично, а элементы идентичны, использовать "один на весь колхоз", алгоритм выполнять не паралейно, а последовательно используя промежуточные переменные! Вот я выкладывал пример подобного решения в посте #3431, 3436: http://www.owen.ru/forum/showthread.php?t=9398&page=344
Не зная всех тонкостей программы не знаю что Вам более подойдёт, это я так вижу возможные способы выхода из вашей ситуации!

[sdy]

Так ясно же написано ограничение в штуках:

Ресурсы ПР114.PNG

Да всё понятно, но
1. на момент написания проекта 200-е были в глубокой бета и ценник еще был не известен
2. входов у 200 на 4 меньше, но это правда под ту задачу не существенно.
3. я это написал (свои 5 копеек) в части диалога о применении реализации логики микросхем в самодельных макросах, к тому, что если вставить логику посложнее да еще несколько раз - то при подходе использования макросов по ОЛ, количества доступных ФБ может не хватить.

[Сергей0308]

Да всё понятно, но
1. на момент написания проекта 200-е были в глубокой бета и ценник еще был не известен
2. входов у 200 на 4 меньше, но это правда под ту задачу не существенно.
3. я это написал (свои 5 копеек) в части диалога о применении реализации логики микросхем в самодельных макросах, к тому, что если вставить логику посложнее да еще несколько раз - то при подходе использования макросов по ОЛ, количества доступных ФБ может не хватить.

Так ПР200, если не ошибаюсь, уже больше года как вышло в продажу, Вы что проект 2 года делаете? Цена сейчас известна и если использовать ПР в сети, то ПР200 выходит при всех её преимуществах над ПР114, ещё и дешевле! Количество дискретных-аналоговых входов - аналогично ПР114, но аналоговые более функциональны, могут измерять сопротивление! Входа можно расширить с помощью модулей расширения по внутренней шине, до 2 модулей по 16 дискретных входов, пока имеются в наличии модули с 8 входами и 8 выходами! Плюс можно по интерфейсу RS485(может быть до 2 интерфейсов) подключить до 16 модулей дискретного ввода на каждый интерфейс! С ПР114 такого нельзя сделать без дополнительного мастера сети, ПР не может быть мастером сети! Вообще-то ПР позиционировалось как замена релейной логике, для сложных алгоритмов не предназначалось, я выкладывал макрос, один макрос, который около полумесяца рисовал, придумал за 5 минут, а рисовал полмесяца, в посте #300: http://www.owen.ru/forum/showthread.php?t=12691&page=30
Несколько таких макросов и годами будете проект рисовать, короче для сложных проектов есть ПЛК!
Если хотите чтобы кто-то помог упростить программу, уменьшить количество используемых ФБ, функций, выкладывайте подробное ТЗ, но мне кажется со сложным проектом вряд ли кто просто-так свяжется, лучше разбить на отдельные, функционально законченные макросы, с макросом больше шансов, что помогут и Вам не придётся раскрывать тайну всего проекта!

[sdy]

....

1. Вы невнимательны, этому проекту уже больше 2-х лет.

2. Помогать программировать мне не надо, если бы вы открыли проект, я думаю вы поняли бы это сразу. Я уже больше 20 лет программирую на порядка 10-ти разных языках в т.ч на ассемблере и считаю свою компетенцию достаточной что-бы разобраться и в ПР, и в ПЛК, и не только в ОЛ и CODESYS, но и в том как это работает на уровне железа и ПО.

3. Нет смысла дискутировать над выбором ПЛК, ПР114 и ПР200 - каждый хорош для своих нужд. Если мне не нужен дисплей и кол-во входов выходов достаточное - зачем я буду платить лишние даже 100 руб?

4. Т.к. проект выложен по просьбе одного из участников в качестве доказательства, что достичь предел по ФБ вполне реально, а не для помощи с ним разобраться, то давайте не будем дальше здесь обсуждать мой проект, если он Вам интересен можем создать отдельную ветку или обсудить в личке.

Вернемся к теме
"Оптимизация OWEN LOGIC"

Так вот, использование макросов в ОЛ путем повторной вставки ФБ макроса конечно имеет свои причины (таймеры и т.п.), с другой стороны создание своих библиотек с достаточно сложной логикой ПИД, или со сложной логикой управления, или накоплением и обработкой массивов данных во времени, приводит к довольно существенным накладным расходам на ФБ, так как например 4-ной или 5-ной селекты, или групповое сложение, или побитовая работа жрут ФБ как хомячки. Поэтому, сложная логика, по сути, побитовых процессов в реализации логики микросхем может привести к тому, что ФБ могут и закончиться.

С другой стороны, поскольку, когда то DOS занимал около 100Кб, а сейчас дистрибутив винды ели-ели влезает на DVD (т.е. в 40 млн. раз больше !!!), то, наверное, производителю проще увеличить размеры ОЗУ и ПЗУ без роста цены изделия, чем переработать ПО уйдя снова в глубокую бету.

З.Ы.
По-хорошему, как я уже писал, лично мне не хватает 2-х вещей, что-бы сказать "ПР и ОЛ - это круто", а не "уныло и муторно".

1. Работы c 1-Wire (т.к. 12 входов+10 выходов хорошо, но кто понимает, 1 шлейф 1-Wire - в 1000 раз круче).

2. Создание макросов-процедур на обычном языке программирования (хотя-бы C например).

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

Это бы уже НАМНОГО облегчило создание систем сложнее "если темно - зажечь лампочку". Можно было-бы по-человечески программировать, например, ПИД, время и погодозависимые системы управления или сетевое взаимодействие. Разработка стала бы в десятки раз легче и быстрее.

Тут уже от безысходности некоторые дошли до того, что превращают ПР в модули ввода вывода, унося всю логику на внешний контроллер - что мне кажется саму идею ПР дискредитирует. А что делать? Если для тривиальной задачи включения лампочки по расписанию надо 3 листа макросов разлиновать.

З.З.Ы. Кстати CODESYS мне тоже не понравился, от слова - совсем. Начиная от нетривиальной, устаревшей давно морально и технологически среды разработки, заканчивая убогим по современным меркам синтаксисом и возможностями.

[smk1635]

Это бы уже НАМНОГО облегчило создание систем сложнее зажечь лампочку если темно. Можно было-бы по-человечески программировать ПИД, время и погодок-зависимые например системы управления, или сетевое взаимодействие, всё стало бы в десятки раз легче и быстрее.

Дык продажи контроллеров упадут.

Тут вот от безысходности некоторые дошли до того, что превращают ПР в модули ввода вывода, унося всю логику на внешний контроллер - что мне кажется саму идею ПР дискредитирует, а что делать? Если для тривиальной задачи включения лампочки по расписанию надо 3 листа макросов разлиновать.

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

[sdy]

Дык продажи контроллеров упадут.

Уверен, продажи ПЛК практически не упадут, а ПР вырастут 100%.

Потому-что
а) и сейчас никто не покупает ПЛК Овен для управления "простой лампочкой", т.к.:
1. Не тот ценовой сегмент.
2. Необходима дополнительная обвязка по числу входов/выходов для недорогих ПЛК.
3. Требуется начальный уровень знаний в весьма непростом CODESYS.
...

б) те, кто использует ПЛК, не побегут покупать ПР т.к.:
1. Не тот уровень надежности.
2. Имеют готовые наработки ПО.
3. Имеют утвержденную рабочую документацию, которую за 1 день не поменяешь.
...

ПР и ПЛК хоть и братья, но ориентированы на разные сегменты. ПР - это скорее "любительское" железо, чем "профессиональное". Для ПР определяющим является цена/фунционал. А для ПЛК к функционалу еще добавляется надежность, стандартизация, сертификация, преемственность кода и наверно еще что-то, чего я с ходу не придумаю.

Так что, решать на ПЛК Овен банальные задачи управления воротами, шлагбаумом, дренажными насосами, отоплением в доме или светом в торговом зале, я думаю никто не будет. ПР подходят для этого вполне не плохо.

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

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

З.Ы. Ну и конечно давно пора Овену озаботиться силовыми защищенными семисторными выходами на ПР, а то приходиться к ПР еще 8 промежуточных силовых реле ставить, что-бы лампочку энергосберегающую зажигать. Я бы Овену доплатил, а не Finder'у или ABB, да и места экономия была-бы огромная.