Проект управления светом квартиры на Siemens Logo с использованием UDF-блоков
Гыгы! Не прошло и ГОДА! =)) Я нашёл коммент от 9 ноября в третьей части постов про Logo, где говорил что скоро напишу четвёртую часть про UDF-блоки ))) Нет, ну а хрен ли? Я ж говорил, что я как начал в Одинцово ремонтить — так зачерствел, на всё позабил, и вообще замкнулся от людей. Вот ща только начинаю заново раскручивать маховик общения! Поэтому мы продолжаем, и сегодня у меня рассказ про UDF-блоки и сетевой проект в Logo.
Для тех, кто всё позабыл (или только наткнулся на этот пост), напомню ссылки на посты про Logo и ПЛК (потом вставлю их во все посты про Logo, чтобы связанность была):
- Логические реле и ПЛК : Зачем это нужно и как работает?
- Логические реле SIEMENS Logo!, часть 1: Устройство и подключение
- Логические реле SIEMENS Logo!, часть 2: Программирование в Logo Soft Comfort — импульсные реле
- Логические реле SIEMENS Logo!, часть 3: Программирование в Logo Soft Comfort — таймеры и сообщения
Гм. Когда-нибудь (может ещё через год) захерачу пост про WEB-визуализацию, когда в Одинцово весь свет и проводку на Logo переберу и мне надо будет туда WEB-интерфейс замутить =)
Для удобства навигации по постам я завёл тэги по типу контроллера. Раз уж я херачу щиты на ОВЕНе и Logo — то пускай и тэги такие будут, чтобы можно было найти все посты, где есть и техническая инфа и щиты, собранные на этом железе.
В третьей части поста были комментарии, в которых мы уже немного обсуждали UDF. Все эти комментарии я перетащил в этот пост, чтобы они были по теме поста. Так что не удивляйтесь комментам годичной давности — это не глюк! =)
Содержание
1. UDF-блоки в Logo. Зачем они нужны?
Начинаем, как всегда, на примере, чтобы было понятнее. Вот зацените эту схему:
Схема на Siemens Logo, участки которой повторяются (кандидат в UDF)
Это то решение, про которое я рассказывал в третьей части постов — про управление вентилятором санузла: короткое нажатие на кнопку запускает вентилятор, длинное — немедленно выключает его; или же, если на кнопку больше не нажимать, вентилятор выключается сам через некоторое время.
Что тут не так? Не, схема правильная — всё нормально! Не так тут то, что она повторяется несколько раз. И если бы вы знали не только про FBD, а про программирование в виде кода, то вы бы сразу заорали: «Надо написать функцию!». Ну, да! UDF — это аналог функции или подпрограммы. Мы запихиваем действие, которое одинаково для разных аргументов или параметров в функцию, один раз отлаживаем, забываем нахер про то, что там написали — и пользуемся готовым результатом!
Вот в Logo можно использовать тот же принцип. Только называется это не функцией, как у всех нормальных (и тех ненормальных, которые в курсе того, что процедура — это функция, которая не возвращает значение) людей, а UDF — User Defined Function или что-то подобное. Я в посте буду звать их UDF-блоками.
Внутрь UDF можно запихать схему, которая будет делать нужное нам сложное (или типовое) действие, а вместо месива элементов (которое задолбаешься копировать несколько раз и заново создавать соединения) — будет один элемент схемы с нужными сигналами входов и выходов. При этом внутри UDF может быть даже сложная схемка — с какими-нибудь таймерами, выдержками и кучей всего другого!
Лично я больше всего затрахался с копированием одинаковых кусков схем. Вот как раз я и взял пример вентилятора, потому что сама схема там простая, но когда ты её копируешь — то Logo Soft Comfort иногда накидывает элементы как попало, и их надо снова красивенько расставлять. А самая ужасная дрянь начинается тогда, когда в этом скопированном куске схемы есть какой-то блок, который надо удалить и поставить новый, а не просто изменить номер входа/выхода. Когда ты удаляешь старое — разваливаются все соединения которые шли к этому блоку, и потом это надо заново отрисовывать.
Меня тут хейтеры упрекали в том, что я делаю одну и ту же стандартную херню в щитах без фантазии =) Во-первых, эти хейтеры забыли сказать о том, что сами-то они по этим щитам учатся и вдохновляются новыми фишками. А во-вторых, посмотрим что они скажут про UDF… =) С ними вся схема для щита с Logo вообще будет выглядеть как несколько стандартных квадратиков =)) А как иначе? Нарабатывается опыт, потом этот опыт сводится в единую техкарту (или стандарт) и все щиты делаются удобно, технично и повторяемо. А через несколько лет снова набирается опыт, все стандарты и техкарты апгрейдятся — и вперёд! =)
Ща мы создадим простой UDF, чтобы я мог показать то, куда надо для этого тыкать в Logo Soft Comfort, а потом займёмся UDF для вентилятора санузлов (по схеме, которую я показал в начале поста).
Тыркаем в меню «File -> New -> UDF diagram (UDF)»:
Создание нового UDF-блока в редакторе Logo
В редакторе открывается новый файл (окно) как для обычной схемы на Logo, только с рамкой вокруг будущего UDF-блока. Рамку можно потаскать за края, чтобы подогнать её размеры под будущую начинку блока. Можно намутить разбивку на страницы, как на обычном проекте, если UDF получается жирный.
Поле для схемы UDF-блока и изменение его размеров
Накидаем схемку для того, чтобы определять длинное нажатие. Идея простая — прокидываем сигнал входа через маркер на выход (для того, чтобы у блока можно было подавать выход на вход через какие-нибудь логические элементы), и для длинного нажатия ставим таймер на включение.
Блок UDF с заданными названиями входов и выходов
Протестим нашу схемку! Эмулятор тут работает точно так же, как и в обычном Logo. Точно так же можно настроить тип входов (кнопка, переключатель), всё протестить и проверить.
Тестируем блок UDF в симуляторе. Работает так же как обычно внутри Logo
У нас получается, что вход передаётся на выход как есть (это одинарное нажатие). Если надо было бы — можно было воткнуть внутрь UDFа какой-нибудь формирователь импульса (Wiping Relay), который выдавал бы на выходе именно импульс одиночного нажатия.
Этот же вход передаём на вход блока задержки включения, которое настроено у нас на две секунды. Если сигнал на входе будет длиться меньше — то блок не сработает. А если больше — то выдаст сигнал на выход, который мы передаём на выход UDF как длинное нажатие.
2. Создаём UDF-блок для вентилятора санузлов
А теперь займёмся нашим блоком. Создадим новый UDF и первым делом займёмся вот чем. Так как мы делаем красивый UDF — то нам надо, чтобы у него было понятное название. Оно в будущем будет использоваться как тип блока в проектах Logo.
Лезем в меню «Edit -> Edit UDF Properties…»:
Команда меню для открытия окна свойств UDF-блока
Открывается большое и дибильное окно:
Задаём название UDF-блока (для внешних программ)
Дибильное, потому что меня БЕСЯТ ублюдочные окна и интерфейсы Logo Soft Comfort! Вот нахер там справа пустое место?! Почему нельзя либо сократить ширину окна, либо растянуть таблицы на всю ширину окна-то?
Вписываем в этом окне название блока и пока закрываем его (но мы ещё вернёмся к нему). А дальше рисуем нашу схему (как из прошлого поста) прямо внутри блока UDF.
Рисуем блок для управления вентилятором санузла (по схеме из предыдущих постов)
Обратите внимание на то, что я задал всем блокам схемы понятные имена. Это красиво, но не всегда хорошо: позжее они сыграют с нами злую шутку!
Внутри UDF можно использовать практически все те же элементы схемы, которые вы используете в обычном Logo. В том числе и маркеры (флаги) M. Они нумеруются внутри UDF с единицы, но они НИКАК не будут связаны с обычными маркерами M в программе Logo. Пугаться не надо: внутри UDF маркеры живут сами по себе и никуда наружу не вылазят (но занимают ресурсы Logo так же как и имена блоков).
ОКей! Схему мы накидали. Ну а как сделать внешние сигналы входов и выходов? Тут всё просто: берёте линию и тянете её к левому или правому краю рамки UDF-блока:
Создание входов и выходов блока UDF (тянем соединение до края рамки)
Всё, что притянете к левому краю — будет входом, к правому — выходом. Всё просто! И точно так же, как в обычном Logo, на один вход можно подцепить внутри несколько блоков (подать его в разные части схемы).
Вот наша схемка уже со входами и выходами:
Схема блока для управления вентилятором составлена
Возвращаемся к тому же окну свойств UDF-блоков и зададим там названия всех наших входных и выходных сигналов — они будут выводиться в проектах, которые будут использовать этот UDF:
Задали названия внешних сигналов блока
Вот что получилось теперь:
Наш блок UDF управления вентилятором полностью готов
Я, пока рисовал UDF для поста, ещё немного поколдовал и зафигачил вход для Reset — принудительного выключения нашего вентилятора. Вдруг, к примеру, надо будет вентиляторы остановить вместе с центральным выключением света по квартире =)
На этом наш UDF готов и его можно использовать в любом проекте Logo. Надо только подключить его в Logo Soft Comfort. Для этого тыркаем правой кнопкой в дереве элементов на пункт «UDF» и выбираем единственный пункт «Configure UDF…»:
Меню для добавления UDF-блоков в проект
Добавляем все наши UDFки в список:
Список блоков UDF для среды Logo Soft Comfort
После этого они появятся в дереве элементов, и их можно использовать так же, как и обычные элементы схем.
Захерачиваем UDF — и наша мега-схема превратилась из суперсложной в херовинку из одного прямоугольничка и трёх линий IO:
Была жирная схема в проекте, а стал маленький блочок UDF =)
Все имена, которые мы задавали, отображаются: название блока и названия всех сигналов. Вот и все хитрости с UDF!
3. Косяки с названиями и передача параметров из UDF-блока
Хех… но не все! Когда я первый раз делал свой UDF для управления светом, то мне надо было сделать некоторые сигналы с разным приоритетом по времени. Я выдумал сигналы Set/Reset и Store/Restore для того, чтобы включать-выключать свет и запоминать и восстанавливать его состояние как было до выключения. И мне ОЧЕНЬ хотелось сделать так, чтобы на блок можно было бы подавать одновременно Reset + Store. А для этого надо замутить приоритет: чтобы Store/Restore обрабатывались внутри блока первыми, а Set/Reset — вторыми. Ну, я и наставил формирователей импульсов внутри блока, которые генерировали мне нужные фронты.
И начал делать на них свой первый проект (в Золотую Звезду; пост лежит тут). Накидал UDFок штук десять — и тут мне Logo каааак ругнётся что всё — не может он больше блоки добавлять, потому что памяти не хватает. Опаньки! Это ж как так? Типа создал UDF, использовал его раза четыре — и досвидос? Хммм.. странные какие-то UDFки… )
На самом деле косяк был в другом! В именах блоков! Когда я делал скриншоты для поста, я не смог воспроизвести ошибку так, как она появлялась у меня только в тот момент, про который я рассказывал. Поэтому сейчас мне придётся показывать вам общий смысл этого косяка.
Помните, что у Logo есть возможность редактировать параметры блоков аппаратно? Ну, когда берёшь какой-нибудь таймер, называешь его как «Work time», а потом прям на Logo в меню «Program -> Set parameter» (аппаратно) можешь подкрутить время его работы? Так вот для этого как раз и нужны названия блоков. Когда я делал свой UDF, я называл все-все блоки. На это тратилась память Logo, и когда я наставил несколько штук блоков — она вся кончилась.
Вывод отсюда уже понятно какой напрашивается: нехер бездумно тратить ресурсы! Если параметры блока будут меняться — то тогда ему и надо задавать имя. Если не будут — то нефиг его именовать; лучше использовать поле «Comment» для названия.
Посмотреть то, сколько занимает ваш проект, можно по кнопке «F2». В этом случае в окно сообщений (в нижней части Logo Soft Comfort) выводится такой вот листинг:
Проверка ресурсов проекта (по клавише F2): хватит ли памяти Logo?
По нему можно увидеть ограничения Logo и то, сколько из них вы уже использовали. Например, с маркерами надо ожидать такой же фигни, как с Block names: если напихать в UDF дофига маркеров, то они в Logo могут быстро кончиться. Ещё интересы пункты «UDF types» и «UDF instances»: в проекте может быть всего до 16 разных UDF (разных штук внутренностей) и до 64 штук UDF в общей сложности.
Я уже упоминал о том, что маркеры (M, «Flag») внутри UDF никак не связаны с проектом Logo. Да, так и есть. Но как ресурсы Logo они вовсю тратятся, причём Logo Soft Comfort сам следит за тем, сколько осталось свободных маркеров.
Я из того проекта, с которого скриншотил, всё стёр и добавил две штуки наших UDF, внутри которых используется один маркер M (Flag), и просто ещё один маркер.
Пример того, как расходуется память маркеров Flag в Logo внутри UDF и в проекте
Смотрите, что получается! Первые два маркера Logo отдал под наши UDF, и поэтому следующий маркер стал номером 3. А если попытаться поменять его номер — то первые два в списке уже недоступны.
Рассказывая про названия блоков, я заикнулся про параметры, которые меняются через меню Logo. А у нас же UDF как раз для управления вентилятором по времени! Внутри UDF для примера я давал названия всем блокам, в том числе и таймеру вентилятора. Ну-ка посмотрим, как это выглядит: будут ли названия блоков из UDF отображаться в меню Logo?
Зальём программу с нашми UDF (и исходными схемами без UDF на два вентилятора) в Logo и зайдём в меню:
Экран Logo. Отображаются только обычные параметры, а не параметры из UDF
А ХРЕН вам, батенька, а не параметры из UDF! Угу, всё что было нафигачено внутри UDF — так внутри UDF и остаётся! Так это и правильно: как же ж Logo разберётся, какой именно параметр из какого именно UDF надо выводить в меню? И как их именовать, если внутри UDF задано всегда одно и то же имя параметра?..
Что надо сделать? То же, что мы делали с именами входов-выходов — составить список параметров UDF. Снова заходим в свойства UDF-блока (меню «Edit -> Edit UDF Properties…»), на вторую вкладку:
Редактирование внешних параметров UDF-блока (время работы вентилятора)
Здесь можно выбрать элементы нашей схемы (внутри UDF) и то, какие их параметры надо вывести наружу из нашего UDF. Опять же зацените ублюдочную вёрстку окна: выбирать надо снизу, а добавлять — вверх. Неужели эти области местами нельзя было поменять?.. Зато теперь ясно, какого хера на первой вкладке этого окна оставалось пустое место около таблиц входов-выходов: чтобы на второй вкладке хватило места под два списка выборов. Пиздец, очень меня всё это стало бесить. Особенно если с CodeSys сранивать!
Слева снизу вы выбираете элемент схемы, параметр которого надо вытащить наружу. Справа в списке отображаются его параметры. Вы выбираете нужный и жмёте кнопку «Add». А в верхнем списке в колонке «Identifier» задаёте внешнее понятное имя для этого параметра. У меня он будет зваться «Time».
Сохраняем изменения в UDF и идём в наш проект. А чего это там за восклицательный знак появился? А это значит то, что UDF в проекте и UDF в файле не совпадают: вы чего-то поменяли, и Logo не знает, что с этим делать.
Команда для обновления UDF-блока в проекте (если поменяли сам блок)
Надо обновить UDFки в проекте, чтобы Logo подгрузил их из новой версии. Нажимаем правой кнопкой на наш UDF, выбираем пункт «Update UDF». После этого инфа в проекте обновится на нашу новую изменённую версию.
Теперь у нашего блока появился параметр «Time». Тыркаем два раза мышкой на блок, и вылазит стандартное окно настройки свойств блока:
Теперь у нашего блока есть параметр - его можно задавать так же, как и обычные параметры FB-блоков
Задаём нашему UDF имя, которое будет отображаться в меню параметров, и время работы. Всё точно так же, как было бы для обычного таймера.
Вуаля: вот теперь в меню параметров Logo появился новый пунктик:
Экран Logo. Теперь отображается ещё и параметр из UDF-блока
Заходим и видим наш параметр «Time». Ура! =)
Экран Logo. Настраиваем параметр Logo из UDF-блока как обычно
Вот такие вот игры с UDF получились. Для своих задач я накатал себе UDF для работы с кнопками по аналогии с FB из библиотеки OSCAT для CodeSys: он определяет одинарное, двойное и длинное нажатие. Все таймеры внутри — а снаружи только удобные выходные сигналы. Берёшь и пользуешься!
Мои блоки UDF для управления светом на Logo
А ещё я накатал огромный UDF для управления светом как аналог штатных импульсных реле Logo. Мой UDF умеет запоминать предыдущее состояние света и восстанавливать его обратно как было. Есть входы для того, чтобы сохранить состояние, стереть сохранённое и выход, который показывает: сохранено ли чего-то или нет.
Так что теперь в моих щитах с Logo появилась такая фишка: длинное нажатие на кнопку при входе в квартиру вырубает весь свет, а двойное — врубает как было! А если что-то сохранено (свет горел перед центральным выключением) — то подсветка кнопки мигает. Позжее я добавлю сюда видос из поста про щиты на Logo (на Золотую Звезду), где всё это будет видно в работе!
4. Сетевые проекты для Logo. Херачим распределённую программу!
Когда я несколько лет назад начинал изучать логические реле и ПЛК, то больше всего я морочился не про функционал, а про то, что у них всех мало входов-выходов, и поэтому искал такие модели, у которых IO можно было расширять: с модулями расширения или со связью между контроллерами. Некоторые производители (Eaton или вот наш Logo) пишут примерно так: «Возможность связывать несколько Logo по сети между собой».
Ну, я тоже на это покупался и думал: «Вооо!! Ща я сделаю мега-щит, и у меня будет 150 входов и 200 выходов, охрененно, круто!». Вот ща мы и разберёмся — можно ли такое наворотить на Logo, как это делается и что ещё можно вытворить. А когда я буду писать пост про ModBus, то ещё раз вернусь к теме сетевых проектов Logo.
Вы уже видели у меня щит в Фили-Град, где было два Logo. Вот фотка оттуда:
Два Siemens Logo для управления освещением (в один не уложились)
Откуда их две штуки набралось? Да потому что в один не уложились, а на ОВЕН нет в щите места: ОВЕН требует опускать рейки по глубине и кучу внешних исполнительных релюшек, а это не всегда влазит в щит. На самом деле ОВЕН (или другой ПЛК с ModBus и модулями ввода-вывода) удобнее, если нам надо получить много линий IO, так как у ПЛК сама система для этого предназначена, а для Logo это уже изнасилование в извращённой форме.
Так вот если мы не укладываемся в один Logo, то надо ставить их два. Или три (вот в том посте про щиты с Logo, который я обещаю, будет такой щит в Дмитров). А раз Logo в щите стоит несколько штук, то надо думать о том, как их между собой соединять для того, чтобы они могли обмениваться данными. И вот тут есть варианты, которые я расскажу на примере тех щитов, которые я на Logo собираю.
Вариант первый — связать Logo между собой аппаратно (общие сигналы подавать через линии IO). Этот вариант я для себя и выбрал, потому что здесь каждый Logo ПОЛНОСТЬЮ автономен и не зависит ни от состояния сети, ни от других Logo. Мы просто заводим одинаковые сигналы на разные Logo — например, сигнал от кнопки центрального выключения света.
Самый главный плюс такого варианта — это адская надёжность и автономность (из-за этого я его и использую), так как вся логика управления находится внутри каждого Logo и не зависит от состояния сети. А минус этого варианта в том, что надо распределять IO по Logo таким образом, чтобы те линии, над которыми мы хотим делать группоые операции (например, центральное выключение света по комнатам целиком при помощи длинного нажатия любой из кнопок света в этой комнате), были целиком внутри одного Logo и не разбивались на два. Пока мне везёт, и у каждого Logo остаётся по 1-4 свободных линии IO.
Вариант второй — связать Logo между собой по схеме «Master — Slave». Это — тот вариант, про который обычно рассказывают производители — типа, вот возьмите кучу Logo и постройте большой щит. Сама программа, если использется режим «Master — Slave», единая для всех Logo и ограничена ресурсами только одного Logo, а удалённые Logo только расширяют линии IO (есть связь только с Input, Output, Analog Input, Analog Output). Зато можно нарисовать большую программу сразу на всю квартиру.
Как это работает? А по обычной Ethernet-сетке! Каждому Logo назначаются свои IP-адреса, а схема-программа составляется при помощи блоков «Network Input», «Network Output», привязанных к этим IP-адресам.
Вот тут-то и возникает первая особенность — IP-адресация и рабочая сетка. Да, я знаю о том, что даже у самого Logo есть свитчи (коммутаторы) на DIN-рейку в аккуратном корпусе. И что можно сделать локальную сетку прямо внутри силового щита. Я ОЧЕНЬ не хочу использовать это всё из-за того, что такая сетка зависит от IP-адресов (а они жёстко прописываются в программе Logo), которые точно отличаются у меня и у заказчика (и чтобы воткнуть Logo с моей программой в свою сеть, ему придётся или переделывать программу в Logo, или перестраивать свою сетку под мою). А если ставить в щит свитч — то блин, это ж потенциальный источник коллизий, мать их.
Хорошее решение — это протащить к каждому Logo в щите свою витую пару от основного свитча квартирной/коттеджной сетки, но щит-то тогда перестаёт быть надёжным готовым изделием, потому что вся работа Logo будет зависеть от состояния этой самой сетки. Отвалится она — и свет аллес =)
Вариант третий — связать Logo между собой по схеме «Master — Master — Master». Этот вариант — смесь двух предыдущих: в каждом Logo теперь будет своя отдельная программа, которая будет крутиться внутри этого Logo. А через сетку можно обмениваться какими-то событиями. Скажем, послать команду центрального выключения всем Logo с любого другого. Тут, если мы заранее про это подумаем, нам не так критичен отвал сетки: тогда просто не будут проходить централизованные команды (если мы решили передавать их по сетке), а свет самими Logo будет управляться как обычно.
В таком режиме можно дёргать из других Logo гораздо больше штучек: входы, выходы, маркеры (флаги M), переменные из памяти переменных (VB) — то есть передавать кучу разных данных или тех же флагов. Правда, всё равно, если нам нужна команда центрального выключения света — то проще все Ixx у Logo вместе проводом в щите соединить и не париться =)
В общем, пока мне позволяют щиты и задачи, я стараюсь избегать сетевых проектов, чтобы мои щиты не зависели от состояния сетки. ПЛК ОВЕН в этом плане удобнее: там RS-485, который никаких свитчей не требует — развёл его внутри щита, подключил всё IO, и нехай работает! А сетка нужна только для программирования ПЛК или доступа к нему через инет. Конечно же в будущем моя логика может измениться, но пока что (на момент даты этого поста) у меня придумано именно так.
Давайте посмотрим на то, как создаётся сетевой проект в Logo и что там можно сделать. Чтобы начать делать сетевой проект, надо перейти на вкладку «Network Project». Тут у Logo Soft Comfort опять мутная муть, потому что несмотря на то, что мы начали вроде как новый проект, только сетевой, все прошлые открытые файлы на вкладке «Diargram Mode» остаются, хотя это всё должно было бы закрываться — новый же проект начали!
Вкладка сетевого проекта среды Logo Soft Comfort
Экран Logo Soft Comfort в режиме сетевого проекта будет разделён на четыре части: слева сверху — дерево устройств проекта и их схемы-программы (если есть), слева снизу — набор блоков, из которых можно будет рисовать схему для текущего устройства (схема которого будет открыта), справа сверху — схема связей между устройствами проекта и справа снизу — схема текущего устройства в проекте (такой же редактор, как в обычном режиме Logo Soft Comfort).
Схема связей (соединений) задумана для того, чтобы показывать TCP/IP-соединения между устройствами и их параметры (например, указать то, какие параметры опрашиваются по ModBus или другим протоколам). Соединения создаются сами, если мы задаём в программе какую-либо связь, или вручную, если нам надо заранее прописать обмен, но ещё не рисовать схему.
Начнём с того, что добавим в наш проект несколько устройств. Пользуемся кнопкой «Add New Device». Смотрите, СКОЛЬКО тут всего есть!!
Окно добавления устройства в сетевой проект Logo
Поддерживаются Logo в режиме «Slave» (когда программа единая, и надо только увеличить число IO), в режиме «Master» (когда программы в Logo отдельные, но могут обмениваться параметрами между собой). Можно воткнуть связь с S7 — внутренним протоколом ПЛК Siemens, с текстовым дисплеем для Logo TDE и, наконец, можно ModBus! =)
Для каждого устройства надо задать имя (чтобы различать их в проекте) и IP-адрес (и остальные параметры сети). Вот с этого-то момента и нет шага назад: сетевой же проект, без сетки работать не будет =) Хоть одно хорошо: если поменять IP-адрес в свойствах устройства, то все ссылки на него в проекте тоже поменяются. Ура, а то я боялся что всё вручную надо будет перехерачивать по всей схеме!
Всё, что мы добавляем, отображается в дереве слева сверху. Тут можно открыть окно параметров или схему. То же можно сделать, если кликать по шестерёнке на устройстве в схеме соединений. Схема открывается просто двойным щелчком по устройству.
Список устройств и схем сетевого проекта
Вот я добавил два Logo в режиме «Master» и одно устройство ModBus. Соединения нарисовал руками просто для того, чтобы показать то, как это выглядит.
Соединения между устройствами в сетевом проекте Logo
Для соединений на каждом устройстве есть определённые слоты. Слот, который отстоит от других (самый левый на Logo), обозначает динамические соединения, а остальная группа слотов — статические соединения. Из справки я понял это так: статические — это те, которые создаются и поддерживаются всегда (не разрываются), а динамические — это соединения по запросу. Между Logo устанавливаются статические соединения, а между Logo и ОВЕНом среда позволяет сделать только динамическое.
Сам сетевой проект сохраняется как один единый файл. И… на деле это ZIP-архив, внутри которого лежат обычные .lsc-файлы для схем устройств проекта. Пипец находка формата файла, блин! =) Вообще, с этим в Logo Soft Comfort угар: обычные программы хранятся в бинарном формате, сетевые проекты .mnp — ZIP-архив, а UDF-блоки — вообще в XML. Бля, чем дальше я копаюсь в Logo Soft Comfort — тем больше он мне кажется сляпаной на коленке поделкой.
Чтобы общаться по сети с другими устройствами, нам понадобятся входы и выходы из раздела «Network»:
Сетевые входы и выходы в списке элементов схемы Logo
Обычные Input/Output передают один бит, True/False (аналог «Coil» в ModBus), а аналоговые (Analog) передают слово (два байта, 16 бит). Эта инфа потом пригодится в посте про ModBus, а если мы соединяем Logo c Logo — то там всё работает точно так же, как обычные или аналоговые входы и выходы.
Например, хотим мы дёрнуть физический выход на втором Logo. Добавляем «Network output», лезем в его свойства и выбираем то, куда нам надо направить этот выход. VM — это переменные в памяти (их можно потом передавать по ModBus), а «Remote device» — это такое удалённое устройство, которое Logo понимает напрямую (не надо указывать адреса переменных в памяти и прочие штуки).
Выбор типа устройства для связи (Logo) и настройка того, чем будем управлять
В нашем случае мы выбираем второй Logo из списка (и вот тут годится его понятное имя, чтобы ориентироваться по нему, а не по IP-адресу), а потом выбираем тип того, что надо удалённо дёргать (для Logo Master это будет вход I, выход Q, флаг M и переменная в памяти V. Ну и выбираем номер этого элемента.
Как только в проекте появились настроенные удалённые IOшки, то Logo Soft Comfort сразу же создаёт соединение между этими элементами. Вот оно на скриншоте. Я с первого Logo взял вход на вентилятор, а управление самим вентилятором прокинул на второй Logo:
Создали связь со вторым Logo и назначили парочку удалённых выходов
Примерно так же задаются параметры ModBus. Тоже выбираем устройство, его адрес в сети, тип команды (Write Coils, Write Register) и номер регистра, в который пишем.
Создали связь с каким-нить устройством ModBus (команда Set Coils)
Только вот опять мудаки в Logo почему-то адрес устройства в ModBus назвали как «Unit ID», а номер регистра назвали как «ModBus address». Пиздец! Прям как Sunlight в сценосвете — уебанская программа совершенно.
Итого у нас получились вот что:
Полная схема сетевого проекта со всеми соединениям и связями
Дальше такой проект можно загрузить в Logo и он будет работать (на ModBus я проверял, хе хе).
Если сделать двойной щелчок на линии соединения, то открывается окно его свойств. Кое-чего менять нельзя (кто Master, кто Slave именно в соединении, а не в проекте, IP-адреса, передаваемые данные).
Окна со списком параметров, которые передаются по сети Logo
Если вы создаёте ModBus-соединение с нуля, то в этом окне будет список переменных, которые оттудова надо опрашивать. А если задаёте параметры на схеме в проекте — то список будет недоступен; менять их надо будет в схеме проекта — там же, где они и были заданы.
Ещё обратите внимание на то, что минимальный интервал работы по ModBus у Logo нельзя задать меньше, чем 80 мс (а для Logo-Logo такого лимита вообще нет). Так что все идеи типа «Ща мы воткнём сюда парочку модулей ввода-вывода на 32 линии каждый и забацаем на Logo по ModBus щит коттеджа» идут лесом. А вот поопрашивать какие-нибудь аналоговые входы (например, кучу датчиков температуры или давления) — можно.
Вот и все хитрости! Творите, камрады! Если используете эту инфу — оставляйте у себя ссылку на этот пост! Через некоторое время я довыложу пост про щиты с Logo (я за этот год собрал несколько штук) в формате собранного опыта по разработке, а потом и про ModBus в Logo. Я уже пробовал, и это и весело и слёзно одновременно!
Проекту исполнилось 15 лет! Поддержать проект материально, проспонсировать проекты Автора или сделать ему подарок можно на этой странице: "Донаты и Спонсорство, Список Желаний".
Немного попытался нарисовать реализацию с одинарным/двойным и длинным нажатием. Выход Q1 всегда будет срабатывать по нажатию (0->1), тут ничего не поделаешь. По отпусканию запускается таймер, в течение которого второе нажатие активирует Q2. Ну а Q3 по длинному нажатию. В симуляторе вроде работает.
Это к дискуссии pressmaster & CS. Об этом речь была?
УГУ! Я также выдумал его: по отпусканию кнопки запускается мелкий таймер. Если, пока он считает, пришло ещё одно нажатие — то двойное. Иначе — одинарное! =)
А ты нафига на триггеры вывел? Это ты тестировал или хотел у себя в проекте фиксировать такие нажатия и переключать ими чего-то?
Это pulse relay на выходе. Собственно это простейший вариант реализации кнопки — сразу на выход. А с триггерами я еще думаю. Дело осложняется тем, что logo запрещает рекурсию — только через Q или M. Одно нельзя использовать в udf, второе в ограниченном количестве. А хочется запилить udf, который будет pulse relay w/ memory. Что бы на входе был Trg, Store&Reset, Restore. Но пока не получается, надо думать.
sba Я у себя M заюзал и не стал париться, потому что заточил UDF под свет, а тут всё равно больше 20 выходов ты их и не сделаешь — значит из 64 маркеров потратится 20 штук — да и плевать на них!
А если система будет распределённая по сети — то опять же, в каждом Logo тогда будет занято 20 маркеров из 64.
Да, с флагом все работает. Только вот не ясно, при использовании в udf — это будут разные флаги? И как тогда будет нумерация? Если начать с М1, то там М8 и далее есть служебные флаги. Их бы не хотелось трогать. В общем с флагом у меня получилась такая вот схема одного исполнительного элемента — импульсное реле (Trg), вход Store/Reset — сохраняет статус и сбрасывает реле, Restore — подает импульс / либо не подает на Trg, в зависимости от состояния триггера. В udf пока не заталкивал — так проще отлаживать с I/Q — их видно на симуляторе :) Однако хотелось бы как-то этот флаг убрать и сделать без него. Не люблю глобальные переменные :)
Еще, кстати, момент. При включенном сохранении состояния, по идее в EEPROM/FLASH будет записываться каждое изменение состояния элемента. Не знаю, как они там организовали хранение, но если в ту же ячейку, то ресурс не бесконечен. А при такой схеме сохранение производится только при наличии сигнала Store.
О, вроде как все получилось. Ничего, если я тут немного картинок понакидаю?
Первый блок — Btn, на входе кнопка, на выходе импульсы Single/Double/Long. Причем Single/Double работают напрямую от кнопки (отпускание), а Long принудительно делается импульсом в 1 такт (иначе Reset нормально не работает).
Второй блок — собственно реле с памятью. Выше уже описывал. Нарисовал схему использования:
I1 — это кнопка в комнате, управляет двумя группами света. Одиночное — 1, двойное — 2, длинное — выключает (с сохранением).
I2 — общая кнопка на выходе — длинное выключает с сохранением, двойное — восстанавливает.
Эх, осталось обзавестись железкой и потестить как следует :)
Один раз ничего! Потом, как я говорил, я пост накидаю и туда эти комменты переедут, чтобы по теме было! =)
У меня подобная задумка и есть! Только я замутил Set/Reset, Store/Restore и Clear ещё =) И сделал приоритеты для Store/Restore.
Поэтому по помещению у меня подаётся просто Reset (для концепта), и блок просто вырубается (центральное выключение по помещению), а по всей квартире подаётся Reset + Store.
Идея понятна. А зачем отдельные сигналы Store и Clear? Я исходил из логики, что сохранение необходимо только при сбросе и в принципе без разницы, центральный это сброс был или местный — сохраняется всегда. Не могу придумать ситуацию, когда нужно сохранение просто так, отдельно от сброса. А прямые Set/Reset согласен, хорошо бы иметь если надо откуда-то выставить принудительно. Так-то я старался управлять только импульсным реле, т.е. что бы выход был только через него. Заодно обнаружил у себя баг — если после выключения с сохранением что-то включить, а потом сделать restore, то он перещелкнет включенное реле.
Кстати, про флаги. На форумах пишут, что где-то он их сам нумерует при добавлении элементов на схему. Но при этом как-то странно — я в udf использовал M32, добавил на схему два элемента. При добавлении на схему флага видно, что М32 недоступен (используется в udf), а вот М33 — есть. И при работе двух udf они друг на друга не влияют. В общем не понятно, что там внутри происходит. Зато нашел способ, как обойти запрет рекурсии не используя флаг :)
sba А я исходил, как обычно — из универсальности. Мало ли чего и где понадобится?
Про флаги — скорее всего среда глючит и толком в UDF их не может подсчитать =)
Надо опыт поставить. Воткнуть мигалку на M33 твой и накидать UDF и посмотреть — будут глючить или среда возьмёт другой, не занятый? =)
С флагами я проверил — там все корректно. Какие флаги берет — не сознается, но они не пересекаются. А вот я еще другую интересную штуку раскопал. Сетевые входы/выходы. Оказывается, это все реализовано через локальные переменные, коих там аж 850 штук. И что самое главное — эти входы/выходы не обязательно по сети должны работать, они и с локальными переменными прекрасно общаются. Первое, что приходит на ум — сигнальная шина. Вместо того, что бы тянуть кучу линков к примеру на общий reset, ставим один Nout, в нем выбираем адрес, и к блокам где надо получить сигнал — ставим Nin. Теперь подаем сигнал на наш Nout и он разлетается по всем блокам. Единственное — ограничение в 64 штуки всего. А еще, эти переменные можно мапить к параметрам блоков.
Про выходы по сети — это я даже давно писал. И писал, почему я их не использую. Там и Modbus есть. Просто читать надо.
А вот про сетевые порты мне на глаза не попадалось, хотя вроде все прочитал. Ок, перепроверю.
Modbus я видел, но это уже промышленная автоматика, явно не для дома :)
sba А оно в явном виде и не попадётся. Это может быть всего лишь одно предложение вида «вообще у Logo есть возможность работать по сети в редиме Master-Slave, но я этим не пользуюсь, потому что не хочу чтобы мои щиты зависели от состояния внешней сетки» ;)
А modbus — это ты зря. Например можно к Logo какие-нить нестандартные датчтки подцепить или тоже IO расширить. Но опять же по сетке.
Ну разве что нашел упоминания про общение по сети между logo. Это понятно — зависимость от сети.
Я же говорил несколько о другом. Тут речь о работе через loopback. Если быть точнее, то с локальными переменными. К сети это в принципе, отношения особо не имеет, кроме названия.
Но профит здесь такой — не надо тянуть к каждому блоку глобальные сигналы с единой точки, а просто расставляя в нужных местах NI и NQ и выбирая соответствующий адрес переменной можно сделать такой себе локальный broadcast.
Так же, стоит упомянуть, что через переменные очень удобно работать со встроенным web сервером. Это весьма удобная штука, т.к. не требует никаких дополнительных устройств — рисуешь план квартиры, расставляешь управляемые точки (картинки) и отображаешь статус. Так же и управлять можно.
Я у себя проверил — вполне неплохо работает. И рисовалка страниц весьма примитивная, делов на 5 минут. Только ему вроде sd карта нужна, что бы сохранять созданные страницы.
А modbus — согласен, много чего можно подцепить, но пока не возникло такой необходимости :) Еще, кстати, есть S7. А для работы по S7 есть библиотека snap-s7 и на базе этой либы запилили драйвер для node-red. Ну а дальше стандартно — малина и понеслись навороты :)
sba Агась, loopback. А IP как вводится? Не опять ли в коде программы? А шо будет, если ты ИП в настройке Logo сменишь? К примеру, у меня дома сеть 10.0.x.x, а у многих — 192.168.x.x.
С глобальными сигналами всё проще. На панели инструсментов есть кнопка «Cut Connections», и я ею активно пользуюсь. Можно даже по разным страницам соединения раздирать.
Не усложняй простые вещи, а? Я помню, у тебя есть эта черта ;)
Цепани скриншот рисовалки! Интересно! Надо себе поставить (у нас тут где-то ссыль пробегала) и заценить на каком-нить Лого! =)
вот моя реализация выключателя single double long клик
Коллеги, кстати, если кому-то будет полезно, то два контроллера видят друг друга по ethernet без коммутатора. Патч-корд брать нужно с прямой (обычной) обжимкой, не кросс. Я назначал один мастером, второй слейв и … все работает.
Вообще я уже давно не встречал сетевых устройств которым нужен кросс — обжим.
Все в железе реализовано.
Не нужно пытаться «попасть» ip адресами в сеть заказчика.
Наоборот нужно отделить ip cеть автоматики от остальной.
Желательно и физически.
Т.е. отдельный свич для щита это не проблема, а наоборот отличный вариант для закоченного щитка. (А при только двух устройсвах и свича не нужно)
Если же планируется подключать удаленное управление по сети (ethernet датчики, или исполнители), то тогда можно соединить свич в щитке с общедомовым. Но объединять ip адресацию не нужно и даже противопоказано (а для полной красоты выделить vlan для устройств автоматики).
А про «потенциальный источник коллизий» это что-то из прошлого века. Не нужно так. :-)
alpha.fm Ну нет уж! Я считаю, что для квартиры извраты с обособленными сетями — уж слишком перебор и гадко.
Это, прикинь, если надо будет новую программу в Logo влить — бери комп, прись в щит, цепляйся к его обособленной сети, меняй IP-адрес компа, заливай, потом возвращай всё назад.
А ещё ты, камрад, забыл про WEB-визуализацию в Logo. Она там есть (через Logo Web Editor) — и как тут быть? Не менять же IP компа всякий раз, когда на лого надо глянуть…
Сделал вот такую реализацию кнопок.
Включение происходит с небольшой задержкой, но зато нет срабатывания одиночного нажатия и схема легко масштабируется до троных, четверных и т.д. нажатий.
Отлично! Вот здорово! Я дал принцип, а вы дальше его дорабатывайте =)
Я не хотел так морочиться, мне было интересно сделать именно как в компе: что Double обязательно означает то, что Single тоже проходит.
Если нужно более менее регулярно связываться по сети с Logo, то нужно сети соединить физически и сделать маршрут на роутере.
Нет тут никакого перебора. Это реально на порядок проще, чем остальное что обсуждается в данной статье. :-)
В данном вопросе две части. Физическая зависмость автоматики от «какого-то внешнего свича», что решается выделенным свичом и одним проводом наружу.
И логическая, это в частности ip адресация.
Я бы очень не хотел чтобы автоматика зависела от того что происходит во внешней сети. Более того, я бы не давал доступ в интернет Logo, а это легко организовать выделив ему отдельную ip сеть.
Я так понимаю, что дискуссия у нас в данном случае от разных сфер деятельности. :-)
Я вот знаю про логические элементы, и схемы из этой статьи для меня не китайская грамота, но сложно из-за отсутствия опыта.
А для тебя ip сети это знакомая сфера, но сходу не понятны нюансы, а для меня наоборот.
Это нормально :-)
Пообщайся на тему сетей с каким нибудь знакомым авторитетным для тебя человеком, я так понимаю такие люди есть.
В данном случае часовой мастер-класс за чашкой чая может дать отличный толчек для дальнейшего понимания и развития.
alpha.fm Хмммм… я когда-то спрашивал про ArtNet. Вот, на сообществе. Хер кто сказал как это сделать без изъёбов или этого… microtik. А там задача была такая же, как ты ставишь — подружить 2.2.х.х и 10.0.х.х так, чтобы они в одном свитче работали и можно было с одной сетки коннектиться к другой как нефиг делать.
Это — изъёбы. Нахер такое. А то давай до VLAN ещё докатимся, который Logo не понимает.
Так, давай ещё раз подерёмся. Не думаю, что за 20 лет TCP/IP прям так поменялся или выдумали чего-то новое в MAC-адресах или роутинге. Да, роутинг я знаю только как NAT и VPN, как подружить две сети — я не умею. Но мне это и не надо. Поэтому не хочу я в этом разбираться.
Я хочу, чтобы никакие мои заказчики не трахали себе мозги с Logo и сеткой. И ещё я хочу, чтобы мой щит был готовым изделием и при этом, когда у заказчика дома 19″ шкаф и гигабитная сетка, никакой 100- или 10-мегабитной инфекции в щите не стояло. Вообще.
А ещё, чтобы не драться, я тебе доскажу. Да, я в курсе, что ОБЫЧНО стараются разносить всякие хуйни по разным сеткам. Через VLAN или физически. Тот же ArtNet так и задуман, к примеру. Или так удобно сделать для видеонаблюдения, чтобы какой-нить вор снаружи сетку не начал укладывать.
Но я не хочу заниматься этим на потоке щитов. Я хочу, чтобы мои щиты были простые в плане подключения и настройки. А чтобы пусконаладка шла к сложным щитам, а не к таким, где Logo светом рулит и через визуализацию это отдаёт.
Ещё я например облака люто ненавижу. И всегда выберу белый IP и VPN к себе домой, чем через облако данные херачить. Поэтому мнгого сеток и прочие извраты я не считаю чем-то хорошим. Да и чего я… я свой взгляд изложил. Идеи вам выдал. А дальше берите эти идеи и делайте так, как вам всем удобнее — мне на это пофиг, я изобретатель и генератор новых идей!
UPD. Что касается людей. ХУЙ ТАМ! У меня ща полный кризис общения. Только два человека остались, с которыми я могу искренне общаться.
А те, кто пытается дружить с блога — чаще всего делают это или из корысти, или из какого-то уважения/пресмыкания, что отбивает вообще всю охоту общаться.
Поэтому да, я с радостью вспоминаю о тех временах, когда вокруг меня были люди такие же увлечённые и своим рассказом про 1Ски, серваки, компы могли вдохновить. А не тупо дать инфу или сказать «делай так, тебе понравится».
Ща у меня набираются новые вопросы — про WEB, облака, нейросети — но нет тех, кто может увлечённо рассказать про это.
Поэтому в плане общения у меня треш, кризис и пиздец. И я от этого сильно страдаю.
Если периодически нужно налазить на контроллеры, которые находятся в другом адресном пространстве, то можно объединить эти сети железно через коммутатор.
А на компе, с которого будем заходить на контроллеры, поднять второй ip адрес на интерфейсе, единственное условие, статика на этом интерфейсе у обоих диапазонов
Wirth А спинку этой сетке вареньем крыжовенным не намазать ещё?
Что-то какой-то ёбаный гемор получается ради того, чтобы зайти с телефона на Logo и перетыкнуть там свет.
Нахер такие сложности дома нужны?
Ща объясню. Например, у меня на даче инет только мегафон или йота. Сответствено серый IP (можно на мегафоне белый но дюже дорого). Поэтому у меня в москве и на даче по микротику. В москве белый ip и vpn (l2tp и openvpn) с дачи домой, c автопереключением между ними. Плюс куча скриптов, обеспечивающих резервирование. Соответсвенно 2 разные сети (Москва и дом). И таки да, чтобы пощелкать светом (или включить отопление) knok-knok защита, чтоб это сделал только я. Поскольку безопасность и бытовой контроллер — не совсем одно и то же.
Csыч, не могу разобраться. Есть в лого начальная инициализация переменных?
Мне надо устанавливать SetPoint со стороны сети. NAI связанный с локальной переменной. Вот как мне ее при старте лого, или при перезапуске сбрасывать на какое-то значение. Сделал схему, но мне не нравится.
Что такое SetPoint?
Маркер ты правильно взял. Только ты забыл, что у этого мудака Logo минимум 80 мсек опрос идёт по сети.
Поэтому тебе надо по маркеру запускать какой-нить формирователь импульса, который тебе это значение будет держать например 500 мс.
И ещё не забудь, что у этих мудил все значения Signed, а не Unsigned бля.
Установка целевой температуры. С возможность установки из сети.
И задача чтобы при старте Лого, он уже какое то состояние задал. Чтобы когда-то потом через KNX интерфейс его можно было установить. Не спрашивай, почему не все на KNX (слишком жирно для простой котельной). Да и Лого в запасах валяется.
Ну вот если там типа ModBus — то нужно чтобы этот твой мультиплексор выдавал сигнал хоть на 500 мсек или одну секунду, иначе он просто не успеет на выход попасть.
Попробуй подключить его на постоянку и вообще посмотреть, доходит ли эта инфа до получателя или нет.
А то я трахался так с ModBus — он у меня никак не хотел Write Registers писать, а Write Coils — запросто.
Еще один вариант включения разных групп. Доработал схемку, добавил длинное нажатие.
Одиночное нажатие подает сигнал на Q1, двойное на Q2 и тройное на Q3.
Romesskin а если быстро нажать 1 раз а потом долгое нажатие, отработает долгое и 2ое нажатие?
Wirth, да, но я думаю что с клавишей которая на стене привыкнуть можно. В любой схеме, где есть таймеры, могут быть такие вот коллизии!))
Wirth, есть решение проблемы добавлением в разрыв второго и третьего выхода, блока B009, как у первого выхода, с таким же подключением.
Комменты подрезал чуток =)
Я делал с таймерами. Нажали один раз — запустился таймер на выдержку. Если за это же время отпустили и ещё раз нажали — то выдаём двойное нажатие. Тут без коллизий будет.
CS, коллизии убрал, все работает.))
Привет. Хотел бы поделиться своей реализацией пользовательской функции. У неё в качестве параметров минимальное и максимальное количество нажатий. То есть можно задать, например, от 49 до 97 и если подряд будет нажатий в этом диапазоне, то функция выдаст сигнал, если меньше или больше — не выдаст. С помощью ее у себя реализую одинарное, двойное, тройное нажатия, задавая от 1 до 2, от 2 до 3 и от 3 до 4 соответсвенно. Если нужно несколько функций на одной кнопке, то ставится несколько таких блоков с входом от кнопки и только один в итоге дас сигнал на свой выход
Так же есть реализация длинного нажатия, комбинаций нажатий (например длинное, а потом тройное короткое) — если интересно, могу показать
MacSergey Слушай, а ты помнишь что количество экземпляров UDF в проекте ограничено?
Ну, там 64 штуки — но с таким каскадом UDFох их реально занять все, если ещё какие-нить UDFки на свет сделать!
CS, это всегда дилемма в программирование: потратить много времени и сделать очень оптимизированную, но узконаправленную программу или очень быстро использовать многофункциональную, но которая может быть на порядки менее эффективной. Тут уже надо смотреть какой подход выгоднее в конкретном случае.
Мне на программу для однокомнатной квартиры, где я реализовал довольно замороченную логику со светом, организовал управление кранами и систему контроля протечек — ресурсов лого хватило. В твоих проектах, наверное, не всегда будет возможно применить мой подход.
P.S. Есть возможность показать какой щит получился у меня, который сделал в основном основываясь на твоём блоге, так сказать интересно что скажет профессионал: говно или имеет право на жизнь :)
MacSergey Не, не! Я хочу придраться к следующему:
а) Дилемма в подходе — с этим я согласен. Скажем, сделали мы универсальный FBD для всех нажатий, ставим их — а используем не всё.
Это нормально. Программа перегружена, но если памяти хватает — то норм. И решение типовое получается.
б) А вот с тем, как ты описал свой подход — я не до конца согласен. Сделать FBD, чтобы их них делать, образно говоря, по месту ещё вложенные FBD — это изврат.
И раньше говорили, что это от неумения программировать. Ну как если бы чуваку надо было вывести поверх WEB-страницы окно — и вместо того чтобы подключить одну библиотеку (типа там jQuery или Node.js), чувак перевёл весь сайт полностью на Ajax, переписал код движка — и благодаря этому смог подключить какую-нить платную хуйню, которая выводит ему это окошко.
А потом оправдывался как «Ну… у меня многофункциональный подход» — это пиздец =)
Доработай свой UDF так, чтобы он один делал всё =)
CS, как раз таки вложенные функции друг в друга это нормальный подход: весь повторяющийся код выносится в отдельные функции. Но у меня как раз нет вложенных функций.
Вот смотри: в варианте что ранее обсуждался в функции используется 11 блоков. Отлично, когда нужны все его функции: одинарное, двойное, тройное и длинное, но если нужно только одно из этого — будет напрасная трата блоков так как они все суммируются из всех функций.
В моем варианте всего 6 блоков используется и плюс к этому он универсальный по количеству нажатий, не нужно будет доробатывать, если понадобится четверное нажатие. Если нужна обработка нескольких типов нажатия, то просто ставится несколько таких блоков со своими параметрами.
Кстати, есть еще фишка, что эти параметры можно тоже динамически передавать и тем самым можно реализовать изменение требуемых количеств нажатия для запуска чего-то.
// Так же есть реализация длинного нажатия, комбинаций нажатий (например длинное, а потом тройное короткое) — если интересно, могу показать
MacSergey, да, интересно. Хотел бы посмотреть.
MaxDesperate Это если он нам покажет. Здесь не форум, такие прыжки через мою голову (владельца ресурса) запрещены.
А был опыт построения управления сценами освещения и одновременно с другого места управление группами независимо? Т.е. одной кнопкой включил\выключил 2 группы. Другой кнопкой вкл.\выкл. одну из этих же групп.
Zoer БУГАГАШЕНЬКИ!!! ЕСТЬ ОПЫТ! =)) Вот: https://cs-cs.net/sh-knx-light-scenarios-owen-mone =))
А вообще смотри посты по тэгу «Logo». Я ещё дописал про визуализацию.
Так я имел ввиду именно на Logo. У меня щит собран, осталось с логикой разобраться.
UPD. Блин, я понял. В топку сцены, на Лого я это не реализую. Нужно было укатывать заказчика на ПЛК.
Zoer УГУ! Или хотя бы на ОВЕН ПР200. Я ща начинаю готовить посты про них, они ОХУЕННЫ (через неделю точно выложу первую часть про железо)!
Там тоже FBD, но настолько продвинутые, что один чувак смог написать там сцены эти!
А, да! И ModBus НОРМАЛЬНЫЙ есть — я за это ваще прям ПРки полюбил!
Доброго времени суток всем хорошим людям.
Очень пондравилась реализация подключения с вентилятором для санузла.
А как можно реализовать схему что-бы вентилятор (или какая либо другая нагрузка) включался на заданный промежуток времени только после выключения света?
DM Ты хочешь совсем готовое решение? Ну, чтобы я нарисовал схему и ты тупо скопировал (это мне не всегда приятно)?
Или ты более-менее разобрался с Logo и знаешь, как та схема из примера работает (ты читал все посты про Logo — предыдущие три части)?
КОНЕЧНО ЖЕ МОЖНО. Я не делал, но сделал бы так:
а) Оставил бы именно эту схему, чтобы юзер мог всё равно врубать или вырубать вентилятор кнопкой.
б) Вот у нас у таймера вентилятора (который его включает) есть вход T — запуск.
Если подать на него ещё откуда-то сигнал (через OR) — то вентилятор тоже включится. Мы этим будем пользоваться как раз ща.
в) Есть ещё херня «Wiping Relay» (пишу на память, уточни). Она делает следующее: если сигнал на вход подаётся постоянно — на выходе превращает его в короткий импульс.
Эта штука нужна для тех случаев, когда нам важно чтобы сигналы запуска или переключения чего-то (короткие) не пересекались. То есть для сигнала «Т» на таймер вентилятора и других мест (ща дорасскажу).
Дальше про это всё временно забываем и делаем отдельную херовину, которая нам вентилятор будет запускать (сигнал на Т подавать).
Тут оставляю на твлю фантазию. Идеи таки:
* Ставим это самое Wiping Relay таким образом, чтобы когда свет погасили (был переход с 1 на 0) — оно выдавало импульс (для этого на вход этого реле подаём инверсный сигнал — при переходе с 0 на 1, когда зажгли свет оно НЕ должно работать, а при переходе с 1 на 0 — должно).
Вот сразу и будет логика: погасили свет = ткнули таймер вентилятора.
* Перед Wiping Relay воткнём таймер On-Delay (выход света — таймер — реле). Тогда можно настроить его на какое-то время и сделать логику «Если свет горел больше чем хх (On-delay досчитал до этого времени) — то когда свет погаснет — выдать импульс на запуск вентилятора».
* Навернуть то же с кучей таймеров и заданием настроек таймера вентилятора (или несколькими таймерами) таким образом, чтобы вентилятор стартовал на разное время. Например, если свет горел больше чем 5 минут — вентилятор старутет с одним временем, если больше 20 минут — с другим.
Вот! Я думал, что это очевидно всё, потому и не стал писать.
CS Я так понимаю что Wiping Relay — это интервальное реле.
Ну просто у меня установлен logo soft comfort на великом и могучем.
У таймера есть вход T, или все-таки Trg? …
В любом случае спасибо за развернутый ответ.
Я понял… что нихера не понял.
DM Гммм.. как это будет на русском — я НЕ в курсе, потому что я таким софтом я работаю на английском, если есть возможность… после того, как я русский перевод Автокада увидел со словами «вырезать», «обрезать», «растянуть», «расчленить», «взорвать» =))
Про таймер — могу путать (пишу ща по памяти, так как дал тебе идею). Возможно и Trg.
Ну чего ты не понял? Начни с малого. Вот можешь ты сделать такой участок схемы, который выдаёт импульс, когда свет в ванной погасили? Вот по выключению света ставим это «интервальное реле», например на 0,5 секунды.
И импульс от этого реле «нажимает» на кнопку запуска вентилятора. Через «ИЛИ», чтобы и сигнал от обычной кнопки тоже проходил нормально.
Смотри. Я тебе нарисовал на базе своего UDF из этого поста (то, что там внутри — тут же в посте ты и увидишь).
а) В правой части стоит U002 и Q4 — это блок управления вентилятором из поста и выход на вентилятор.
б) Вход «Button» этого U002 через «ИЛИ» (OR) подцеплен к кнопке I4, которая управляет вентилятором (чтобы его можно было вручную включить или выключить).
Ещё на этот же вход запуска вентилятора (кнопки) подаётся сигнал с блока «И» B019. Обрати внимание, что один из входов у него инвертирован (точка стоит).
в) Теперь смотрим на цепочку I5 — Q5 — B018. Это и есть то, про что я говорил — что надо добавить. Q5 — это лампы света ванной, от которых ты хочешь вентилятор запускать. I5 — это мне для проверки схемы надо было имитировать включение ламп.
B018 — это то самое Wiping Relay на 0,5 секунды — оно формирует импульс, когда погас свет. Обрати внимание, что вход у него тоже с точкой — инвертирован.
НО! Если щас (без B020) запустить схему — то при первом включении Logo получится так, что свет ванной не горит, и система подумает что свет погас — и врубит вентилятор.
Чтобы этого не было — я сделал ещё один формирователь импульса B020, который ВСЕГДА и ОДИН раз выдаёт импульс при запуске Logo — потому что мы на вход B020 воткнули «1».
Это и есть блокировка от ложного включения вентилятора про старте Logo: пока этот импульс от B020 выдаётся, то импульс включения от B018 пройти до кнопки не может.
Так хоть понятно? =)) Если не ясно — то вон набери мне на телефон, я тебе голосом поясню.
Или лыжи не едут … или ТЗ описал не верно.
Все перепробовал, не контачит так как надо.
Суть задумки была такова.
Работает только Нагрузка 1
При ее выключении должна включаться Нагрузка 2 на заданный отрезок времени (по таймеру, дням или как то еще).
У меня не выходит именно это. Все время получается с ложными срабатываниями (((
DM, элементарно.
Если не нужно отключение нагрузки 2, когда включили нагрузку 1 при работающей 2, то удали связь R у блока B005.
CS, знаю нельзя… прости не сдержался.
Последние комменты подчистил, так как пошло уже не по вопросу и уже вширь.
У меня такое ощущение, что кто-то врёт, говоря про вентилятор. Пример под него я показал, и там не справится только идиот. Тем более, что я всё нарисовал и даже в симуляторе проверил. Изначальному вопросу это соответствует.
Поэтому дальше делаем так (прерывая наглость): если нужна консультация по разработке программы для Logo — то DM пишет мне на мыло с запросом на консультацию и описанием того алгоритма, который должен быть. Без вентиляторов — а про то, что там реально надо сделать.
Я выставляю счёт и после его оплаты работаю.
Wirth Спасибо, да! Но сдаётся мне, что верить тут не надо. И щас тут будут пытать что-то вида «я всё равно не понял, вообще у меня не свет, а привод гидропресса».
CS А вот зря ты так.
Я вот чесно написал
Wirth сам вызвался… никто за… нетянул.
Искал инфу в инете и наткнулся на этот сайт. Вот и решил спросить.
В ветке есть и скрины и обсуждения и комментарии!
По факту только свет в квартире. Гидропресса НЕТ.
Двушка во вторичке.
Так тогда ЧТО тебе не понятно их моих примеров, если я тебе не просто показал, а дал прям готовый и бесплатный ответ? Тебе надо только это всё повторить.
Перечитал эту статью с комментариями и три предыдущие и так и не понял возможно ли все же сделать так, чтобы одна кнопка корректно управляла тремя нагрузками при разных нажатиях (одинарном, двойном и длинном). Тут предлагали два варианта. Первый вариант в третьей части от CS и еще один в начале комментариев этой 4-й части от KOH. В первом варианте некорректно работает однократное нажатие, а во втором — двойное, а после однократного нажатия выход включается не сразу. И почему то нет даже реле для включения выхода.
Может все же кто то знает алгоритм корректной работы с одной кнопки в трех режимах? Или хотя бы в двух: однократной/двойное или однократное/длинное
KO40 Да такое обычно противоречит концепту. Вот на компе с мышью ж всегда одинарное нажатие следует за двойным. И никак от этого не избавиться.
Алгоритмы?.. Хммм! Поискать можно не только для Logo — а для любого ПЛК. Я не морочился, потому что такие извраты исключил как класс сразу же!
KO40 посмотри мой вариант за 29 октября (https://cs-cs.net/logicheskie-rele-siemens-logo-programmirovanie-udf-net-project#comment-38868). В схеме формируются импульсы на включение и отключение, импульсное реле ты можешь добавить сам.
Да, увидел. Но все схемы эти, в т.ч. и ваша, не совсем идеальные. Где то ложные срабатывания, где то срабатывание после отпускания кнопки (неприятно при длительном нажатии).
Пытаюсь создать схемку с включением сразу при нажатии хотя бы на двух комбинациях: одинарной и двойное нажатие или одинарное и длинное. Может кто то уже изобрел такую схему, чтобы красиво, понятно и надежно?
KO40 Чтобы длительное нажатие срабатывало после 1 секунды а не по отпусканию кнопки нужно заменить блок B004 на импульс по переднему фронту а не по заднему. По ложным срабатываниям можно подробней? как не побывал у себя на схеме, все ок.
Если требуется как минимум двойное нажатие, то с технической точки зрения без выдержки не обойтись. здесь ты можешь играться с таймерами.
Если использовать только 2 комбинации, то с точки зрения алгоритма можно реализовать
— только одиночное и двойное нажатие:
одиночно нажатие будет срабатывать с заданной выдержкой, но ее можно уменьшить скажем до 200 мс. двойное нажатие будет отрабатывать сразу, как только нажал 2 раз
— одиночное и длительное нажатие:
одиночное нажатие сработает моментально когда отпустил кнопку. длительное нажатие отработает как только пройдет выдержка длительного нажатия, ее задаешь сам. это может быть и 100 мс и 1с.
Готовых схем, которые тебя удовлетворят, скорее всего не будет. каждый делает либо для себя, либо для заказчика. На вкус и цвет все фломастеры разные.
Спасибо, разобрался. все хорошо, немного доработал.
Задачи были такие
1. Это кухня и лоджия.
2. В кухне две кнопки. Нужно чтобы с одной кнопки по простому однократному нажатию управлялся свет над столешницей, а с другой — по однократному нажатию управлялся основной свет.
3. Освещение лоджии должно управляться с кнопки на самой лоджии. И дополнительно хотелось бы, чтобы он управлялся с кнопки в кухне (если дверь на лоджию закрыл, а свет забыл выключить). Сделал управление светом в лоджии дополнительно по двойному нажатию кнопки основного света.
4. Нужно, чтобы обе группы света гасились в кухне при длительном нажатии на любую клавишу в кухне.
5. Нужно, чтобы все освещение гасилось при нажатии основного мастер-выключателя квартиры (на схеме его не сделал, чтобы не загружать схему), но входы под эту мастер-кнопку запланированы на блоках В46, В49 и ресет на В30.
Все нравится, кроме одного. Управление основным светом происходит с задержкой (сейчас 100 мсек.).
Знатоки, есть способ убрать или существенно сократить такую задержку на основной свет?
KO40
Убрать задержку при двойном тройном и т.д. нажатиях логически не возможно.
Программа же не знает сколько раз ты нажмешь кнопку, по этому она выжидает эту задержку, и если ты не нажал еще раз, выполняет действия по текущему количеству нажатий.
Как я писал выше, без задержки возможен только вариант, когда используется одинарное и длинное нажатие.
Для удобства создай блок UDF(смотри картинки) который обрабатывает нажатия и дает импульс на выхода одиночного и долгого нажатия, здесь же ты можешь задать выдержку, по которой будет определяться долгое нажатие. У меня стоит 500 мс.
На второй картинке пример программы. Но так как пришлось отказаться от задержки на включение, управление светом на лоджии реализовано на 2 кнопке в кухне при длительном нажатии.
Если выключение света на кухне необходимо с обоих кнопок при длительном нажатии, то можно подвязать к одной из кнопок отключение не только кухни но и лоджии.
Если такой вариант тоже не подходит, то с текущем количеством объектов и субъектов управления, при условии отсутствия задержки управления, задача не имеет решения. Нужно за»;%рить еще одну кнопку =)
Пытаюсь самостоятельно разобраться с программированием функциональными блоками и перерыл уже достаточно много инфы. В чем смысл использования МАРКЕРА?
Единственное, что приходит в голову, что его состояние можно как-то считывать из какого-то другого функционального блока, но в своем простеньком контроллере от EKF я пока не смог такого найти.
В лестничных схемах у реле (М) вроде как есть катушка и контакт — тут все понятно. Но в функциональных блоках у меня ступор.
NikitaDA А ты все посты про Logo перечитал у меня, или только этот комментишь? И как так инфа про EKF может быть связана с Logo? Это ж разные системы, и назначение маркеров у них разное.