Программируемые реле ОВЕН ПР100, ПР102 и ПР200, часть 3: Программируем на OWENLogic (примеры из Logo) и балуемся с ModBus

Число просмотров: 1 348 

Среда разработки OWEN Logic с тестовым проектом для блога ;)

Среда разработки OWEN Logic с тестовым проектом для блога ;)

Я продолжаю цикл постов про логические (программируемые) реле ПР от ОВЕНа. Напоминаю, что всё, что к этим реле относится (в том числе и предыдущая посты про ПРки о OWEN Logic), доступно по тэгу «ПРххх«. Сегодня мы продолжаем то, чем занимались в предудыщей части — там мы составили простенький макрос для импульсного реле на основе D-триггера.

Сейчас мы его позюзаем, повторим примеры для Logo про включение света по длинному нажатию кнопки и для управления вентилятором ванной, научимся продвинутым фишкам OWEN Logic (запись в FB, значения по условиям) и ещё… О, ДА! Мы тестанём работу ПР200 с ModBus — подключим термодатчик типа ДТС014 к модулю аналоговых вводов МВ110-8А и попробуем получить с него температуру!

1. Простые примеры управления светом на основе макроса IRelay из прошлого поста.

Сначала начнём со скучной фигни — просто так повторим управление светом через макрос импульсного реле, который мы сделали и протестировали в прошлой части поста. Импульсное реле у нас сделано на базе D-триггера с обратной связью.

Процесс тестирования нашего импульсного реле в симуляторе OWEN Logic

Процесс тестирования нашего импульсного реле в симуляторе OWEN Logic

Хехехехе!!! Так вышло, что пример с импульсными реле у меня уже стал каноническим, типа Hello World в языках программирования! На каждом новом ПЛК или реле я делаю управление светом! =)

Вот сделаем и тут. Даже в ПРку заливать не будет — его достаточно на симуляторе прогнать. Ставим четыре штуки импульсных реле, соединяем их входы на Ix, выходы на Qx, а все Reset — на ещё один вход I8:

Применяем наш макрос на четыре группы света

Применяем наш макрос на четыре группы света

Всё работает (а чего ещё ожидать-то от простого примера)!

Соберём ещё один кусочек, который я делал на Logo — когда длинное нажатие на любую кнопку группы света гасит весь свет в помещении целиком. Через OR берём все входы (OR включены каскадом, чтобы получить OR на 4 входа), дальше пихаем таймер TON (задержка на включение) и после этого таймера подаём сигнал на Reset всех импульсных реле:

Делаем центральное выключение света по длинному нажатию на кнопку

Делаем центральное выключение света по длинному нажатию на кнопку

Остальное — точно так же, как и в Logo. Даже показывать не буду — вы сами может переделать все мои примеры из постов Logo на ПРку.

Что делать, если вы напихали в ПРку кучу модулей IO по ModBus, которые выдают вам 16 входов или 16 выходов одной переменной типа Int (WORD в ModBus)? Да блин легче лёгкого! Вспоминаем, что у нас есть удобная работа с переменными и разбираем исходную ModBus-переменную на 16 булевых переменных при помощи EXTRACT. А дальше эти булевые переменные считаем «кнопками» и работаем с ними как обычно. Можно даже макрос такой написать, который будет это раздирать и склеивать =)

Теперича займёмся вторым классическим примеров — работой вентилятора ванной (вот ссылка на пост про Logo, где про это рассказывалось). Алгоритм работы вентилятора санузла можно поделить на три состояния:

  • Выключен. Вентилятор не работает, подсветка кнопки (напоминаю пост про кнопки и то, как сделать отдельную подсветку) горит.
  • Включается. Если обнаружено короткое нажатие на кнопку, то вентилятор должен включиться.
  • Работает. Вентилятор включен, подсветка кнопки мигает.
  • Выключается вручную. Если обнаружено длительное нажатие на кнопку (кнопка нажата более 3 секунд), то вентилятор должен выключиться.
  • Выключается по времени. Если прошло указанное время (например, 20-30 минут), то вентилятор отключается автоматически.

На Logo это делалось при помощи парочки таймеров. Один работал как задержка на выключение и управлял вентилятором (ткнули кнопку — он и заработал, а через нужное время сам отключился). Другой работал как задержка на включение и отвечал за длинное нажатие кнопки: если сигнал на входе длился больше 3 секунд, то на выходе таймера появлялся сигнал, который вырубал первый тамер при помощи входа «Reset» («R»).

Вот так выглядит таймер Off-Delay в Logo. У него есть вход «Trg» для запуска, вход Par для задания времени работы и вход «R» для сброса (отключения):

Справка по реле Off Delay в Logo Soft Comfort (мутная)

Справка по реле Off Delay в Logo Soft Comfort (мутная)

А вот так выглядит таймер в OWEN Logic (и CodeSys тоже):

Блок TP для таймера, который выдаёт импульс по сигналу запуска

Блок TP для таймера, который выдаёт импульс по сигналу запуска

И вот ГДЕ тут вход Reset-то? Ыыыы?! Как быть-то? Не останавливать таймер что ли? Ни фига подобного! Такие таймеры устроены адски просто как стальной лом: если записать в таймер время работы, равное нулю, то он сразу же остановится!

Что вы говорите? Я вас ещё больше запутал? Записать в таймер? Время? Куда? Как? А ща расскажу!

Помните, я упоминал такую штуку, как запись или чтение из/в функциональный блок? Вот она-то там и нужна! Она может влезть во внутренности одного из функциональных блоков (это выбирается) и записать туда какое-то системное значение. Например, уставку времени или какой-то другой параметр, который вы обычно задаёте в свойствах функционального блока.

Эта штука тоже адски мощная и гораздо круче, чем сраные «Parameter» в Logo. Там можно передать параметры только между некоторыми блоками — например, насчитанное счётчиком значение загрузить в таймер. А тут в блок передаётся любая переменная. Хоть расчитанная, хоть полученная по ModBus, блин! Это гораздо адски круче, чем в Logo! Ну и надо ли говорить, что загружаемое значение можно будет вытащить на экран и редактировать его (как настройку системы)?

Поэтому делаем мы вот какие действия. Во-первых, заводим себе переменную «bVentReset». Если она будет равна True, то вентилятор должен остановиться. Во-вторых, вспоминаем про удобный оператор SEL, который умеет выдавать на выход одно из двух значений.

Дальше делаем такую схему: через SEL выбираем (в зависимости от значения bVentReset) то число, которое надо загрузить в таймер — и загружаем его через функцию записи в функциональный блок (что и куда писать, настраиваем в свойствах).

Схема, которая позволяет принудительно остановить таймер в OWEN Logic

Схема, которая позволяет принудительно остановить таймер в OWEN Logic

Важные замечания:

  • Конечно же из этого удобно сделать макрос таймера со входом Reset;
  • Внимание! Проверьте за мной пожалуйста! Вроде как в свойствах таймера время настраивается в чём надо (секунды, минуты, часы), а если это время загружается через число — то оно всегда загружается в миллисекундах. Но я могу ошибаться;
  • Когда я загружал ноль в таймер, то симулятор ругался на то, что таймер не будет корректно работать из-за того, что симулятор не может его обсчитать так быстро. Поэтому я загружаю в таймер 500 мсек, чтобы симулятор успевал работать и чтобы таймер отключался как мне надо.

Кроме этих особенностей, решение отлично и грамотно работает. И точно так же всё делается в CodeSys. Вот вам кусочек вентилятора и выбора значения, которое я гружу в таймер tmVentTime:

Пример загрузки значения в таймер TOF с CodeSys, чтобы принудительно остановить его

Пример загрузки значения в таймер TOF с CodeSys, чтобы принудительно остановить его

Итак, тестируем нашу схему в симуляторе. Сначала запустим вентилятрор кнопкой по I7:

Таймер вентилятора в OWEN Logic - включен, считает время

Таймер вентилятора в OWEN Logic - включен, считает время

Видно, что SEL у нас выбирает число «20 000» и выдаёт его в таймер. А таймер считает себе в миллисекундах (так что я был прав, миллисекунды туда грузятся).

Теперь вкючим вход I8, на который у меня пока что повешена переменная bVentReset для теста. В этом случае SEL выдал нам значение «500», которое загрузилось в таймер — и таймер остановился! Ура!

Таймер вентилятора в OWEN Logic - принудительно выключен

Таймер вентилятора в OWEN Logic - принудительно выключен

Ещё раз напомню, что такие штуки проще оформить в свои макросы, заточенные под себя — так реально удобнее, чем каждый раз это рисовать.

Ну а мы нарисуем полную схему нашего вентилятора для ванной. Верхняя часть у нас относится к SEL и выбору уставки таймера по bVentReset. Таймер TP1 отвечает за работу вентилятора, таймер TON2 — за длинное нажатие на кнопку (его выход передаётся в переменную bVentReset), а таймер BLINK1 — за мигание подсветки кнопки вентилятора.

Полная схема для управления вентилятором санузла на OWEN Logic (аналог схемы на Logo)

Полная схема для управления вентилятором санузла на OWEN Logic (аналог схемы на Logo)

Обвязка таймеров TP1 и TON2 сделана для того, чтобы сигнал остановки (bVentReset) от TON2 блокировал сигнал от кнопки и не давал ему пройти на запуск таймера TP1. Ну а обвязка вокруг подсветки кнопки через OR собирает два сигнала: если вентилятор не работает, то через NOT напрямую зажигает подсветку, а если вентилятор работает — то подаёт сигналы с BLINK1.

Дальше, если хочется, всё это заворачивается в макрос «Вентилятор ванной» и аккуратно и красиво используется в проектах! Ну или это можно развить интереснее (в комментах поста про Logo спрашивали про это), привязав логику запуска вентилятора к свету санузла. Например, считать время работы света санузла в минутах, а потом через сравнивалку GT и SEL задавать разные уставки для времени работы вентилятора: если свет горел меньше 5 минут — то не врубать, если от 5 до 15 минут — то включить на 2 минуты, если от 15ти до 30 минут — то включить на 15 минут, а если больше — то на 40 минут.

На Logo это делать затрахаешься, потому что там есть аналог SEL — но… только для аналоговых значений с плавающей точкой. Которые во время работы таймера хер загрузишь! Ещё один плюс в сторону ОВЕНа! ;)

3. Работа ПРок с ModBus: настраиваем аппаратную часть и переменные.

Ну а теперь пошёл жЫр! Сейчас мы забацаем следующее: возьмём модуль аналоговых вводов МВ110-8А (на 8 универсальных входов), подключим его к ПРке под ModBus и прочитаем значение температуры с термодатчика сложным методом с небольшими математическими вычислениями и выведем его на дисплей ПР200 (этот пример я делал для поста на форуме ОВЕНа).

Сначала займёмся модулем и его настройками. Ранний пост про модули IO от ОВЕНа и их конфигуратор вы можете почитать по этой ссылке. Ежели я сделаю свежий пост — то тогда потом ссылку подновлю, если не забуду!

Модуль аналоговых вводов МВ110-8А — крутой, потому что он умеет понимать датчики кучи видов: дискретные, сопротивления, температуры и классические 0..10V и 4..20 мА. Мы подключим к нему самый простой датчик температуры ДТС014-50М (вы видели такие датчики в щите котельной в Папушево): белый наконечник датчика — на AIx-1, а остальные два — на AIx-2 и AI-R.

Подключение датчика ДТС014 к модулю аналоговых вводов ОВЕН МВ110-224.8А

Подключение датчика ДТС014 к модулю аналоговых вводов ОВЕН МВ110-224.8А

Теперь нам надо зайти в конфигуратор модулей ввода-вывода и правильно настроить измерительный канал для этого датчика:

Процесс настройки модуля аналоговых вводов ОВЕН МВ110-8А для датчиков ДТС014

Процесс настройки модуля аналоговых вводов ОВЕН МВ110-8А для датчиков ДТС014

Нам надо задать тип датчика (ТСМ50М, Cu 50) и не забыть о том, что измерительный модуль масштабирует то, что намерил его внутренний АЦП для понятных нам значений. Так как датчик умеет мерить от -50 до +150 градусов, то эти значения нам и надо вписать в параметры канала модуля, иначе мы получим не температуру, а величину мозга попугая в зависимости от урожая вереска в Сибири. Также можно задать значение десятичной точки — сколько знаков после запятой нам над мерить. Я оставил один знак.

Прежде чем двигаться дальше — обязательно ПРОВЕРЬТЕ, увидел ли модуль датчик и увидел ли он его правильно! Для этого в конфигураторе модуля надо зайти в меню «Прибор» и выбрать пункт «Состояние входов и выходов». Откроется окошко, в котором будет показано то, что намерил датчик или его ошибки:

Тестируем правильность настройки модуля МВ110-8А для датчика ДТС014

Тестируем правильность настройки модуля МВ110-8А для датчика ДТС014

Камрад, который спрашивал про подключение датчика на форуме ОВЕНа, как раз и зарезался на этом моменте. У него просто датчик был не 50М, а другого типа. Измерительный модуль показывал хрен знает что, а он полез разбираться с ПРкой, ModBus, переменными, программой. А всего-то надо было проверить железо и то, что выдаёт модуль.

Как нам получить то, что модуль намерил? Откроем его инструкцию и пролистаем её до таблицы регистров ModBus. Для первого канала нас будут интересовать регистры от 0 до 5:

Таблица регистров ModBus для первого входа модуля МВ110-8А

Таблица регистров ModBus для первого входа модуля МВ110-8А

Сами данные с модуля можно получать двумя способами:

  • Читать как FLOAT32. Этот тип содержит в себе много геморроя, потому что на самом деле в ModBus никакого FLOAT и тем боеле FLOAT32 вообще нет и не было, а данные передаются как два регистра типа WORD (вон их номера и даны подряд как 4 и 5).
    А вот дальше вы сами должны склеить из этих двух чисел другое число и привести его к типу FLOAT. Косяки тут начинаются из-за того, что иногда некоторые модули или устройства передают эти регистры то в прямом, а то в обратном порядке (старшая и младшая часть числа). Всё это надо учитывать, чтобы правильно склеивать и не получить кашу.
  • Читать как обычные WORD-регистры с целыми числами, а потом вычислять нужное значение. Мне этот способ нравится тем, что ты читаешь только WORD (Int), и точно не ошибёшься с порядком регистров — поэтому я его везде использую, если есть возможность получать данные в таком виде.
    Тут нам нужно тоже две переменных — само число без точки и отдельно положение точки. Значения там получаются в виде «1234» и «2». Это будет значить, что десятичная точка тут должна быть во втором разряде числа — то есть, нам передают число «12,34».
    Математика, которая это считает, простая: полученное значение (1234) делим на 10 в степени положения точки (10^2 = 100). Получаем 1234 / 100 = 12,34. Вуаля!

Начинаем с настроек ModBus в параметрах прибора (меню «Прибор -> Настройки прибора»). Так как модуль аналоговых вводов, который я щас использую, будет работать в одном из щитов заказчика, то пока что я не менял его настройки связи, оставив их стандартными (9600, 8, N, 1). Ну а режим работы слота задаём как Master (это скриншот из прошлого поста):

Окно настроек прибора в OWEN Logic (настройки интерфейса ModBus)

Окно настроек прибора в OWEN Logic (настройки интерфейса ModBus)

Дальше добавляем новое устройство ModBus. Вы можете добавить его из шаблонов (MV110-8A), а я его добавлю вручную.

Выбор шаблонов устройств ModBus (загруженных из менеджера компонентов)

Выбор шаблонов устройств ModBus (загруженных из менеджера компонентов)

Я добавил новое устройство, обозвал его по модели модуля ввода (МВ110-8А). Вот окно его настроек и переменных, которые я создал:

Добавляем модуль МВ110-8А в реле ПР200 (OWEN Logic)

Добавляем модуль МВ110-8А в реле ПР200 (OWEN Logic)

В верхней части окна настраиваются параметры опроса самого устройства: его адрес, скорость опроса, таймаут связи и число попыток связи, после которых ПРка решает что устройство отвалилось со связи и умэрло =) И тут как раз можно настроить порядок слов и байтов для типа Float32, про который я говорил выше.

Настройка параметров опроса ModBus в OWEN Logic (и переменная для запуска работы)

Настройка параметров опроса ModBus в OWEN Logic (и переменная для запуска работы)

Но когда вы сделаете все настройки (адрес, период опроса, таймаут), то примерно с 90%-ной вероятностью вы будете орать что ОВЕН гавнище, ни хера не работает, а потом побежите на форум (или в техподдержку) ОВЕНа с вопросом о том, какого хрена у вас по ModBus физически связь есть (светодиод на модуле ввода мигает), а никакие переменные ни хрена не опрашиваются.

Решается ваш вопрос элементарно. КТО будет разрешать опрос устройства-то? Пушкин? Да, в ПРках есть ещё несколько хитрых фишек. Какое-нибудь ModBus устройство можно включать или выключать из работы программно. Например, чтобы не грузить шину или чтобы сделать проект в ПРке настраиваемый под железо.

Скажем, разрабатываете вы какой-то шкаф управления приводами, и у вас может быть один или два частотника, которые вы опрашиваете по ModBus. Пользователь купит ваш шкаф на базе ПРки и может сам докупить и поставить частотник (в нашем примере — определённой, точно такой же, как и первый, модели). Значит ваша программа должна знать — опрашивать ей два частотника или один. И вот если физически в шкафу есть один частотник, то чтобы ПРка не охреневала про «Нет связи», второй частотник можно выключить из опроса.

Делается это просто: в верхней части окна, где мы задавали адрес и другие параметры устройства, есть поле «Опрос:», в котором надо указать булевую переменную, которая включает или выключает этот самый опрос. Если это поле будет пустым — то ПРка ничего опрашивать не будет. И на этом многие и погорают с ними, ругаясь на ОВЕН. А на самом деле надо на самих себя ругаться-то… Я завожу в проекте одну общую переменную с названием вида «bMbusWork» и при помощи константы выставляю её в True. И всё сразу запускается влёт!

Теперь заглянем в нижнюю область окна. Тут у нас есть список переменных, которые мы читаем или пишем по ModBus из/в наше устройство. И, прежде чем изучать эту кучу полей, тоже обратите внимание на поля для переменных, которые запускают чтение или запись для каждой конкретной переменной!

Переменные, которые будут опрашиваться по ModBus и их настройка (OWEN Logic)

Переменные, которые будут опрашиваться по ModBus и их настройка (OWEN Logic)

В этом списке мы создаём переменные для нашей программы, привязываем их к регистрам ModBus. Справа для каждой переменной отдельно можно выбрать, что с ней делать: её тип, при помощи каких функций её надо читать из устройства, писать в него, какими переменными будет запускаться чтение или запись. У меня тут снова торчит та самая bMbWork, чтобы переменная читалась из модуля.

Видите, здесь гораздо больше вариантов настройки переменной, чем в окне выбора переменных ModBus:

Таблица переменных OWEN Logic (переменные одного из устройств ModBus)

Таблица переменных OWEN Logic (переменные одного из устройств ModBus)

Да, тут можно создать новую переменную и задать ей самые базовые параметры. Но вот запуск записи и чтения тут не задашь. Поэтому всё-таки ModBus-переменные лучше настраивать в окне настроек прибора, а в окне переменных только выбирать для вставки в проект.

4. Обработка полученных по ModBus данных. Где же наша температура?

А вот теперь железная часть закончена! ModBus у нас работает и мы получаем три значения в переменных:

  • InStatus — статус измерения входа. Модуль МВ110-8А сообщает нам о том, всё ли хорошо с нашим датчиком. Если эта переменная равна нулю — то всё хорошо, мы всё измерили. А если с датчиком что-то случилось, то эта переменная будет содержать код ошибки (значения есть в документации на модуль), например «Обрыв датчика», «Замыкание датчика».
    Мы будем использовать эту переменную для того, чтобы наш пример был настоящим: если с датчиком жопа, то система должна не пытаться бесконечно врубать нагреватель, а отключить его по ошибке. Не забывайте о том, что вы программируете под железо! И что ошибка в таком примере можнет привести вас не к сообщению вида «Упс, программа аварийно закрыта», а к настоящему физическому пожару (если брать пример с нагревателем)!!!
  • InValue — наше измеренное значение (оно верно только если InStatus = 0) без десятичной точки.
  • InPoint — положение десятичной точки в штуках разрядов. 1 — это «0.0», 2 — это «0.00», 3 — это «0.00» и так далее.

Для нашей математики нам понадобится операция «fPOW», которая возводит в степень (примеры даны из справки OWEN Logic):

Описание операции fPOW из справки OWEN Logic (возведение в степень)

Описание операции fPOW из справки OWEN Logic (возведение в степень)

И обычная операция деления fDIV:

Описание операции fDIV из справки OWEN Logic (деление)

Описание операции fDIV из справки OWEN Logic (деление)

Так как мы получаем от ModBus переменные целого типа, а наша математика подразумевает работу с числами Float, то будем использовать преобразователи из Integer в Float.

Вот какая математика у нас получится (вверху я записываю «1» в переменную bMbWork, чтобы у меня работал ModBus):

Схема запуска чтения по ModBus и преобразования значения с МВ110-8А в OWEN Logic (ПР200)

Схема запуска чтения по ModBus и преобразования значения с МВ110-8А в OWEN Logic (ПР200)

Взяли InValue, перевели его в Float и подали на операцию деления («ЧТО» делим). Взяли InPoint, преобразовали его в Float, возвели 10 в степень InPoint, а результат подали на операцию деления («НА ЧТО» делим). А готовый результат пихнули в переменную Res.

А потом вытащили все эти три переменные на экран:

Пример возможностей ОВЕН ПР: читаем показания термодатчика по ModBus

Пример возможностей ОВЕН ПР: читаем показания термодатчика по ModBus

На экране такие надписи (это фотка для примера на форуме): Val — то, что даёт модуль без точки (InValue), Pt — положение токи (InPoint), Er — статус измерения (InStatus). А T — это и есть подсчитанная температура (Res). Работает! =))

Помните, в прошлой части поста я рассказывал про библиотеку компонентов и загружал себе в проект регулятор с гистерезисом? А давайте представим, что мы действительно будем нагревать какую-нибудь печь до данным о температуре с ModBus!

Вот какая схема у меня получилась (названия переменных тут я поменял под наш проект):

Полная схема (пример) терморегулятора с проверкой правильности значения от термодатчика

Полная схема (пример) терморегулятора с проверкой правильности значения от термодатчика

Сначала мы разрешаем работ ModBus и опрос нашего модуля вводов. Потом математикой получаем значение температуры в градусах с нужным положением запятой. Потом при помощи операции EQ сравниваем статус измерения с нулём (который означает то, что измерение в порядке и значение верное). Наша температура fTemper подаётся на вход регулятора. Также через константы этому регулятору задаётся уставка (+45 градусов) и гистерезис (3,5 градуса). Выход на нагрев с регулятора через логическое «И» объединяется с успешным статусом измерения и после этого передаётся на управление нагревателем.

Всё?

А хрен вам! У нас же ModBus! Который может банально отвалиться (помехи, обрыв кабеля, глюки связи, глюки питания измерительного модуля)! Что будет, если связи с модулем не будет? Тогда все переменные получат значения «0». Наша математика подсчитает температуру как 0 / (10^0) = 0 / 1 = 0. И это ещё не вся часть пиздеца!

Вторая часть пиздеца — это то, что переменная статус измерения InStatus тоже будет равна нулю! Связи с модулем же нет! И наша текущая программ решит следующее: «О! Измерение верное, ща в печи 0 градусов, надо её жоско греть!». И снова будет пизда печи, пожар, взрыв и новоселье в аду. Для таких ёбаных программистов.

Как быть? Снова пойти в настройки ModBus-устройства и увидеть ещё одно поле для переменной «Статус:». Если вписать туда переменную, то она будет устанавливаться в True, если наше устройство есть на связи по ModBus и False, если связи с устройством нет. Я создал переменную «bDTStatus» и прописал её туда:

Добавляем переменную для опроса состояния модуля МВ110-8А по ModBus

Добавляем переменную для опроса состояния модуля МВ110-8А по ModBus

Теперь в нашу схему добавилось ещё одно условие «И» на выходе управления нагревом. Если связь с модулем пропала — то мы выключаем нагрев к чертям!

Схема нашего терморегулятора с проверкой на то, есть ли связь с модулем МВ110-8А

Схема нашего терморегулятора с проверкой на то, есть ли связь с модулем МВ110-8А

Конечно же в симуляторе при неподключенном ModBus всё так и заработает, как я и говорил. Связи с модулем нет (более того — на момент скриншотов модуль был давно отключени и упакован назад в коробочку), по ModBus все переменные равны нулю — и математика решает, что мы получили 0 градусов и измерили это верно. Регулятор выдаёт сигнал на нагрев, который как раз и блокируется нашей переменной bDTStatus:

Работа схемы терморегулятора, если связь с модулем МВ110-8А отвалилась

Работа схемы терморегулятора, если связь с модулем МВ110-8А отвалилась

Ну как? Прониклись правилами разработки программ под железо? Ещё раз повторюсь, что живое железо, причём промышленное — это не шутка. Всякие умные дома, Ardiuno, Rapsberry и WirenBoard’ы имеют меньшую цену ошибки. Там, если вы накосячите, у вас тихо бахнет электроника. Или 5V на GND замкнёт. А вот в промке очень важно проверять ВСЕ возможные косяки и предусматривать ВСЕ случаи — и отвал датчика, и отвал связи, и отвал модуля на этой связи!

Фуххх! Вот я вам и рассказал всё про ПРки! Проект, который я вам скриншотил для поста, лежит тут: PR200-Blog.owl. А мне, наверное, надо ждать комментариев вида «Ты сволочь! Блядь! Я только купил Logo, а тут ты написал про ПРки! Нахера я этот Logo купил?!» и слухов о том, что инстаграммные электрики начали пиариться (за мой, мать его, счёт) с ПРками и умными домами на них!

Если отставить злостёб — то ПРки, как оказалось, были мной сильно недооценены, потому что так, как я, про них мало кто рассказывал. Как я говорил в первом посте, из-за того что про ПРки было мало инфы, я думал что ПРки — это хуже Logo. А оказалось-то совсем наоборот! Поэтому если вы хотите себе простой щит на ПРках — пишите мне, я вам его сделаю!

17 Отзывов на “Программируемые реле ОВЕН ПР100, ПР102 и ПР200, часть 3: Программируем на OWENLogic (примеры из Logo) и балуемся с ModBus”


  • 1 loa

    Дефицитнейший материал, когда пишут не про то, «как», а вначале «зачем». Это только практик может сделать.

    Большой респект!

  • 2 CS  [Москва]

    Я всегда так пишу, ты знаешь!
    Всё, теперь мониторим инстаграмм — через полгода он будет забит «Умный дом на ПРках» =))

    Вы все хоть когда научитесь, про меня рассказывайте — мне приятно будет, и люди будут знать!

  • 3 santa  [Курск]

    Статья как всегда отличная.
    И как говориться «совершенно в дырочку»
    Шкаф собрать надо, думал на ПРке, теперь точно сделаю на ПРке.

    Спасибо!

  • 4 loa

    «- Петька, ты и про меня оперу напиши
    — Обязательно, ВасильИваныч: опер просил обо всех писать!..»

  • 5 elrus  [Санкт-Петербург]

    А я вот ещё LOGO! не купил, хотя уже в интернет магазине в корзину добавил=)
    Теперь всерьёз думаю щит на ПРке делать.
    Спасибо тебе большое за доступность изложения материала и не хилую мотивацию изучать и разбираться дальше.

    Чего думаю то: В промышленной автоматизации хорошим тоном является все устройства с выхода PLC подключать через Реле интерфейсные. С моей точки зрения, это здравое решение, поскольку в щите у нас одно напряжение (грубо), а пределами щита уже хоть движки через контакторы пускать мощные, другое то есть напряжение.

    Опыта с домашней автоматизацией не много (и весь на оборудовании Crestron), но нигде ещё не видел,чтобы реле устанавливали промежуточные. Всё напрямую с модулей реле или диммеров. Но реле там на 16А все 230VAC.

    Какие ты, шаман, обычно устройства устанавливаешь, на 24 с реле или 230 напрямую? Из тем про Лого понял,что рассчитываешь нагрузки потребителя и подключаешь напрямую на выход через автомат 6А. А с ПРками как дела обстоят? И вообще, сделал уже проект какой на ПРке?
    Места в щите, конечно, релюхи много займут, даже если их 20 будет штук. Да и стоимость прилично так подскочит, если одна релюха 1000 стоит (а вероятно и больше). Хотя с другой стороны, безопасность превыше всех этих экономий..

    Скажи своё экспертное мнение;)
    Спасибо!

  • 6 CS  [Москва]

    elrus Да, ребята! Вы хоть спасибо-то говорите (и не только мне, а миру)! А то я ж не вкурсе ни хрена, иногда кажется что я хуйнёй занимаюсь и пишу в пустоту и никто не читает.

    Смотри. Я ж пришёл в автоматизацию зданий через ПЛКхи, у которых выходы заведомо хилые и которым реле нужны по любому. Вот конкретно у ОВЕНа реле на 5А активной нагрузки. Помигать лампочками подсветок, пнуть какие-то заслонки/клапана — годятся. А лампы — тоже сгодятся на бра.
    Но ты знаешь, что я много раз накалывался на стартовые токи светодиодов, от которых мелкие реле аж спаиваются или прогорают. Даже так, что в Logo их всё равно приходилось ставить.
    Поэтому я уже заебался страдать фигнёй и скрестил одно с другим: сразу ставлю релюхи на +24V DC (катушка) и на 16А номинала. И ими коммутирую лампы под автоматами на 10А.
    Конкретно в ОВЕНских ПРках и ПЛК счвитай что реле стоят на 3А активной нагрузки (если это будет только активная — то 5А).
    Внешние реле можно использовать похеру какие. Не в 1000 рублей они выйдут. Почитай пост про них (по ищи про реле CR-P), ты там увидишь что типоразмер этих реле стандартный. То есть можно взять колодки нормальные, а реле вообще какие-нить китайские с Алишки, если ты захочешь сэкономить на этом.

    Так, если кратко:
    1. Пролистай первый пост про ПРки — там есть фотки встроенных релюшек и железа.
    2. На ОВЕН на нагрузки больше 3А — всегда нужны внешние реле. Какие-нить простые светодиодные бра можно навесить как есть.
    Я ща ставлю реле, потому что это пиздец повышает надёжность и ремонтопригодность щита. Реле заменить — фигня, это быстро. А если что-то из ПЛК сдохнет — то есть реле с ручным управлением, можно быстро врубить свет.

  • 7 elrus  [Санкт-Петербург]

    Ну а как спасибо не сказать? Пиши по возможности больше! Если бы не твои наработки и подробнейшее описание опыта, я хрен знает, где ещё почитать про те же ПРки. Поэтому респектище!!! Я по возможности всегда обратную связь давать буду:)

    Да да, я все посты про ЛОГО и про ПРки прочитал, всё видел и понял.
    Сначала был однозначно убеждён,что надо брать модификацию Логического реле (хоть Лого, хоть ПР) на 230В с Реле на борту. Теперь думаю о 24В.
    Пусть уж лучше сгорит реле внешнее, чем придётся менять весь модуль контроллера . Даже Бра может сморозить какую-нибудь херь, а потом бегай вокруг этого щита..

    Сам с алишки какие-то конкретные реле заказывал? Колодки АВВ возьму по-любому, а вот про реле не подумал даже. Это реально сэкономит денег)

  • 8 CS  [Москва]

    Спасибо! Буду и дальше писать. Ща вот как изолируют всех про вирус — вот займусь постами и перетряхиванием блога дальше =)
    А ща пока щиты считаю и линии проектирую — всех прорвало заказать, в панике!

    Не, я с китая не заказывал релюхи, кроме аналогов CR-S, чтобы их разломать.
    Я их раньше (когда паял платы и прочее) брал в радиомагазинах. Вот зацени вот такие например и такие от Tyco.
    Ещё можешь взять колодки CR-PSS, которые низкие и мелкие. К ним фиксатор не обязателен, и это тебе денег сэкономит.
    Ааа, я понял вопрос: да, пиздато на +24V делать! На 230V пиздато брать только Logo, если ничего супер извратского в нём не будет!

  • 9 elrus  [Санкт-Петербург]

    Супер. Спасибо за ссылки. Так то реально не дорого выходит)
    Еще, кстати, к преимуществам выбора 24В версии контроллера относится бОльшая надёжность выходов, так как ОК выход уж точно дольше проживёт ЭМ реле. Это, конечно,вопрос 5-10 лет, но все же..

  • 10 Nmn

    elrus По поводу реле.
    В промке(большой типа аэс и нефтянки) обычно ставят реле в зависимости от силовой части. Если часть новая, то контакторы на 24v и никаких реле не стоит. Если контакторы на 220 то стараются обвязку с реле сделать все равно в шкафу силовом.(вообще используют шкафы Круза с выкатанными ячейками). В целом стараются не нагружать сигнальные шкафы.

  • 11 CS  [Москва]

    elrus Вот я всё хочу ОК затестить, но всё время получается так, что удобно сразу на одно-два встроенных реле чего-то повесить (типа управления контактором или чем-то подобным), и я забиваю на ОК и беру с релейными выходами =)
    Ага, за ссылки пожалуйста. Посмотри у вас там в радиомагазинах реле такого вида — и подберёшь чего-нить!

  • 12 elrus  [Санкт-Петербург]

    Nmn, спасибо за информацию. Полезно. Всё равно думаю,что зависит от организации, от проектировщика. Я как раз осваиваю данную профессию (проектирование, собственно), 2 года проработал в организации, занимающейся автоматизацией тепловых пунктов и вообще теплотехники. Так вот там руководитель всегда настаивал на установке реле после контроллера, даже если выход контроллера управляет контактором 24VDC. Я для себя это факт отметил и сейчас, работая уже не в автоматизации ТП, а ближе к бытовому сектору, так же стараюсь внешние цепи снабжать реле. Ну это ИМХО, конечно. Тут главное безопасность. Кто-то вон двумя автоматами обходится на дом и живёт себе счастливо))

    https://yadi.sk/i/_M1MKXnPcyp7YA

    Вот щит на Siemens S-1200. Каждая линия отходящая с контроллера идёт к устройству через реле. То есть я обезопасил контроллер от всяких нештатных ситуаций..

  • 13 elrus  [Санкт-Петербург]

    CS, Да, реле в Чип и Дипе найду точно:)

  • 14 CS  [Москва]

    Да и мне реле нравятся. Когда начался трешак со стартовыми токами LED-ламп, с реле удобнее и надёжнее стало!

  • 15 MaxDesperate

    Ох, наконец-то я прочитал все посты и про ПРки =)

    Да, очень понравилась работа с переменными в проге, так много интересного и эксклюзивного для себя написать можно, в отличие от LOGO. Целое непаханное поле для организации сценариев!

    Cs, спасибо за такие посты! Сколько я их у тебя перечитал, уже и не припомню. Но главное, не припомню и сколько всего пользы от этого было — уж ооооочень много! ))

  • 16 CS  [Москва]

    MaxDesperate Во, спасибо за обратную связь!
    Переменные — это прям крутая круть у них, я очень с этого концепта втащился.
    И ещё с концепта экранов (в сравнении с Logo) тоже втащился!

    Ща под вирус можно хоть весь блог перечитывать сидеть, всё равно делать нехер!

  • 17 Redfox  [Екатеринбург]

    elrus, да на самом деле релюшек формата abb cr-p и колодок полным полно существует- te connectivity серий rt и rz, finder 40-46 серий (46- это отдельная вещь- там клеммы подключения у релюшек уже мощнее, плюс есть рычажок ручного включения), omron (не помню каких серий- но есть и формата crp и формата финдера 46 серии), hongfa, relpol, ну а также понятное дело абб, шнайдер, сименс (но им тоже в основном вроде делают релюшки вышеперечисленные фирмы). Ну и плюс всякие китайцы с рангом пониже- тот же TTI.

    По колодкам- также, как и с релюшками. Их вообще походу все в одном месте клепают:)) Даже у меандра есть колодки под cr-p:))

    Шаман, ты кстати не думал заказать кучку хонгфовских релюшек с хитрыми двойными контактами, способными коммутировать огромные пусковые токи (до 800 ампер чтоль) в формате crp? А конкретно серия hongfa HF115F-S (именно с таким обозначением)- таким образом закроешь вопрос по пусковым токам (точнее они никуда не денутся, но хоть релюшки не будут залипать). Вот собственно рассказ про эти релюшки
    https://habr.com/ru/company/wirenboard/blog/422197/

    Меня самого уже начинает задалбывать вопрос по пусковым токам- тут на одном из объектов (который вообще не хочу брать) сделано светодиодного освещения на 11 киловатт, и часть блоков питания включается через релюшки- короче во время пусконаладки у народа логичное дело что все релюшки позалипали от пусковых токов (а реле блин в «умных» релюшках с звэйвом). Короче уже ржу над народом у которых позалипало ведро «умных» релюшек по 5 т.р каждое. Ошибки проектирования в некоторых мозгах б…дь. Не хочу больше уже брать объекты, где приходится исправлять ошибки других, мне одного объекта на звэйве хватило. Такое чувство, что беспроводные хипстерские решения также ломают мозг, как и например аб-лог. Я все-таки как-нибудь напишу про эту гадость, под названием звэйв.

    По пр-кам- тоже надо себе попробовать, только пока разбираюсь чего овенлоджик не хочет под вайном взлетать- хочет мелкософтовский нет фреймворк 4 версии- поставил, еще хочет исправление для фреймворка- а уже кривое индусское исправление не хочет устанавливаться под вайном, а без него овенлоджик не встает. Никто случайно не знает как это дело исправить? Уже пробовал на паре машин с разными версиями вайна- одно и то же- не хочет ставится исправление для нет фреймворка 4 версии. Кодесис же без проблем завелся под вайном.

Оставить отзыв

Вы должны войти на блог, чтобы оставить комментарий.