Программируемое реле ОВЕН ПР200 с тестовой программой
Я продолжаю цикл постов про логические (программируемые) реле ПР от ОВЕНа. Напоминаю, что всё, что к этим реле относится (в том числе и предыдущая часть поста), доступно по тэгу «ПРххх».
Сегодня весь пост будет посвящён не программированию разных примеров, как было в Logo, а самой среде OWEN Logic. Потому что (как я уже в первой части упоминал), ОВЕН сделал её по мотивам CodeSys. А что это значит?
А то, что тут есть дофига разных настроек, фишек и куча параметров самого реле и проекта! Вот с ними мы сегодня поразбираемся, а потом создадим себе макрос (UDF) для импульсного реле, который заюзаем в третьей части поста!
Содержание
- 1. Среда OWEN Logic. Особенности и принципы её использования. Как подключать ПРки?
- 2. Настройки прибора (реле) в OWEN Logic: IO, ModBus-слоты.
- 3. Что умеет OWEN Logic (функции, операции)?
- 4. Переменные в OWEN Logic: их типы и таблицы (локальные и ModBus).
- 5. Экраны (для ПРок с дисплеем) и работа с ними. Менеджер экранов.
- 6. Менеджер компонентов. Загружаем компоненты и ModBus-модули от ОВЕНа!
- 7. Макросы (аналог UDF в Logo). Сразу же делаем своё импульсное реле!
1. Среда OWEN Logic. Особенности и принципы её использования. Как подключать ПРки?
Общий концепт программирования в OWEN Logic, конечно же, основан на языке FBD — вы при помощи разных блоков чертите схему, и она начинает у вас работать. Изначально текстовх языков программирования в OWEN Logic не было, но и не должно быть, так как сам продукт, под который заточена эта среда и называется «программируемое реле» — по определению простая штука. Хотя по фичам ПРки от ОВЕНа могут заткнуть за пояс и небольшие ПЛК! Однако с 2021 года в OWEN Logic постепенно внедряют текстовый язык ST. Про это мы поговорим в посте про реле ПР103, когда я получу его образцы.
Вот те главные фичи, которые я бы выделил (про них сегодня и будет разговор):
- Есть нормальные типы значений — Булевый (Bool), Целый (Integer), С плавающей точкой (Float). Поддерживается ещё и преобразование типов друг в друга. У Logo этого НЕ было, а были только два типа — Digital (булевый) и Analog (знаковый с плавающей точкой).
При этом ебучий Analog был знаковый, и задачка вида «выдать на устройство число 20, если вход активен и 1 если вход не активен» превращалась в тьму срани, потому что половину всего надо было переводить в тип Analog. - Есть переменные и константы, как в проектах для ПЛК. Всех трёх типов. Поэтому программировать тут — удовольствие! Вы можете обсчитать какой-то результат, сохранить его в переменную, а потом эту переменную использовать в других местах проекта — вам не надо всё «соединять» линиями, как в Logo было. А если есть константы — то можно вытащить их на краешек листа схемы и задавать какие-то системные настройки проекта (время длинных нажатий на кнопки например).
- Есть МАТЕМАТИКА (и целочисленная и с плавающей точкой), сравнение и мультиплексирование! Урааа!!! Есть деление, умножение, сложение, вычитание, даже возведение в степень! Переменные можно сравнить на «равно» или «больше», а при помощи мультиплексора можно выдать на выход одно из двух значений (от других переменных или констант), которое выбирается через блок SEL (или fSEL для значений с плавающей точкой) в зависимости от значения входной переменной (True/False).
- Есть работа с битами: сдвиг, чтение, запись, распаковка, запаковка. То есть можно прочитать WORD по ModBus от модуля дискретных входов (МВ110-224.16Д/ДН — вот пост про модули ввода-вывода от ОВЕН), разобрать его на биты и привязать эти биты к каким-нить входам кнопок.
- Да-а-а-а! Есть НОРМАЛЬНАЯ работа с ModBus по RS-485! Нормальная — это значит то, что можно гонять пачками данные каждые 10 мсек (а не 80 и только по одной переменной, как у Logo) на скорости 115200 и не париться. Нормальная — это значит, что тут доступны флаги состояния устройства на шине (есть связь или устройство не отвечает), доступны все функции чтения и записи переменных (Read/Write Register/Coil), есть нормальная работа с битами, можно переставлять порядок байт для передачи Float…
- Есть удобная работа с экраном в ПР200 (и будущих реле с экраном). Экраны поддерживают вывод и редактирование данных, можно переключаться с экрана на экран по разным событиям (кнопками или по изменению переменных). Редактирование делается «на месте»: если на экран выводится булевая переменная с заданным текстом «Авто»/»Ручн.», то и редактироваться она будет в виде этих же слов, а не внутренних значений или ещё какой-то херни.
- Есть специальная задержка на один цикл программы! ААААА!!! Это то, чего в Logo решается через ёбаные чёртовы маркеры — когда сигнал с выхода какого-то блока надо подать на его же вход! Тут такая связь выхода со входом делается штатно, на уровне железа.
Я проспойлерю, но с такой задержкой можно охуенно решать гонки во времени — например, когда подаются одновременно сигналы Store и Reset, и Store должен пройти чуточку быстрее, чем Reset! В Logo это делалось таймерами или маркерами, а тут — просто чертишь схему так же, как и чертил бы. Без лишней траты элементов схемы! - Библиотека компонентов, которую развивает и пополняет ОВЕН на основании разработок пользователей. OWEN Logic коннектится на сайт (FTP) ОВЕНа, предлагает выбрать разные компоненты (UDF-макросы) и быстренько подгрузить их в проект! То есть, в этом мире вы не одни — если вы хотите изобретать велосипед, то гляньте в библиотеке — вдруг кто-то уже сделал!
- Есть такая фишка, как плагины. Один из них — это мастер тиражирования. Это удобная штука для потокового производства: вместо того, чтобы давать на производство исходник программы (проект OWEN Logic), вы из своего проекта создаёте один EXE-файл, который им и даёте. Файл умеет только запускаться и заливать программу в реле. Таким образом ваш проект налево не уйдёт, а в промке это бывает важно.
Но тем, кто пересаживается с Logo или других реле, будет немного плохо. Из-за того, что тут всё как в CodeSys — есть математика, ModBus, триггеры, самые простые таймеры, PID-регулятор — и всё. Все остальные вещи (импульсные реле, таймеры с остановкой по сигналу, лестничные реле для освещения), которые были в Logo готовенькие, тут надо писать самому. Да даже например «OR» на пять входов — и тот надо будет создавать ручками (или пихать OR каскадом). Зато вы можете отрисовать его именно на 5 входов, а не трахаться с Logoвскими четырьмя.
Я легко принял это, потому что делал так же в CodeSys. Сначала на это ругаешься («Как так нет импульсного реле?!»), а потом понимаешь, что и правильно что нет — потому что это реле удобнее написать с нуля СРАЗУ с нужными для тебя функциями (сохранение предыдущего состояния и восстановление его), чем дорабатывать уже написанное. Вон, как я в CodeSys 2.3 сделал:
Пример написанного самостоятельно продвинутого импульсного реле в CodeSys v2.3
В остальном OWEN Logic вас не удивит — тут есть всё, что надо — загрузка программы в реле, симулятор, проверка программы на ошибки (классная причём!), указатели занятой памяти по программе, переменным и Retain. Ну разве что обратно из реле считать программу нельзя (и это тоже хорошая защита от воров) — только загрузить в реле.
Основной минус OWEN Logic в том, что среда эта сложная в плане кучи режимов, окон, опций и фишек — и ОВЕН не всегда успевает быстро отслеживать и исправлять баги. Баги тут есть, но они относятся именно к интерфейсу OWEN Logic — у кого-то при определённом разрешении экрана где-то не вмещается текст, где-то не помещается окошко или не так работает перетаскивание или копирование чего-то. Все такие баги ОВЕН обсуждает у себя на форуме, набирает их список (я тоже набросил несколько правок и пожеланий), проверяет — и потом выпускает обновлённую версию программы.
Шаги создания проекта я бы выделил бы такие (если у вас есть немного опыта и вы знаете, что настраивать):
- Настроить подключение к прибору (если там что-то поменялось);
- Создать новый проект под наше реле (прибор). Возможно, обновить прошивку реле, если OWEN Logic это предложит сделать;
- Пробежаться по настройкам реле в проекте (дисплей, входы, выходы, ModBus);
- Поискать и создать все макросы, которые могут понадобиться в проекте;
- Создать переменные (примерно, какие могут понадобиться);
- …и вот тогда уже рисовать схему!
Поехали разбираться со всем этим детально! Запускаем OWEN Logic и видим пустой экран:
Главное окно среды разработки OWEN Logic без загруженного проекта
Будьте внимательны! Когда OWEN Logic запускается, она сразу же пытается подключиться к прибору и ждёт некоторое время, ничего не делая (при этом пункты меню доступны для выбора). Если вы запустили её просто так, без подключенного к компу прибора, то дайте ей подождать и выдать ошибку подключения — а после этого спокойно работайте.
Любая ПРка (которая тут называется «прибор»), которая подключается к компу через USB-шнурок, видится на компе как COM-порт (на всякий случай напоминаю свой пост про изменение нумерации COM-портов в винде — он до сих пор актуален). Чтобы OWEN Logic её видела, первое, с чего надо начать (если у вас есть живая ПРка и вы делаете проект для неё) — это с настроек связи.
Лезем в меню «Прибор -> Настройка порта…» и в диалоге выбираем настройки для последовательного пора — нужны COM-порт от USB-подключения ПРки. Все остальные параметры оставьте по умолчанию (9600, 8, N, 1, адрес = 16):
Команда меню и окно настроек подключения к ПРкам (USB/COM-порта)
Ещё есть возможность подключиться к ПРКе по TCP/IP. Это относится к тем случаям, когда ПРка имеет те коммуникационные модули для Ethernet/WiFi, про которые я упоминал в посте про аппаратную часть.
Параметры подключения настраиваются один раз после установки программы (или если вы чего-то меняли в драйверах и COM-портах), а потом сюда больше лазить не надо.
Создаём новый проект:
Меню создания нового проекта в OWEN Logic
Нам предлагают выбрать модель реле, под которую мы будем создавать программу-схему. Моделей дофига (и в будущем могут появиться другие модели ПРок), поэтому тут есть фильтр по тексту в верхней строке. Если туда чего-то написать, то список фильтруется по части этого слова.
Окно выбора модели устройства для проекта OWEN Logic
Если вы случайно выбрали что-то не то (или вам надо переделать проект с одной ПРки на ПРку другого типа), то вы можете поменять модель при помощи команды «Файл -> Смена целевой платформы».
Команда меню для изменения модели устройства, под которую сделан проект OWEN Logic
Откроется то же самое окно для выбора модели реле. Но теперь доступны в нём будут те модели, которые совпадают по количеству встроенного IO. То есть, переехать из проекта с 8I и 8Q на проект с 4I и 4Q не получится!
После того, как мы выбрали модель реле, у нас появляется окно с полем для рисования нашей схемы-програмы и заполняется список доступных блоков для создания схемы.
Окно среды разработки OWEN Logic со свежесозданным проектом
2. Настройки прибора (реле) в OWEN Logic: IO, ModBus-слоты.
Прежде, чем что-то рисовать, давайте залезем в настройки нашего реле и посмотрим, что там есть. Делается это через меню «Прибор, в котором — если проект открыт — доступно дофига разных пунктов.
Команды меню для работы с прибором (настройки и запись программы)
Здесь есть команда для записи программы в реле (напоминаю, что считать её оттуда никак и ничем нельзя), можно обновить прошивку самого реле (если среда видит, что в реле прошивка старая — то она автоматически предлагает её обновить, когда к нему подключается).
Также можно глянуть информацию про само реле, к которому мы подключились — версия прошивки и железа и версия проекта, который в неё залит. Версию проекта мы задаём ручками сами для себя в меню «Файл -> Сведения о проекте», и вот эта версия и выводится в информации о реле. Нужно это для нас самих, чтобы вспомнить, какую версию какой-нибудь программы мы вливали в реле и надо ли её обновить.
Вообще, меня прикалывает это всё у ОВЕНа — так получается, что тут сразу всё заточено на злую промку: программу считать нельзя (ибо копирайты), зато версию можно посмотреть. То есть нас толкают в ту же степь, как если бы мы пользовались какой-нибудь железкой, смотрели её версию прошивки и скачивали свежую версию с сайта производителя (с Мастером Тиражирования такое для ПРок возможно).
Все настройки реле выводятся в одном окне. Слева в дереве можно выбрать группу настроек, а справа — их параметры. Само дерево настроек нужно для того, чтобы можно было наглядно добавлять устройства ModBus и модули расширения.
Окно настроек прибора в OWEN Logic (настройки экрана)
Всякие обычные настройки типа часов и экрана (я пишу на ПР200 — так же интереснее вам про экраны рассказать) простые и тут ничего интересного нету. Я оставляю всегда включенную подсветку экрана, а часы реального времени в реле выставляю по часам компьютера.
Самое крутое, куда я стремился попасть, был ModBus (про него я расскажу в третьей части поста; в этой я покажу только то, что к шаблонам устройств относится). Тут есть всёёё! Можно добавить до двух слотов ModBus (вы помните, физически в ПРках может быть до двух ModBus), задать им режим работы (Master-Slave) и параметры связи. В дереве можно будет добавлять устройства ModBus и настраивать переменные для них.
Окно настроек прибора в OWEN Logic (настройки интерфейса ModBus)
Ради прикола я добавил пару слотов, один из которых Master, а другой — Slave. Вот в чём круть ПРок и концепта с переменными внутри OWEN Logic! Переменная внутри ПРки может просто всегда висеть в значении «134» — и она будет совершенно спокойно отдаваться по ModBus Slave на какую-нить панель оператора или «старший» ПЛК. Вообще круть!
В Logo есть огрызок работы с переменными — они там называются VM — Variable Memory. Но там работать с ними надо мутно — считать адреса по табличкам и подстраивать ModBus под них, а не наоборот.
Если наше реле имеет аналоговые входы и/или выходы, то для них нам тоже надо всё настраивать. Не забываем, что для ПР200 перемычки на плате и настройка входа в параметрах реле должны совпадать (правда, если они не будут совпадать, OWEN Logic заругается).
Окно настроек прибора в OWEN Logic (настройки аналоговых входов)
Если вы новичок в аналоговых входах (вот здесь вы можете прочитать большой пост про аналоговые входы и выходы), то я быстро расскажу о том, как работает и настраивается аналоговый вход. Сам прибор (или модуль ввода) никогда не знает и не понимает о том, что именно подключено на аналоговый вход. И ему, признаться, на это наплевать — так специально задумано.
АЦП в модуле ввода или в реле считывает напряжение или ток, а потом приводит их к обычному числу с нужной точностью. Например 4 мА (низ предела измерения) будет равно числу 0, а 20 мА (верх предела измерения) будет равно числу 10 000. А что дальше? А вот дальше только вы сами знаете, что именно вы меряете и как это должно выглядеть для вас.
Поэтому-то вам и надо задать числа, которые помогут привести те значения, которые намерил АЦП, к удобному для вас виду — верхнюю и нижнюю границу измерений. Вот там-то вы и можете сказать, что на самом деле ваши 4..20мА — это от 0 до 6 атмосфер давления! И математика измерений пересчитает всё таким образом, что в конце концов вы будете получать результат, намерянный по этому входу, именно в атмосферах, а не в чём-то ещё. Подробнее про это было рассказано в посте про аналоговые сигналы, ссылку на который я приводил выше.
И вот после того, как мы настроили наше реле (чтобы туда больше не возвращаться), мы можем начать разбираться с главным окном OWEN Logic.
Окно среды разработки OWEN Logic с пустым проектом после всех настроек
Вот какие элементы окна у нас есть (или могут быть):
- Посередине окна есть поле для нашей программы. Размеры поля можно увеличивать и уменьшать по своему желанию, а заранее расставленные значки входов и выходов — двигать по своему усмотрению так, чтобы всё было наглядно для вас и тех, кто после вас будет разбираться в проекте.
- Сверху есть панель инструментов, на которой есть очень важные кнопки (справа) работы с переменными и преобразованием типов значений. Тут можно вставить переменную (обычную, сетевую, из функционального блока), константу и обратную связь (задержку на один цикл программы).
- Справа есть списки всех доступных компонентов, функций и макросов проекта. Нужные элементы перетаскиваются на поле в схему.
- Справа снизу находится окно свойств того элемента, который выбран на поле для схемы — само поле (тут-то и можно его размеры подстроить), какая-нибудь переменная, функциональный блок, экран, группа экранов, и тому подобное.
- Слева есть окно доступных переменных проекта (всех-всех, в том числе и ModBus). Оно нужно для того, чтобы можно было быстренько перетащить её в проект и куда-то вставить, а не выбирать элемент «Переменная», а потом задавать там нужную переменную (без клавиши Shift переменная перетаскивается как входная, а с Shift — как выходная). Ну и ещё оно помогает не забыть о том, какие переменные у вас есть и где они используются (если выбрать переменную, то снизу выводится список ссылок на неё).
- Ещё слева хитро спряталось окно списка экранов. Оно появляется, если вы делаете проект на реле с дисплеем (пока это ПР200, но ходят слухи, что линейка будет расширяться вплоть до сенсорных). В этом окне можно создавать экраны (сообщения на физическом дисплее), их группы и условия того, как эти экраны будут между собой переключаться (по событиям, переменным или кнопкам).
- В самом низу есть строка состояния, которая показывает то, сколько памяти занимает наша программа и переменные.
3. Что умеет OWEN Logic (функции, операции)?
Хммм! По идее, тут-то и должны быть все плюшки OWEN Logic, которые я радостно расписал в начале поста — про переменные, математику, преобразование типов ;) Расписать-то расписал, но не показал списков всех операций и функций. Вот сейчас мы по ним и пробежимся, в виде краткой сводки.
Начинаем со списка операций — того, что можно делать с разными значениями, входами, выходами и переменными:
Список доступных операций (функций) над переменными в OWEN Logic
Выделю то, на что стоит обратить внимание:
- Некоторые функции есть и для целочисленного и для типа данных с плавающей точкой. Они абсолютно одинаковы, только у тех, которые используют тип с плавающей точкой, есть приставка «f» — fMUL, fPOW, fGT.
- Все базовые операции (И, ИЛИ, исключающее ИЛИ) расчитаны только на два операнда. Если вам надо больше входов — то вы включаете их каскадом или, если вам часто нужна какая-то операция на, к примеру, 8 входов, делаете макрос.
- Есть обычная математика: сложение ADD, вычитание SUB, умножение MUL, деление DIV, деление с остатком MOD. Вон Кирич уже зубы точит. «Я», — говорит, — «Буду импульсы от счётчиков воды дома считать Retain-счётчиками». А я ему: «А вот как раз потом к этим насчитанным импульсам прибавишь начальные значения цифр на счётчиках через ADD — и получишь реальные показания счётчика». Кстати, по Modbus потом эти показания можно вывести на ОВЕНские индикаторные дисплеи СМИ-2М (пост про них), которые могут менять цвет и мигание в зависимости от величины показания.
- Отдельно напишу, что для float есть операция возведения в степень fPOW. Это ОЧЕНЬ важно, потому что она используется в тех случаях, когда мы получаем не готовое значение с плавающей точкой, а значение без точки и положение точки отдельно (10 в степени хх), например с модуля аналоговых вводов (ссылка на пост про модули ввода-вывода):
Таблица регистров ModBus для первого входа модуля МВ110-8А
- Работа с битами: чтение бита EXTRACT, запись бита PUTBIT, шифратор CD32 и дешифратор DC32, сдвиги влево SHL и вправо SHR (сдвиговые регистры). Всё это очень удобно для работы с разными флагами — иногда из ModBus-устройств, иногда внутри своей же программы.
Иногда такое обожают мутить в преобразователях частоты в виде инструкций «третий и четвёртый биты 17го регистра отвечают за режим плавного старта двигателя». И поди думай, как их оттуда выделить. - И, наконец, операции сравнения и выбора значений. Можно просто сравнить два значения EQ (например, равен ли статус ошибки нулю — значит ошибок нет, не равен — есть ошибки), можно сравнить на то, больше значение или нет GT — скажем, для какого-то регулирования температуры или ещё чего-то. А ещё можно выбрать какое-то из двух значений по булевому SEL: если булево равно нулю, то на выходе будет одно значение, а если единице — то другое.
При этом выбор может идти из любых других значений, не только чисел: входов реле, выходов каких-то блоков, переменных ModBus, констант… ну например, по тому же примеру флага статуса ошибки через SEL можно выдать 0, если была ошибка, или измеренное значение, если ошибки измерения не было.
И всё это — для типов Int/Float, твою мать!! В Logo этого не было! Если тебе надо было выдать какое-то значение, то надо было брать аналоговый мультиплексор и ебаться с тем, чтобы знаковое аналоговое значение с плавающей точкой привести к числу «45083», которое тебе и надо выдать. Меня это дико бесило!
Надо ли говорить, что с таким жирным списком операций тут можно намутить гораздо больше, чем на Logo? И что один камрад смог сделать на этом реле сценарное управление светом, которое на Logo сделать не получается! Вон он какой модуль разработал! Аж с настройками групп — какая группа в каком сценарии будет работать (чтением битов как раз).
Пример адски крутого макроса на управление светом по сценариям на OWEN Logic
Идём далее! Теперь разберёмся с тем, какие функциональные блоки нам тут доступны и что на них можно сделать:
Список доступных функциональных блоков в OWEN Logic
- Самые базовые триггеры: RS, SR.
- Детекторы фронтов сигналов: RTRIG, FTRIG.
- Самый главный триггер всех и всея — D-триггер.
- Самые базовые таймеры: задержка включения TON, задержка выключения TOF, формирователь импульса TP, мигалка BLINK.
- Счётчики импульсов CT, CTU, CTN, интервальный таймер CLOCK и недельный CLOCK WEEK.
- А на закуску блок PID-регулятора, который нужен для регулировки температуры или других параметров. Однако не забывайте, что такой реулятор может довольно часто включать и выключать нагрузку, и поэтому релюшки или контакторы к нему не подходят — он их защёлкает до смерти. Тут нужны твердотельные реле или другой способ регулирования (дискретное с гистерезисом)!
Что я там говорил про CodeSys? Вот вам скриншот самых стандартных функциональных блоков в CodeSys v 2.3 (в 3.5 они такие же, но тут нагляднее):
Самые базовые функциональные блок CodeSys (из стандартной библиотеки)
Тут даже BLINK нету, кстати! И вот если народ на этом пишет всё остальное — то, значится, и в ПРках тоже можно будет всё это понаписать! Так что можно ещё раз постебаться, что ПРки — это CodeSys в миниатюре, но с приличным функционалом и математикой! Я рад!
4. Переменные в OWEN Logic: их типы и таблицы (локальные и ModBus).
Как я уже раза два писал, переменные в OWEN Logic — это самый главный жЫр, благодаря которому программирование становится и наглядным, и удобным и техничным.
В Siemens Logo и других логических реле понятия переменных почти что нету, и там люди оперируют сигналами: соединили блоки между собой линиями и что-то куда-то передали. Там это можно было называть сигналом, и из-за этого у меня возникала куча логических непоняток. Например, вместо переменной «Время», которую я могу через SEL выбирать и запихивать в таймер, в Logo были извраты с параметрами этих таймеров, которые могли подставляться только из определённого блока или места — и никаких вариаций больше нет.
Поэтому ОВЕНу за переменные ставим памятник, ибо логика работы с переменными тут похожа на обычные языки программирования: переменные можно хранить в памяти прибора (Retain), использовать в разных местах программы, получать и записывать в разные устройства или фунциональные блоки.
Например, у нас есть переменная «время работы вентилятора». Вот что мы с ней можем сделать (одновременно):
- Вывести на экран ПРки для просмотра или изменения;
- Объявить как Retain, чтобы значение переменной сохранялось на тот момент, пока на реле не подаётся питание;
- Записать эту переменную в таймер, который управляет у нас вентилятором;
- Одать её по каналу ModBus на какую-нибудь вентиляционную установку.
И это всё будет гораздо нагляднее, чем всякие линии соединений в Logo!
Переменные в OWEN Logic бывают такие (сами имена переменных можно давать любые, даже на русском языке):
- Локальные (Стандартные). Это переменные, которые мы создали для нашего проекта и которые не относятся ко всяким внешним устройствам (ModBus). Имена переменных в пределах этого списка должны не повторяться.
- Системные. Это переменные, которые относятся к самому реле. Чаще всего это часы реального времени и дата.
- Сетевые. Это переменные, которые относятся к устройстам ModBus (их регистры). Переменные НЕ должны повторяться в пределах одного устройства ModBus. При этом в самом проекте может быть куча одинаковых устройств ModBus, внутри каждого из которых есть переменная, которая называется одинаково, и это не будет ошибкой. Когда вы выбираете сетевую переменную, OWEN Logic заставляет вас выбрать устройство, а потом переменную — вот путаницы и нету.
- Чтение-Запись из ФБ. Отнесу это к переменным, хотя это больше подходит к функциям. В некоторые функциональные блоки (счётчики, таймеры) можно записывать значения или считывать их из них. Например, в таймер можно записать значение уставки времени, чтобы менять её в зависимости от условий программы.
Локальные переменные удобно редактировать через штатное окно, а переменные ModBus удобнее редактировать в «Настройках прибора», а в окне только просматривать или выбирать.
Лезем в меню «Прибор -> Таблица переменных»:
Меню открытия таблицы переменных проекта OWEN Logic
И первым делом видим локальные переменные нашего проекта. Список переменных можно фильтровать по каким-то словам, вбив их в верхнее поле. Переменную можно добавлять или удалять, выбирать тип и ставить флаг Retain.
Таблица переменных OWEN Logic (локальные переменные)
Справа этого окна есть вкладки, при помощи которых можно выбирать тип переменных, которые мы будем просматривать. Вот системные переменные, в которых ничего интересного, кроме даты-времени нету:
Таблица переменных OWEN Logic (системные переменные)
А вот список переменных ModBus, причём для конкретного устройства — RGBW-диммера DDL24. В этом списке переменные тоже можно добавлять и удалять, но ещё раз повторюсь, что удобнее это делать именно в настройках ModBus, так как там есть больше параметров для каждой переменной, которые важны.
Таблица переменных OWEN Logic (переменные одного из устройств ModBus)
Всё, что относится к работе с переменными и их типами, показано на скриншоте ниже (кнопки на панели инструментов как раз добавляют показанные элементы):
То, как переменные и преобразования типов выглядят в OWEN Logic
Мы можем преобразовать переменную к разным типам. Это иногда надо, если по ModBus мы читаем целое, а потом нам надо его поделить на что-то и получить результат типа с плавающей точкой. Тогда нам удобно преобразовать целое к плавающей точке и потом сделать fDIV для них.
Можем задать какую-нибудь константу (константа может быть всех трёх типов), ну и использовать локальные, сетевые переменные для чтения и записи. Локальные и сетевые переменные хоть и обозначаются разными значками, полностью одинаковы внутри одного проекта. То есть, если вам надо вытащить сетевую переменную на дисплей — то вы это делаете напрямую, сразу же.
5. Экраны (для ПРок с дисплеем) и работа с ними. Менеджер экранов.
Теперь будем разбираться с менеджером экранов, которые будут выводиться на дисплее ПР200 (на момент создания поста есть только такое реле). Работа с экранами имеет такую логику и концепты:
- Экранов можно создавать несколько штук для разных задач и условий.
- На каждый экран можно выводить статичный текст, переменные (и разрешать их изменение или нет), выбор значения из списка заданных (например «Авто», «Авто в морозы», «Ручное», «Запретить»).
- Экран может содержать несколько строк, которые можно прокручивать вверх или вниз. И всё это будет один экран!
- Можно настраивать условия, по которым будет делаться переход между экранами: по нажатию кнопок на реле, по изменению переменных внутри проекта.
В Logo у нас были просто некие «Сообщения», которых было много штук и которые мы могли только или показывать или скрывать по True/False для каждого сообщения. Вот так они редактировались (ссылка на пост про Logo):
Выводим сообщения в Logo: редактор блока сообщения
На Logo мы не всегда могли менять значения переменных или делать прокрутку экрана, а здесь это возможно.
С сообщениями в Logo была жопа ещё и в том, что между ними было сложно переключаться. Скажем, у нас должны были быть сообщения вида «Запуск генератора», потом «Генератор запускается», «Генератор работает». Это были три экрана, каждый из которых можно было только включить через True/False. Надо было мутить дополнительный огрызок схемы, который управлял бы этими экранами, примерно так:
Пример неудобной работы с экранами в Siemens Logo: на каждый экран делается своя схема, которая должна его выводить
У ОВЕНа же всё можно сделать ещё проще: во-первых, экраны можно завязать между собой в цепочку. А во-вторых, как я говорил, привязать переходы по экранам к переменным. Например, есть у нас три переменных «Stop», «Starting», «Started» и мы делаем логику работы экранов именно по ним — без извратов.
Всё управление экранами прячется в окошке, название которого торчит ярлычком слева окна OWEN Logic — «Менеджер экранов». Если нажать на него, то окно раскрывается:
Экраны OWEN Logic (для ПР200) и окно управления ими
При помощи менеджера экранов мы можем насоздавать нужные нам экраны (или скопировать текущий) и открыть их для редактирований. Группа экранов нужна для того, чтобы можно было задать условия перехода между экранами, про которые я рассказывал.
Открываем самый первый экран для редактирования двойным щелчком на его названии в дереве. Экран редактируется в том же окне, где и программа. Точно так же на экран можно перетащить разные компоненты и задать их свойства.
Вот я вверху экрана сделал текстовую метку (просто текст), а снизу поставил отображение переменной:
Конструирование одного из экранов в OWEN Logic (перетащили поле переменной и задали его свойства)
Если мы выводим переменную, то у неё есть куча интересных свойств, которые зависят от её типа. Можно задать текст для True/False, если она булевая. Можно задать текст до и после (чтобы значение сразу форматировалось в «Давление =» и «bar») и не надо было дописывать это текстом на экране. Можно запретить или разрешить редактирование переменной пользователем.
И конечно же выбрать переменную! Я сделал самое простое, что только можно было сделать! Создал две переменных: bDispTest и fDispTest и воткнул их на экране.
Выбрали переменную для экранного поля в OWEN Logic (для ПР200)
Особенность ПРок в том, что если в проекте есть только один экран, то ПРка сразу же его и будет показывать. Никакой код для этого писать не надо! И вот они — мои переменные:
Наш первый экран на ПР200 уже работает (отображаются две переменные)!
Теперь давайте ещё раз проценим эту фичу! Я ТОЛЬКО лишь создал переменную и сразу же вытащил её на экран, причём разрешил её менять! Для этого никакую схему мне не пришлось чертить!
Если развивать прикол дальше — то из такой ПРки можно сделать лёгкую менялку переменных для какого-нить устройства по ModBus! =)) Берём переменные из ModBus и привязываем их сразу на экран, разрешаем изменение — и всё готово!
Чтобы изменить переменную на экране, надо нажать на реле кнопку «SEL». После этого одна из переменных начинает мигать, и её значение можно менять кнопками «Вверх» и «Вниз». Если переменных на экране много, то кнопка «SEL» перебирает их подряд, чтобы можно было выбрать именно ту, которую мы меняем.
Процесс изменения одной из переменных (Sel + стрелки)
Чтобы сделать экран многострочным (например, длинный список настроек какого-то процесса), надо нажать на кнопку менюшки около строки экрана и выбрать там нужный пункт (добавления или удаления строки):
Добавление строк экрана в OWEN Logic
Вот я замутил экран уже на четыре строки, которые на живой ПРке будут листаться теми же кнопками «Вверх» и «Вниз»:
Экран для реле ПР200, который содержит в себе несколько строк и будет прокручиваться
А вот пролистал его до третьей строки:
Мультистроковый экран в работе (прокрутили его на строку вниз, до третьей)
Итак, сделали вы себе разные экраны. А как теперь между ними переключаться?
Выбираем нашу группу экранов в менеджере и тыкаем пункт меню «Редактировать группу»:
Меню вызова редактора группы экранов в OWEN Logic
И у нас открывается редактор группы экранов. В этом редакторе показываются все экраны, которые входят в группу и их свойства.
Процесс настройки условия, по которым в проекте будут отображаться другие экраны
Вот в свойствах-то и настраиваются условия перехода по экранам. Причём условий перехода может быть несколько штук одновременно (все они работают по «ИЛИ»). Чтобы добавить новый переход — выберите экран, ИЗ которого вы будете куда-то переходить, и нажмите кнопку с тремя точками в списке свойств (показано выше).
У вас откроется окно, в котором можно выбрать новый экран, на который надо перейти и условие для этого перехода:
Задаём одно из условий перехода на другой экран в проекте ПР200
Условием может быть или аппаратная кнопка на реле (есть разные варианты их комбинаций) или булевая переменная, которую можно выбрать. Как только она меняется на True, то мы переходим на указанный экран.
Будьте внимательны, так как если вы прописали переход на какой-то экран, это совсем не означает, что вы потом вернётесь с этого экрана назад на главный! Это тоже надо прописывать ручками, никакие аппаратные кнопки (если они не прописаны) назад вас не вернут. Конечно же, так сделано специально, так как разработчики не знают, как вы будете использовать экраны. Может быть вам надо будет один раз показать экран-заставку, а потом никогда к нему не возвращаться. И тут аппаратные кнопки мешали бы.
Так как условия перехода на разные экраны можно добавлять несколько штук, то я сделал так: по «ALT+Вверх» я перехожу на экран «SubMain», а по «ALT+Вниз» — на экран «Error». Возврат с этих экранов делается по кнопке «ESC».
Все эти переходы отображаются в окне группы экранов линиями:
Схема экранов с переходами между ними по разным условиям (кнопки или переменные)
И вот я это тестирую. Зажал «ALT+Вниз» и получил свой экран аварии:
Тестируем переход: по Alt + Вниз перешли на экран 3 (Авария)
Применять экраны можно как угодно. Скажем, сделать один многострочный главный экран, где будет отображаться основное состояние системы, а в нём сделать булеву переменную «Режим» со значениями False/True, подписанными как «Работа»/»Настройки» и по ней переходить к другому экрану настроек, в котором забахать список меню настроек тоже через переменные. А по этим переменным включать другие экраны. А выход из всей этой вакханалии сделать по клавише Esc.
6. Менеджер компонентов. Загружаем компоненты и ModBus-модули от ОВЕНа!
Сейчас будет ещё одна фишка, за которую ОВЕНу надо ставить ещё один памятник! Это менеджер компонентов! Вызывается он из меню «Файл -> Менеджер компонентов»:
Меню, которое открывает менеджер компонентов в OWEN Logic
И вам открывается настоящий клондайк!
Окноно менеджера компонентов OWEN Logic (подгрузка шаблонов от ОВЕНа)
Менеджер компонентов — это онлайн-база (которая поддерживается и проверяется ОВЕНом), в которой есть много разных макросов для OWEN Logic, в том числе и шаблоны для модулей ввода-вывода серии Mx110 (RS-485). Прежде чем изобретать велосипед, стоит поискать его в этой базе!
База компонентов подгружается с сайта ОВЕНа, поэтому OWEN Logic будет проситься в инет. Можно пустить его один раз (что я и сделал), выбрать всё-всё-всё и загрузить его себе в локальную базу, а потом использовать оттуда.
Процесс выбора и загрузки нужных компонентов в OWEN Logic
Потом из локальной базы можно будет добавлять макросы в наш проект. Выбираем нужное и жмём кнопку «Загрузить в проект». Я себе регулятор с гистерезисом вот загрузил, хочу побаловаться им в тестовом примере.
Выбираем, какие из загруженных компонентов надо добавить в проект
После загрузки макрос этого регулятора появился у меня в списке доступных, и я перетащил его себе в схему-программу:
Наш компонент (из загруженных) добавился в раздел макросов, и мы можем его использовать
И — вуаля! Тот же механизм шаблонов поддерживается и на устройствах ModBus!! Вы заходите в настройки реле, тыркаете на слоте ModBus правой кнопкой и выбираете пункт «Добавить из шаблонов»:
Выбор шаблонов устройств ModBus (загруженных из менеджера компонентов)
У вас открывается окно для выбора файла шаблона (надо перейти в папки «Owen Logic\Library\PR200»). Я выбираю модуль аналоговых вводов:
Выбираем файл модуля аналоговых вводов, чтобы добавить его в шаблон
И он добавляется мне в устройства!
Добавили в интерфейс ModBus модуль аналоговых вводов из шаблонов
Все шаблоны макросов или ModBus-устройств не обязательно подгружать только из онлайн-библиотеки. Вы вообще можете ей не пользоваться, а создать свои компоненты и подгружать их. Или даже просто пользоваться командами сохранения/загрузки макроса в файл, или поступать точно так же с ModBus-устройствами.
Я говорил, что кое-где интерфейс OWEN Logic немного не доработан. Вот, например, нет команды копирования устройства ModBus. И тут сохранение-загрузка шаблонов вас очень выручит.
Любое другое устройство ModBus (своё) можно тоже сохранить как шаблон
Я могу создать себе устройство (например, я сделал LED RGBW-диммер DDL24/DDL04R — вот пост про него), потом сохранить его как шаблон и несколько раз загрузить из шаблона. И я получу несколько его копий без ручного ввода всех переменых. Ну и конечно же, все свои любимые устройства можно себе сохранить как шаблоны и добавлять их в проект по мере надобности!
7. Макросы (аналог UDF в Logo). Сразу же делаем своё импульсное реле!
Помните, что я говорил? Что изначально OWEN Logic голый, как CodeSys! Поэтому, чтобы в следующем посте мне повторить примеры из Siemens Logo на импульсных реле — мне надо его создать! Я решил, что это хороший способ показать то, как в OWEN Logic программируются простые штуки и создаются макросы (которые в Logo звались UDF).
Макросами тут называются созданные нами функциональные блоки. Эти макросы имеют входы и выходы (любого типа, который доступен для переменных — Bool, Integer, Float), могут защищаться паролем (чтобы никто не спёр их внутренние исходники) и иметь параметры (для внутренних таймеров и прочих штук).
В новых версиях OWEN Logic появился текстовый язык ST, на котором гораздо удобнее писать некоторые вычисления (посмотрите этот пост как пример сложного задания, которое на ST легко решается). Пока ST есть только в макросах, но потом можно будет писать на нём и основную программу.
OWEN Logic предполагает, что макрос создаётся прямо внутри текущего проекта, а уже потом, если его надо сохранить отдельно (вне проекта), экспортируется во внешний файл. Ну и также можно загрузить макрос из внешнего файла. В этом случае он импортируется в проект. Также в макрос можно вложить другие маросы. Я знаю, что некоторые разработчики вообще почти весь проект фигачат в один большой макрос и ещё его паролем защищают!
В Logo макросы привязывались к файлам, из которых они подгружались в проект. С одной стороны это было удобно тем, что если ты обновил исходный макрос — то он обновится и в проекте. А с другой стороны это было плохо тем, что вместе с проектом надо было таскать ещё и все макросы. В OWEN Logic такого не будет: все нужные макросы станут частью одного файла проекта, а это удобнее для заказчика — получил файл с программой и пользуйся!
Итак, нам надо создать себе импульсное реле. Помнится, что для первого щита на ПЛК110 и CodeSys v2.3 я искал-искал импульсное реле… и дико тупил, потому совсем забыл книжки про цифровую логику, которые читал в детстве. Знаете, да? Такие книжки про микросхемы 155-ой серии, где рассказвали про всякие счётчики, триггеры, сдвиговые регистры. Так вот что такое импульсное реле, если описать его терминами цифровой логики? Это T-триггер — такой триггер, каждый импульс которого меняет состояние его выхода на противоположное.
Поэтому дальше нам надо найти информацию о том, что такое T-триггер и как его можно сделать. Ща вы будете ржать, потому что T-триггер — это частный случай D-триггера %) D-триггер — это самый навороченный вид триггера (на деле это не так, есть ещё круче — JK), и поэтому он поддерживается многими средами разработки, так как из него можно сделать все остальные виды триггеров (про триггеры можно почитать в Википедии).
Что умеет D-триггер? У него есть обычные для триггеров входы S и R, которые принудительно устанавливают триггер в «1» или в «0». А дальше начинается хитрость: D-триггер имеет вход «D» для сигнала (данных) и вход «C» для сигнала тактирования. Когда на «C» приходит сигнал, то то, что подавалось на вход D, записывается (передаётся) на выход триггера. Магия здесь следующая: если выход D-триггера подать через инвертор на его вход, то получится что по C триггер будет записывать в себя то «0», то «1» попеременно. Вот вам и импульсное реле =)
Итак, идём в меню «Файл -> Создать макрос…» (там же есть команды для импорта-экспорта макроса в файл):
Команда меню для создания макроса в OWEN Logic
Нас спрашивают о том, сколько входов и выходов будет иметь наш макрос:
Окно выбора количества IO-линий для макроса
Если вы уже точно знаете, что будете выдумывать, то можете указать точные значения, и программа создаст вам нужное число входов и выходов. Если потом понадобится добавить входы-выходы, то достаточно щёлкнуть правой кнопкой по полю макроса:
После того, как макрос создан, линии IO тоже можно добавлять
Удаляются входы или выходы ещё проще: выбрали его и нажали «Delete».
После того, как мы создали макрос и нужное число входов и выходов, хорошо бы зайти в его свойства (ткнув на пустое место схемы) и задать ему название и описание для того, чтобы другие люди (или вы сами) вспомнили то, что делает этот макрос. Эти же название и описание будут потом отображаться в списке компонентов, так что не надо ими пренебрегать.
Свойства для того, чтобы изменять размер страницы поля для схемы
Ещё вы можете поменять размер листа со схемой макроса, задав нужные размеры (показаны рамкой на скриншоте выше).
Точно так же надо будет пройтись по входам и выходам макроса и задать им понятные названия и типы переменных (обязательно, так как по умолчанию все входы и выходы имеют тип Bool). Названия входов и выходов могут быть любые. Хорошим стилем именования будет, если их названия будут говорить о том, какие сигналы они принимают или выдают (Set, Reset, Clear, Out, Lamp и так далее).
Задаём свойства выхода нашего макроса (тип и название)
Теперь давайте наконец-то займёмся рисованием схемы нашего импульсного реле. Оно будет у нас совсем простое — вход для кнопки «Trig», вход для сброса «Reset» и выход на лампу «Out».
Перетаскиваем на нашу схему D-триггер (элемент DTRIG):
Перетаскиваем D-триггер в схему будущего макроса
И начинаем его подключать. Сначала самое простое — входы и выходы. В OWEN Logic нет специального режима для того, чтобы рисовать соединения. Вы просто подводите курсор мыши к концу нужного вывода, нажимаете и тянете линию:
Процесс рисования соединений между элементами схемы
Когда соединение уже сделано, вы можете выделить его и перетащить так, как вам удобно.
Нарисованные соединения можно отредактировать и передвинуть
В этом плане OWEN Logic рисует соединения поспокойнее, чем Logo Soft Comfort с его безумием и путаницей. Помните эту жесть?
Среда Logo Soft Comfort хреново рисует соединения - правим
Подключаем I1 на «C» триггера, I2 на «R» триггера, выход триггера «Q» — на Q1. И теперь нам нужно с выхода триггера через инвертор (NOT) завести сигнал на вход триггера «D».
И тут OWEN Logic на нас ругается:
Ошибка: цикличная связь между входами и выходами
Что это за хрень? А всё правильно он ругается! Мы же с вами зациклили триггер напрочь! ПРка будет бесконечно его переключать и зависнет! Правда, до ПРки дело не дойдёт, потому что такую программу нам не дадут никуда записать и пошлют в задницу.
Почему такое будет происходить? Помните старый-старый (но важный) пост о ПЛК и логических реле? Я там писал о том, что ПЛК и логические реле работают в циклах: берутся состояния внешних входов, потом обсчитывается схема, потом это выдаётся на внешние выходы. И так бесконечно в цикле. И вот представьте, что эту схему вы начертили так, что ПЛК/ПР получило команду: «Взять значение с выхода блока, подать его на вход — пересчитать блок — выход блока изменился — пересчитать всё, что относится к выходу блока — взять значение с выхода, подать на вход…» — и всё, аллес!
Что нужно сделать? Нужно каким-то образом разорвать этот бесконечный цикл зависаний. Например, сделать какую-то переменную, в которой мог бы быть промежуточный результат. С выхода записали его в переменную, потом прокрутили цикл, из переменной взяли и подали на вход. В Logo в этой роли у нас выступали маркеры «M (Flag)». Помните, во многих постах про Logo я про эти маркеры постоянно говорю и говорю, что хоть этих маркеров и будет 64 штуки, но они могут легко улететь на разные UDF, проброс кнопок для визуализации и другие задачки.
Так вот в OWEN Logic это знали (стопудово знали!), и решили эту задачу гораздо КРУЧЕ! Это ещё один случай, за который я хочу поставить памятник ОВЕНу! Вместо секса с маркерами и прочей сранью они создали специальный тип соединения в схеме, который называется «Линия задержки» и выбирается кнопкой на панели инструментов:
Злемент задержки для того, чтобы создавать цикличные связи правильно
Если прочертить соединение в схеме этим инструментом, то ПРка как раз-то и просчитает схему так, как мы хотели: «Подсчитай выход, потом погоди, потом подсчитай вход»!
Перечерчиваем этот кусок:
Теперь наша схема сделана правильно, задержка показана пунктиром
И ошибка исчезает — всё хорошо!
Линия задержки — это МЕГА-ВЕЩЬ!! Кроме этого примера с зацикливанием, линия задержки позволяет избавиться от гонок во времени. Помните мой UDF для Logo, который умел управлять светом, сохраняя и восстанавливая его значение? Вот он, посередине:
Мои блоки UDF для управления светом на Logo
Тут у меня есть сигналы «Set»/»Reset» и «Store»/»Restore». Первые принудительно включают или выключают блок, а вторые дают ему команду сохранить или восстановить значение. В чём тут сложность? А в том, что сигналы «Store»/»Restore» всегда должны срабатывать раньше сигнала «Reset», даже если они поданы на вход блока одновременно.
В Logo это приходилось решать коротенькими таймерами, которые давали мне задержку на сигнал Reset, тратили место в памяти и отнимали процессорное время. А вот у ОВЕНа я мог бы просто нарисовать на схеме задержку от входа Reset! ВОТ!!! И никаких дополнительных ресусов и памяти на это не потратилось бы!
Нам осталось проверить наше импульсное реле в работе. Для этого пользуемся встроенным симулятором OWEN Logic. Нажимаем на кнопку симулятора на верхней панели и запускаем его на нижней панели, которая появляется на экране:
Процесс тестирования нашего импульсного реле в симуляторе OWEN Logic
Я всё проверил: D-триггер переключается по I1, выход работает, I2 его принудительно сбрасывает и имеет приоритет выше, чем I1. Всё отлично! Наш макрос готов, и мы закрываем окно его редактирования.
Теперь он доступен для нашего проекта (ну и его можно экспортировать в файл, если мы захотим использовать этот макрос в других проектах).
Наш созданный макрос (импульсное реле) появился в списке доступных
А вот дальше в третьей части мы повторим классические схемы на импульсных реле, сделаем схему для управления вентилятором санузла и побалуемся с ModBus!
Проекту исполнилось 15 лет! Поддержать проект материально, проспонсировать проекты Автора или сделать ему подарок можно на этой странице: "Донаты и Спонсорство, Список Желаний".
Зачод! )
О! Хоть один коммент на два поста )
Блокбастеры гораздо популярнее, чем видеолекции по физике твердого тела.
Посты имхо толковые и очень полезные.
Спасибо! А то получается херня какая-то: выходит, что я вас, коллег, учу за просто так, а денег на этом не зарабатываю.
Но при этом блокбастеры — не совсем моя тема. Хотя сегодня одного прораба я кошмарил, и жёстко. И когда-нить про это будет пост.
А тут ближайший пост будет про мой новый световой пульт. Наверное в ПН.
Серия статей просто отличная. Читаю и учусь.
Там по-моему ошибка есть в
Q1 и Q2 вместо I1 и I2
з.ы.: Не зануда.
santa Гыгыгы!! Пасибо! Этот пост в три ночи писался, вот и глюки! Пофиксил!
CS, если ты, предположим, записал ролик о ПРках и еще один, где происходит срач с прорабом (лучше с матами и мордобоем), во сколько раз второй наберет больше просмотров и комментариев? Раз в десять, как минимум )
Это просто закон жанра, что тут поделать.
loa А! А что? Вчерашний прораб уже выложил этот ролик, который он снимал?
В таком случае я его сдам налоговой за незаконное предпринимательство! =)
Спасибо за обзоры. Толково, компактно и поучительно!! Давно читаю, хороший сайт, специально зарегался, чтоб выразить благодарность! Автор молодец, так держать!!!
acidzone Спасибо! Мне очень приятно!
Спасибо, за весьма информативный пост про ПР200.
Вообще характерная черта твоего блога максимальная информативность и стремление к максимальной профессиональности. Давно отслеживаю твой блог, кое что не нравится в подходе сборки щитов (ориентация на дорогие решения в основном ABB). Но в целом твой талант вникать максимально в суть, писать большие и подробные статьи, делают твой блог по части сборки электрооборудования уникальным и лучшим на просторах рунета.
Тебе однозначно надо подучится излагать схемы щитов как положено по ЕСКД, это только дополнит твой профессионализм да и на сложных проектах без этого уже не обойтись. Сейчас сам посматривая на Eplan (но собака мутный он в управлении).
А так Честь и хвала тебе, за такой большой труд, ми дальнейших успехов в профессионализме!
Yahont7 Не за что! На здоровье пользуйся! Ты подметил верно: у меня основное — это разобраться в самой сути, чтобы по подобию делать свои штучки или идеи. А вы уже их читаете, дорабатываете под себя и делаете на чём вам нравится. Так что тут дело совсем не в модульке, и я это много раз говорил.
По поводу ЕСКД и схем щитов. Тут поспорю, потому что у меня есть охуенно удобный инструмент всё-в-одном, начиная от денежного учёта и кончая аж учётом счётчиков воды и электричества вместе с уплатой налогов и формированием квитанций, налеек, схем щитов и документации (это ты посмотри посты по тэгу CS CRM). Ммм… как же слова подобрать. Короче, это система, в которой я делаю всё: деньги, бухгалтерия, товары, щиты, кабели, чертежи и наклейки с этикетками. И вот только ради того, чтобы рисовать какие-то там чертежи по ЕСКД, я не буду всю систему бросать нахер. А делать двойную работу — то есть в сотню кликов мыши спроектировать (и что важно — быстро поправить и переделать) щит и получить докуму вместе с заказом на материалы и отслеживанем его цен и статуса у поставщика… — и потом отдельно ебаться с чертежами — не хочу.
Блин, да, кратко не вышло пояснить. Попробую совсем кратко. Моя система охуенна тем (самое главное её достоинство), что эти неказистые (но понятные) чертежи, инструкции, списки кабелей, заказы материалов генерируются АВТОМАТИЧЕСКИ, а данные для того, чтобы их сгенерировать, меняются только в ОДНОМ месте. Вот! И если у меня переименовалась линия или добавилась — то вручную я правлю только расстановку модульки (это ж человеческая задача — понять, куда поставить автомат, в какое место щита), а документация, блок-схема щита, заказ материалов, кабель — всё меняется автоматом. Без ручного труда.
И вот этого (чтобы были денежно-товарно-складской учёты, проектирование, генерирование документации, генерирование схем) в других системах я не видел. Все, как полные мудилы, чертят ради того чтобы чертить — чтобы по ЕСКД было. Делать работу ради работы я не согласен. Нахуй мне нужны чертежи ради чертежей, если когда у меня что-то сменится, что мне надо будет открывать ещё другую программу, искать изменения там, менять их, перерисовывать?
У меня получается ща так:
* Основное всё — в CS CRM, включая текстовое ТехЗадание и описание проекта и его решений;
* Схемы сложных узлов (электрические принципиальные) я рисую отдельно там, где это надо. Херовины вида «УЗО => Автомат => Реле => Клемма» отлично читаются по моей блок-схеме.
* И в отдельных прогах я пишу только программы для ПЛК. Но без этого уже никак.
Да я помню твой обзор некой надстройки над 1С, в которой ты все делаешь.
По сути это не надстройка а как ее называют «конфигурация». Впринципе если делать только щиты в основном модульной концепции то конечно сойдет и такой подход. Но, если же делать щиты со сложными схемами, скажем запутанными контакторно-релейными связями, с панелями управления (кнопочки, селекторные переключатели, индикация и т.д.) с теми же ПЛК, а если еще приходится единую сложную схему рассредотачивать на несколько щитов с кабельными связями, то вообще тяжко будет делать это все в какой либо конфигурации 1С.
Я тоже начинал делать щиты без спец. программ причем щиты не модульные а обычные металлические с монтажной панелью, для силовых и прочих распред и учет. щитов все просто, схемку легко накидать а народной sPlan. Но как только пришлось делать щиты КИПа тут я малек увяз с sPlan-ом (пришлось искать пути упрощения как довести свою мысль до третьего лица). Компоновку правда, я предпочитаю делать в SolidWorks. Эта программа позволяет в 3D четко определится с расположением объектов, и оптимально решить какой габарит оболочки подходит под этот щит. Про solid works вообще есть что сказать отдельно, из плюшек:
1. Можно проектировать различные корпусные детали из листовой стали, со сложным и красивым профилем, затем все это заказать на предприятии имеющее лазерную резку, гибку и порошковую покраску. В результате на руки ты получаешь уникальные детали произв. изг. под пространственные детали для твоего щита, которые будут стоить дешевле стандартных от ABB, DKS и прочих.
2. Благодаря пространственной компоновке и возможности делать произвольные сборки, которые активно используют глубину шкафа. Можно делать двууровневые сборки разборные или легко обслуживаемые использую промышл. фурнитуру.
3. Можно проектировать алюминиевые шильды под переднюю панель щита. Это могут быть как отдельные таблички так и панель управления в целом. Потом за небольшие деньги это можно заказать и ты получаешь офигенный дизайн передней панели. Жаль на твоем сайте нельзя разместить фотки некоторых своих работ на этот счет.
Yahont7 Гммм… хочу озлиться. Вот ты реши, не разбираясь, это всё-таки надстройка или конфигурация-то? А если ты не знаешь — то спроси пожалуйста. Не надо профанничать!
Не, SolidWorks — это не мой случай. У меня вон AutoCAD стоит. И ты обсмеёшься — я его запускал последний раз в 2014 году! =) Вот настолько редко мне нужен такой софт.
Шкафы с кастомными деталями и ССА на дверь — это НЕ моя сфера. У меня CombiLine вовсю идёт, а его размеры я все знаю настолько, что ориентир идёт как «Берём шкаф TwinLine, ставим раму на глубину -1, а рейки с клеммами — на -4».
Рабочая ли идея? На вход ПР подать сигнал от датчика движения и соответственно по переднему фронту — включать свет, по заднему — выключать. ОВЕНовские ПР умеют в такое?
З.Ы.: Смысл работы по датчику через вход ПР: в зависимости от времени суток включать разные светильники.
sam2sam Влёгкую из стандартных компонентов (их обозначения пишу жирным).
а) Включать и выключать свет можно при помощи RS-триггера. Причём по разным условиям: на входы S подаём то, по каким условиям должно включиться, а на входы R — выключиться. Через OR.
б) Детектор фронта — R_TRIG (Raise — подъём, фронт), детектор спада — F_TRIG (Fall — спал). Каждый из этих блоков «выдаёт» на выходе «импульс» ровно на один цикл программы ПРки, вне зависимости от того, насколько длинным был входной сигнал.
Вот и получается, что в простом варианте ты после херовины «Время суток» заводишь её выход на R_TRIG (а его на «S» триггера) и на F_TRIG (а его — на «R» триггера), и всё.
Если нужно будет управление светом с кнопки или ещё кого — то ты можешь сделать импульсное реле на основе D-триггера, и его выходы снова дёрнуть через те же R_TRIG/F_TRIG через OR на входы S и R триггера. Тогда кнопка (или включатель) будут работать независимо от херовины «Время суток».
Вопрос, связанный и использованием памяти и, как следствие, производительностью. у ПР очевидно есть ограничение на кол-во FB в программе, а скорее всего ещё и зависимость времени одного цикла в зависимости от кол-ва блоков.
Допустим, у меня есть 8 выходов, которыми я собираюсь управлять по предложенной схеме из двух FB — DTRTIG и NOT. Я могу сделать макрос и вставить его 8 раз в программу, а могу просто 8 раз скопировать эти два FB. Какое будет использование памяти в первом и во втором случае?
Dron9K Ага, очень классный и интересный вопрос, спасибо!
1. У ПРки есть главное отличие от Logo: учитываются, вычисляются и обрабатываются только те части схемы, которые подключены к выходам или сетевым переменным.
То есть, если какой-то выход FB не задействован — то он даже внутри FB вычисляться не будет.
Или если накидать 100500 FB на схему, но не подключать их к выходам — они нигде (в том числе и в свободной памяти ПРки и ДАЖЕ в СИМУЛЯЦИИ) учитываться не будут.
С этим стоит быть внимательнее, чтобы избежать вопросов про «А чё в симуляции что-то не работает» (потому что к выходу не подключил).
2. По сравнению с Logo памяти тут ЗАВАЛИСЬ, а в свежих версиях OwenLogic и ПРок — ещё больше. Что-то типа 16384 FBшек на проект и 32768 переменных.
Память считается без разницы как: и в виде FB и в виде прямых накиданных блоков.
Так что смело делай всё на FBшках без проблем.
3. Время цикла там зависит от колиичества вычисления в общем (все все элементы + все FBшки), и тем, как ты будешь прогать (наприямую через через FB) на это ты не повлияешь.
В общем, смело делай макрос (мои даже сложнее: там ещё входы On, Off, Store, Restore для мастер-кнопки сделаны, и два D-DTRIG стоит, и ещё и энергонезависимые) — всё будет работать, а программа будет выгледять приятнее и лучше.
CS,
Я последний раз программировал на ЕС ЭВМ, там помню что операция сложения работала на один такт процессора быстрее чем вычитание, поэтому программу нужно было строить так, чтобы получать отрицательные значения и потом складывать )
Тут я тоже подсознательно пытаюсь оптимизировать «код»
А зачем нужны стор-рестор?
Dron9K Всё ОК! Оптимизировать НАСТОЛЬКО ничего не надо — всё будет работать без проблем!
Вообще, в среде OwenLogic есть указатели на занятую память и другие ресурсы ПРки. Вот по ним ты и увидишь, превышаешь ли ты память, или нет.