а так:Цитата:
Сообщение от Сема
Вложение 32518
Вид для печати
а так:Цитата:
Сообщение от Сема
Вложение 32518
Глупости. Входы-выходы макроса прекрасно настраиваются под любой имеющийся тип.Цитата:
Сообщение от Сема
Не при создании макроса, а в свойствах входа/выхода.
Научитесь пользоваться макросами, и не придётся рисовать "метр на метр" схемы, в которых чёрт ногу сломит,и оттестировать которые голова квадратной станет.
Ещё умейте пользоваться переменными, как "именованными цепями". И схемы станут простыми и легко читаемыми и отлаживаемыми.
Это называется "структурное программирование". В рисовании схем для ПР это тоже актуально.
А вы не пробовали в свойствах входов и выходов макроса изменить их, сделать целочисленными или флоат?Цитата:
Сообщение от Сема
Там ещё и процессор слабее чем в ПР200Цитата:
Сообщение от Сема
Поскольку вопрос с написанием макросов на языке высокого уровня подвис, а так же с заявлениями разработчиков ОЛ - "присылайте нам заявки, мы сделаем блок в библиотеку", я предлагаю разработчикам разработать и включить в библиотеку ФБ, по выполняемым функциям соответствующие логическим микросхемам стандартной серии 74 (у нас 155), например. В отличие от языков высокого уровня, я не предвижу возражений от любителей рисовать "квадратики", ибо это и будут квадратики. Кроме этого значительная часть имеющихся схем будет достаточно просто переводиться на новую элементную базу в виде ПР. Возможное неудобство будет никак не больше, чем например отсутствие отрицательных целых чисел в ОЛ (что является несомненным достижением, т.к. в микроконтроллере ядра ПР200 они есть). Вообще системы управления возможно проектировать исходя из аппаратного подхода или программного. При этом сторонники ПР придерживаются первого, а ПЛК - второго. Однако в настоящее время ОЛ не реализует толком ни один - для первого слишком малая библиотека, а для второго - слишком узкие возможности программирования. Своим предложением я предлагаю устранить первое ограничение, если уж второе признано идеологически неверным.
Справочник "Популярные цифровые микросхемы" автор В. Шило - читаем, если забыли и рисуем что душе угодно
Так мы и так уже читаем и рисуем. Есть только ощущение, что это какой-то бред - сперва квадратики, потом это странслируется в промежуточный язык, а потом интерпретатор будет выполнять эти команды на контроллере... Я предположил что если создатели ОЛ оформят это в виде библиотеки - оно покомпактнее выйдет и побыстрее, возможно.Цитата:
Сообщение от ssm
Не выйдет побыстрее. Всёравно через "промежуточный код" и "интерпретатор".Цитата:
Сообщение от starmos
Другой вопрос - а нафига оно полный набор нужен, если любой элемент за несколько минут собирается из того, что уже есть. А какие именно понадобятся, а какие никогда - заранее неизвестно.
Вставлю свои 5 копеек.
На самом деле проблема не столько в том, что нет нужных наборов макросов, сколько в том что собственные макросы попадают в финальный код именно как макросы, а не как вызовы процедур.
Поэтому при реализации достаточно сложных, однотипных механизмов на разных вводах/выходах сам лично столкнулся с банальной нехваткой памяти под микропрограмму уже на 3-м порту из 8-ми. Пришлось всё заново переписывать придумывать очередь для обработки запросов и обрабатывать каждый вход на одном макросе в режиме карусели.
В общем код получился пипец какой сложный, без бутылки спустя месяц не разобраться. как итог иногда происходят теперь какие-то "странные глюки" (по большому счету не критичные в техпроцессе), которые не понятно к чему отнести, то-ли к звону контактов, то-ли к ошибкам в вечно бета ОЛ, то-ли моей ошибке в схеме из-за многопоточности где-то в этой гигантской каруселе линий и квадратиков.
Но разбираться желания особого нет, работает 99,9% времени и хорошо, нажать лишний раз кнопку оператору - не проблема.
Какой памяти не хватало?Цитата:
Сообщение от sdy
ОЗУ? Переменные? Стек?
Это голословное утверждение. Где доказательства? Подробное ТЗ и программу "в студию".Цитата:
Сообщение от sdy
Или хотя бы скрины или сколько переменных ,ФБ ,элементов итд , что бы понять что значит "достаточно сложных"
Анатолий, сказать можно что угодно, меня убедят только доказательства.Цитата:
Сообщение от rovki
Всякие бывают ситуации .Проект хорошо увидеть ,если позволят обстоятельства :rolleyes::cool:Цитата:
Сообщение от Василий Кашуба
Держите, "Фома не верующий".Цитата:
Сообщение от Василий Кашуба
ТЗ и документацию выкладывать не буду, всё-таки интеллектуальная собственность, а без них понять что и как сложнее чем заново написать.
Не влезал растиражированный макрос LightCtrlV, он кстати не финальный, там еще в 2 раза больше блоков должно быть для сетевого управления, но проект пока подморожен.
Отдельно отмечу, то что вы видите, это только одно из нескольких реле. Функционал собирается как конструктор из разных кирпичиков ("макросов") и констант настройки.
Нет, банально места по кол-ву функциональных блоков. Т.к. каждое повтороное упоминание макроса ведет к добавлению его блоков в программу повторно.Цитата:
Сообщение от Владимир Ситников
Так ясно же написано ограничение в штуках:Цитата:
Сообщение от sdy
Вложение 33165
Кто не даёт взять ПР200, там я кстати не нашёл таких ограничений(по количеству ФБ, функций) и других ресурсов гораздо больше, например энергонезависимых переменных почти на порядок больше! И как Вы пишите окончательный вариант с сетевыми переменными, тогда это и дешевле выйдет! Ещё и оптимизировать никто не запрещает, например, если время некритично, а элементы идентичны, использовать "один на весь колхоз", алгоритм выполнять не паралейно, а последовательно используя промежуточные переменные! Вот я выкладывал пример подобного решения в посте #3431, 3436: http://www.owen.ru/forum/showthread.php?t=9398&page=344
Не зная всех тонкостей программы не знаю что Вам более подойдёт, это я так вижу возможные способы выхода из вашей ситуации!
Да всё понятно, ноЦитата:
Сообщение от Сергей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-х лет.Цитата:
Сообщение от Сергей0308
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 мне тоже не понравился, от слова - совсем. Начиная от нетривиальной, устаревшей давно морально и технологически среды разработки, заканчивая убогим по современным меркам синтаксисом и возможностями.
Дык продажи контроллеров упадут. :)Цитата:
Сообщение от sdy
Ну не просто как чистый модуль, а как модуль с собственной программой безопасности, не зависимой от основной программы ПЛК.Цитата:
Сообщение от sdy
Уверен, продажи ПЛК практически не упадут, а ПР вырастут 100%.Цитата:
Сообщение от smk1635
Потому-что
а) и сейчас никто не покупает ПЛК Овен для управления "простой лампочкой", т.к.:
1. Не тот ценовой сегмент.
2. Необходима дополнительная обвязка по числу входов/выходов для недорогих ПЛК.
3. Требуется начальный уровень знаний в весьма непростом CODESYS.
...
б) те, кто использует ПЛК, не побегут покупать ПР т.к.:
1. Не тот уровень надежности.
2. Имеют готовые наработки ПО.
3. Имеют утвержденную рабочую документацию, которую за 1 день не поменяешь.
...
ПР и ПЛК хоть и братья, но ориентированы на разные сегменты. ПР - это скорее "любительское" железо, чем "профессиональное". Для ПР определяющим является цена/фунционал. А для ПЛК к функционалу еще добавляется надежность, стандартизация, сертификация, преемственность кода и наверно еще что-то, чего я с ходу не придумаю.
Так что, решать на ПЛК Овен банальные задачи управления воротами, шлагбаумом, дренажными насосами, отоплением в доме или светом в торговом зале, я думаю никто не будет. ПР подходят для этого вполне не плохо.
Проблема в том, что современный рынок требует "управления с телефона" и "экологичность и энергосбережение", и если использовать ПР Овен для этих задач, то по идеи простой функционал, надо обернуть в сетевое взаимодействие или сделать привязки к дате, времени, погоде, температуре или сопрячь с другими дешевыми железками - и тут уже всё - сушите вёсла - или ограничение по входным портам или 100 листов макросов.
Поэтому ПР Овен в сегмент "умный дом" очень тяжело затягивается - а жаль, железки не плохие.
З.Ы. Ну и конечно давно пора Овену озаботиться силовыми защищенными семисторными выходами на ПР, а то приходиться к ПР еще 8 промежуточных силовых реле ставить, что-бы лампочку энергосберегающую зажигать. Я бы Овену доплатил, а не Finder'у или ABB, да и места экономия была-бы огромная.
Вы ошибаетесь ,что вырастут на 100% .Таких как вы единицы ,точнее вас двое ;).Остальные программисты профи делают на ПЛК с кодесис такие проекты.Цитата:
Сообщение от sdy
Т.е. вы считаете, что управлять лампочками и насосами в частном доме или здании надо через ПЛК? А если оно откажет в работе? Всё, зданию конец? Или ставим на каждый насос и 5 лампочек по ПЛК? Или двойное-тройное резервирование как в ВПК? Денег не напасешься! Каскада+ПК или ПЛК хорошо в том техпроцессе, который если что-то отказало останавливается полностью. Но такое решение в доме или офисе я не поставил бы ни за что!
Прелесть ПР в модульности и самодостаточности. Сгорело 1 ПР - ну подумаешь не работает свет в 3-х комнатах, или 4 роллеты не опускаются, или 1 насос не качает, или контур теплого пола не работает, при нормальном проектировании - это не беда, можно починить не торопясь за 2-3 дня. А вот если умрет центральный ПЛК или ПК управляющий централизовано всем зданием - то это КРИЗИС, особенно если зимой.
Вот на днях сгорел у клиента в одном из 7-ми ПР встроенный БП, ну не горел свет 2 дня в коридоре и одной спальне, пережили легко - жить можно, приехали через день плату за 5 минут заменили и всё, никакого ахтунга! а умер бы ПЛК? Это надо дежурную аварийку 24х7 держать.
А таких как я мало потому, что - на данном этапе, как я уже писал, ПР Овен под эти задачи подходит с большой большой натяжкой. Очень дорого и долго обходится обвязка посложнее и программирование.
З.Ы.
Если бы в свое время я не познакомился с оборудованием Овен в одной из котельных, где о нем отзывались весьма положительно, и не рост курса, то вряд-ли бы я стал использовать ПР Овен изначально.
А сейчас, уже помучившись, скажу честно, что вряд-ли еще раз свяжусь без большой надобности с программированием через ОЛ чего-то сложнее "включения вентилятора по датчику температуры", т.к. написание кода того проекта вместо 3-х - 4-х дней заняло почти месяц, да еще и возня с постоянными багами в ОЛ откровенно достала.
Пришло понимание: к сожалению, на данном этапе использовать ПР в умном доме "свеч не стоит". Есть на рынке и поинтереснее решения. Хотя ПР Овен тоже не плох. Если когда-то появится стабильная версия ОЛ и хотя-бы мой желанный 1-wire возможно и вернусь к истокам (в конце концов макросы можно 1 раз и разлиновать), А пока заглядываю сюда периодически, "в надежде - а вдруг?"
Дело в том что мы по разному понимаем "простое\сложное" .Я уже скоро 8 лет дружу как раз с ПР .И какие только задачи на них не решал (в том числе примеры) и в том числе открывал глаза пользователям и разработчикам на возможности ПР.Но за 100 руб ,как пишите вы давиться не буду .Для вашей задачи используйте ПР200 и многие вопросы снимутся ,в том числе и по коммуникациям и визуализации и много входов\выходов макросов .
По моему мнению разработчики слегка отстают от нужного ритма. 2 года бета версии ОЛ, а я читаю на форуме про всё-те же проблемы что и 2 года назад "одно лечим, другое калечим". Может пора сделать хотя-бы один промежуточный stable релиз? Я вот далеко не уверен, что если сейчас поставлю 1.9. мои проекты написанные на 1.8 заведутся на 110-х и 114-х.
Как постоянно использующий, прокомментируйте, что сейчас со стабильностью ОЛ 1.9? Всё ли в порядке с поддержкой старых 110 и 114? Какой релиз более или менее рабочий?
Я высказывал свое мнение по развитию ОЛ ,в том смысле что нужно иметь несколько ОЛ .Для ПР110 Пр114 свой ОЛ (использовал 51 релиз) ,для ПР200 свой ОЛ ,что бы не было -одно лечим другое калечим.А потом будет ПР300 итд ,и что все в один ОЛ сувать .
Сейчас делаю проекты только на ПР200 .Я как и многие использую последний или предпоследний релиз ОЛ , рискую как и все, пока на грабли не натыкался в тех задачах что приходится решать. Какая стабильность ,в чем она выражается ? Стабильно появляются новые версии:D .Разработчики же не только баги исправляют ,но и совершенствуют функционал. ..ОЛ1.9 ПР110 114 поддерживает нормально в моих проектах .
Я Вас понимаю, но только давайте для честности исключим вашу Каскаду, с помощью которой вы обходите те ограничения про которые я и "тот второй" твердим второй год и посмотрим насколько усложнятся ваши решения.Цитата:
Сообщение от rovki
У меня вот есть актуальная проблема по 4-м температурам (прямая, обратка, внешняя температура, температура теплоносителя) и время + уставки поуправлять трехходовым клапаном, насосом и выдавать аварию. Просто? Вроде да, особенно с учетом ПР 200.4 даже практически готовая обвязка наконец-то в наличии (поэтому на форум и вернулся).
Но всё равно:
1. "Нормальные" датчики температуры не повесить (3-х контактные или цифровые) только примитивы резисторные с плавающей точностью которые еще обвязать надо грамотно.
2. Я как подумаю про код - заранее волосы дыбом встают.
На том-же "ардуино" возни на порядок с такой задачей меньше (и не надо говорить, что это не промышленное решение - я согласен, в данном случае речь идет о подключении обвязки и программировании, а не пром-дизайне).
А причем тут Каскада ,это вы про нее начали ?И ардуину то же применяю для быстрых задач (управление драйвером сервопривода) .Датчики температуры и влажности применяю с RS485 (по цене до 1тр).
На счет 1 ware можно и сделать для ПР200 (со шлюзом на МК),был бы спрос ...
И трудности я не обхожу ,а решаю за свой счет....и не только для себя ,но и других пользователей.
Я абсолютно не против Каскады, я о том, что родилась она в том числе как способ облегчить себе жизнь в управлении сложными процессами. Просто у вас уже есть эти наработки, поэтому Вам с ПР комфортно. А тем у кого таких наработок нет - приходится "изобретать велосипеды".
Даже если вы сделаете 1-wire на МК, то придется еще заморочиться с привязкой его через модбас, вот тут и кроется опять тихий ужас - ведь надо будет еще написать протоколы взаимодействия ПР - модбас - МК- 1 wire. И ко всему этому макросы для ОЛ для удобной работы, а там временные задержки есть, цикл запрос - ответ. Прибавьте к этому процедуры 2-х шаговые, широковещательный опрос для поиска новых датчиков. Или управление параллельно несколькими устройствами на 1 wire. Тут впору или свой шлюз на МК писать, или у вас такие макросы на ОЛ будут, что отлаживать их годами придётся. В общем, мне кажется, не вариант, проще будет тот-же ардуино вставить (ПР - модбас - Ардуино - 1 wire) с кодом под конкретную задачу и дешевле, и проще и быстрее.
Реализацию драйвера 1 wire надо опускать в ОЛ на уровень C, иначе это будет мегамонстр и овчинка не будет стоить выделки - хотя реализовать можно, в свое время мои друзья писали игры на Бэйсике и не плохо получалось. А уж если вставки ассемблерные было использовать - так вообще почти как на С выходило ;-).
З.Ы. хотя... так подумать, сейчас есть готовые микро-платформы типа того-же esp8266, можно и заморочиться созданием полноценного шлюза, cо своим протоколом взаимодействия по модбас. Если что готов поучаствовать, по мере сил и возможностей.
Не приходится изобретать ,они просто приходят ко мне за модулями ;)Цитата:
Сообщение от sdy
Тут уже было обсуждение про программирование на С. Набежали поклонники "квадратиков" с криками "ужас-ужас" и "нам это ваше С непонятно". А под конец все похоронило ответственное мнение разработчиков встроенного софта для ПР, о том что ввести программирование на С невозможно. Поскольку попутно выяснилось, что ПР и видимо ПЛК ОВЕН используют некоторую систему команд, как промежуточный код, который и выполняется прошитым в них интерпретатором, то ввести программирование на С конечно невозможно и лучше не стоит, чтобы не получить проблемы от использования кривого компилятора "С->промежуточный код", а в сразу нормальный я не верю. На самом деле этот подход с системой команд очень удобен для программистов ОВЕН, но представляет собой анахронизм уже, только кого это волнует пока деньги платят? Мир быстро меняется, уже и ПР200 начинает устаревать. Скоро любое устройство, не имеющее на борту выхода в Инет будет считаться барахлом. Но поди, объясни. ESP8266 - это половинчатое решение, уже распространяется ESP32, где сняты многие ограничения по интерфейсам и числу выводов. Можно было бы сделать неплохой контроллер на этом ядре, сразу с выходом WiFi, можно даже без экрана и кнопок вообще. Но это фантастика же. "Не соответствует промышленным стандартам..." или еще какую отмазку придумают. Ну так сделайте чтобы соответствовало? "Надо 100500 миллионов, кто заплатит?", ну и т.д., этим разработчикам я бы и 10 рублей не заплатил. Даже просто выпустить клон ПР200, совместимый с Arduino, казалось бы - кому надо купят? - перепаивать-то не надо ничего, ядро вроде поддерживается ардуиновским IDE, бери да продавай.Цитата:
Сообщение от sdy