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

[Сергей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, да и места экономия была-бы огромная.

[rovki]

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

.

Вы ошибаетесь ,что вырастут на 100% .Таких как вы единицы ,точнее вас двое .Остальные программисты профи делают на ПЛК с кодесис такие проекты.