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

[sdy]

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

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

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

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

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

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

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

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

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

[rovki]

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

.

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

[sdy]

Т.е. вы считаете, что управлять лампочками и насосами в частном доме или здании надо через ПЛК? А если оно откажет в работе? Всё, зданию конец? Или ставим на каждый насос и 5 лампочек по ПЛК? Или двойное-тройное резервирование как в ВПК? Денег не напасешься! Каскада+ПК или ПЛК хорошо в том техпроцессе, который если что-то отказало останавливается полностью. Но такое решение в доме или офисе я не поставил бы ни за что!

Прелесть ПР в модульности и самодостаточности. Сгорело 1 ПР - ну подумаешь не работает свет в 3-х комнатах, или 4 роллеты не опускаются, или 1 насос не качает, или контур теплого пола не работает, при нормальном проектировании - это не беда, можно починить не торопясь за 2-3 дня. А вот если умрет центральный ПЛК или ПК управляющий централизовано всем зданием - то это КРИЗИС, особенно если зимой.

Вот на днях сгорел у клиента в одном из 7-ми ПР встроенный БП, ну не горел свет 2 дня в коридоре и одной спальне, пережили легко - жить можно, приехали через день плату за 5 минут заменили и всё, никакого ахтунга! а умер бы ПЛК? Это надо дежурную аварийку 24х7 держать.

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

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

А сейчас, уже помучившись, скажу честно, что вряд-ли еще раз свяжусь без большой надобности с программированием через ОЛ чего-то сложнее "включения вентилятора по датчику температуры", т.к. написание кода того проекта вместо 3-х - 4-х дней заняло почти месяц, да еще и возня с постоянными багами в ОЛ откровенно достала.

Пришло понимание: к сожалению, на данном этапе использовать ПР в умном доме "свеч не стоит". Есть на рынке и поинтереснее решения. Хотя ПР Овен тоже не плох. Если когда-то появится стабильная версия ОЛ и хотя-бы мой желанный 1-wire возможно и вернусь к истокам (в конце концов макросы можно 1 раз и разлиновать), А пока заглядываю сюда периодически, "в надежде - а вдруг?"

[rovki]

Дело в том что мы по разному понимаем "простое\сложное" .Я уже скоро 8 лет дружу как раз с ПР .И какие только задачи на них не решал (в том числе примеры) и в том числе открывал глаза пользователям и разработчикам на возможности ПР.Но за 100 руб ,как пишите вы давиться не буду .Для вашей задачи используйте ПР200 и многие вопросы снимутся ,в том числе и по коммуникациям и визуализации и много входов\выходов макросов .

[sdy]

По моему мнению разработчики слегка отстают от нужного ритма. 2 года бета версии ОЛ, а я читаю на форуме про всё-те же проблемы что и 2 года назад "одно лечим, другое калечим". Может пора сделать хотя-бы один промежуточный stable релиз? Я вот далеко не уверен, что если сейчас поставлю 1.9. мои проекты написанные на 1.8 заведутся на 110-х и 114-х.

Как постоянно использующий, прокомментируйте, что сейчас со стабильностью ОЛ 1.9? Всё ли в порядке с поддержкой старых 110 и 114? Какой релиз более или менее рабочий?

[rovki]

Я высказывал свое мнение по развитию ОЛ ,в том смысле что нужно иметь несколько ОЛ .Для ПР110 Пр114 свой ОЛ (использовал 51 релиз) ,для ПР200 свой ОЛ ,что бы не было -одно лечим другое калечим.А потом будет ПР300 итд ,и что все в один ОЛ сувать .
Сейчас делаю проекты только на ПР200 .Я как и многие использую последний или предпоследний релиз ОЛ , рискую как и все, пока на грабли не натыкался в тех задачах что приходится решать. Какая стабильность ,в чем она выражается ? Стабильно появляются новые версии .Разработчики же не только баги исправляют ,но и совершенствуют функционал. ..ОЛ1.9 ПР110 114 поддерживает нормально в моих проектах .

[sdy]

... .Я уже скоро 8 лет дружу как раз с ПР .И какие только задачи на них не решал (в том числе примеры) и в том числе открывал глаза пользователям и разработчикам на возможности ПР....

Я Вас понимаю, но только давайте для честности исключим вашу Каскаду, с помощью которой вы обходите те ограничения про которые я и "тот второй" твердим второй год и посмотрим насколько усложнятся ваши решения.

У меня вот есть актуальная проблема по 4-м температурам (прямая, обратка, внешняя температура, температура теплоносителя) и время + уставки поуправлять трехходовым клапаном, насосом и выдавать аварию. Просто? Вроде да, особенно с учетом ПР 200.4 даже практически готовая обвязка наконец-то в наличии (поэтому на форум и вернулся).

Но всё равно:
1. "Нормальные" датчики температуры не повесить (3-х контактные или цифровые) только примитивы резисторные с плавающей точностью которые еще обвязать надо грамотно.
2. Я как подумаю про код - заранее волосы дыбом встают.

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

[rovki]

А причем тут Каскада ,это вы про нее начали ?И ардуину то же применяю для быстрых задач (управление драйвером сервопривода) .Датчики температуры и влажности применяю с RS485 (по цене до 1тр).
На счет 1 ware можно и сделать для ПР200 (со шлюзом на МК),был бы спрос ...
И трудности я не обхожу ,а решаю за свой счет....и не только для себя ,но и других пользователей.

[sdy]

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

Даже если вы сделаете 1-wire на МК, то придется еще заморочиться с привязкой его через модбас, вот тут и кроется опять тихий ужас - ведь надо будет еще написать протоколы взаимодействия ПР - модбас - МК- 1 wire. И ко всему этому макросы для ОЛ для удобной работы, а там временные задержки есть, цикл запрос - ответ. Прибавьте к этому процедуры 2-х шаговые, широковещательный опрос для поиска новых датчиков. Или управление параллельно несколькими устройствами на 1 wire. Тут впору или свой шлюз на МК писать, или у вас такие макросы на ОЛ будут, что отлаживать их годами придётся. В общем, мне кажется, не вариант, проще будет тот-же ардуино вставить (ПР - модбас - Ардуино - 1 wire) с кодом под конкретную задачу и дешевле, и проще и быстрее.
Реализацию драйвера 1 wire надо опускать в ОЛ на уровень C, иначе это будет мегамонстр и овчинка не будет стоить выделки - хотя реализовать можно, в свое время мои друзья писали игры на Бэйсике и не плохо получалось. А уж если вставки ассемблерные было использовать - так вообще почти как на С выходило ;-).

З.Ы. хотя... так подумать, сейчас есть готовые микро-платформы типа того-же esp8266, можно и заморочиться созданием полноценного шлюза, cо своим протоколом взаимодействия по модбас. Если что готов поучаствовать, по мере сил и возможностей.

[rovki]

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

Не приходится изобретать ,они просто приходят ко мне за модулями