Comments 94
А что за крипточип? ATEC?
Это же КРИПТОчип, и название секретно! Но выбор не велик, одна из моделей ATECС.
Очень круто! Здорово что вы развиваетесь, главное чтобы оставалась полноценная поддержка старых устройств. Ещё раз большое спасибо за классное устройство.
Самая неприятная ситуация, в которой не хочется оказаться — это полный выход из строя контроллера в какой-нибудь праздничный день. Когда замены ждать несколько дней и непонятно как переносить настройки со сгоревшего устройства на новое. Хорошо если бы был какой-то простой способ миграции с одного wb на другой именно на такой случай.
Наверно глупый вопрос, но всё же. В wb5 никак нельзя заменить процессорный модуль на что-то помощнее?
Самая неприятная ситуация, в которой не хочется оказаться — это полный выход из строя контроллера в какой-нибудь праздничный день. Когда замены ждать несколько дней и непонятно как переносить настройки со сгоревшего устройства на новое. Хорошо если бы был какой-то простой способ миграции с одного wb на другой именно на такой случай.
Наверно глупый вопрос, но всё же. В wb5 никак нельзя заменить процессорный модуль на что-то помощнее?
Сам по себе контроллер выходит из строя редко — статистика отказов пока 0,5-1%.
Но шаловливые ручки частенько что-нибудь ломают в софте. К сожалению простого способа миграции пока нет.
Но вообще, систему автоматизации надо проектировать так, что бы выход из строя контроллера не приводил к фатальным последствиям — был режим перехода на ручное управление, периферийные устройства могли работать автономно и т. д.
Можно, wb5 с мощным процессором это и есть WB6. В начале пытались сделать хотя бы ограниченно совместимыми процессорные платы, но различий оказалось многовато и не стали заморачиваться.
Но шаловливые ручки частенько что-нибудь ломают в софте. К сожалению простого способа миграции пока нет.
Но вообще, систему автоматизации надо проектировать так, что бы выход из строя контроллера не приводил к фатальным последствиям — был режим перехода на ручное управление, периферийные устройства могли работать автономно и т. д.
В wb5 никак нельзя заменить процессорный модуль на что-то помощнее?
Можно, wb5 с мощным процессором это и есть WB6. В начале пытались сделать хотя бы ограниченно совместимыми процессорные платы, но различий оказалось многовато и не стали заморачиваться.
Пока я собирался внедрять дома купленный Wiren Board 5, вы уже выпустили шестую версию. Но я рад, что есть развитие. И не бросайте блог. Знаете, очень страшно покупать контроллер не понимая перспектив. Если он сломается, куплю ли я его завтра? Хочется видеть пульс компании.
Мы будем поддерживать Wiren Board 5 как минимум до окончания производства процессоров Freescale i.MX28 (2020 год; некоторые версии до 2025 года). Возможно, в какой-то момент запустим трейд-ин для обмена на новый контроллер. А в целом мы никуда не пропадаем: делаем новости на сайте, отвечаем на форуме.
У меня от продукции Wiren скорее отрицательные впечатления. Веб-сервер регулярно непонятно от чего отваливается (слава богу он ужен нечасто), реле по MODBUS реагируют с задержкой до секунды.
Просил помощи на форуме, пожали плечами, остался с проблемой один на один…
Просил помощи на форуме, пожали плечами, остался с проблемой один на один…
Нам жаль, что так случилось.
Проблема с веб-интерфейсом действительно была, но, кажется, всегда решалась перезагрузкой страницы.
По опросу Modbus реле — нашёл вашу тему на форуме, мы в ней дали советы, которые могли, а потом тема заглохла. В целом, чтобы найти решение, наверно требовалось больше усилий и от вас, и от нас. Вот у меня на столе лежит релейный модуль, опрашивается на 115200 бит/с и реагирует быстро — теперь нужно найти разницу в конфигурациях)
Проблема с веб-интерфейсом действительно была, но, кажется, всегда решалась перезагрузкой страницы.
По опросу Modbus реле — нашёл вашу тему на форуме, мы в ней дали советы, которые могли, а потом тема заглохла. В целом, чтобы найти решение, наверно требовалось больше усилий и от вас, и от нас. Вот у меня на столе лежит релейный модуль, опрашивается на 115200 бит/с и реагирует быстро — теперь нужно найти разницу в конфигурациях)
Я, кстати, тоже заметил, что время реакции реле модуля WB-MR14 на нажатие кнопки в веб-интерфейсе довольно большое и непостоянное. Но я не пытался пока разобраться почему это так и как от этого избавиться, так что обвинять никого ни в чем не буду.
Обвинять здесь можно только физику. Протокол Modbus RTU — это мастер-слейв протокол. Мастер (контроллер) опрашивает по-очереди все устройства, при этом частота опроса одного регистра определяется только скоростью шины (у нас настраивается), количеством опрашиваемых регистров (у нас настраивается) и скоростью ответа устройств (у нас они отвечают всегда мгновенно).
А насколько быстро в сравнении с родными i2c модулями, подключаемыми «паровозиком»? Сколько миллисекунд первое, сколько второе? И наверно от количества модулей тоже зависит время реакции?
В ваших i2c модулях есть пин int, подозреваю что это прерывание от устройств, т.е. реакция должна быть мгновенной. В modbus же придётся по кругу опрашивать каждое устройство, если устройств много (у меня пять i2c устройств, которые я подумываю подключить через rs485 адаптер), тогда время вообще будет неприемлемым.
В ваших i2c модулях есть пин int, подозреваю что это прерывание от устройств, т.е. реакция должна быть мгновенной. В modbus же придётся по кругу опрашивать каждое устройство, если устройств много (у меня пять i2c устройств, которые я подумываю подключить через rs485 адаптер), тогда время вообще будет неприемлемым.
В ваших i2c модулях есть пин int, подозреваю что это прерывание от устройств, т.е. реакция должна быть мгновенной.
Всё так
В modbus же придётся по кругу опрашивать каждое устройство, если устройств много (у меня пять i2c устройств, которые я подумываю подключить через rs485 адаптер), тогда время вообще будет неприемлемым.
Тут есть большая неопределённость с тем, что является приемлимым. Я знаю ровно одну задачу, где опроса дискретных входов с задержкой в полсекунды недостаточно: включать свет по выключателю. Для конкретно этой задачи есть варианты:
- Поднять скорость шины И опрашивать только регистры входов
- Не использовать Modbus вообще, использовать, допустим наши боковые модули входов. К контроллеру можно подключить напрямую максимально 4*16 = 64 таких дискретных каналов, это более чем достаточно для выключателей.
- Если это умный дом, то использовать для панелек какой-нибудь KNX, благо у Wiren Board есть с этим интеграция
Скоро в игрушки с интеллектом АТТини будут винду пихать.
Питание от батареи Li Poli -> step up -> диод -> step down -> step down -> LDO.
Чес сложнее софт и железо тем неизбежнее и больше багов…
Питание от батареи Li Poli -> step up -> диод -> step down -> step down -> LDO.
Чес сложнее софт и железо тем неизбежнее и больше багов…
Что с сертификацией на применение на промышленных объектах? В качестве средств измерения? Поддержкой выходов 0..20, 4..20 мА, датчиков типа Pt100/1000 и термопар? Поддержкой промышленных языков программирования и возможностью работы в режиме RTOS?
Нет и не планируем.
Это другая сфера, другие подходы, все другое.
Есть декларации о соответствии ТР ТС 004/2011«О безопасности низковольтного оборудования» и ТР ТС 020/2011 «Электромагнитная совместимость».
Есть боковой модуль AI-DV-12 с токовыми входами 0..20, 4..20 мА.
Для датчиков типа Pt100/1000 и термопар разработали MAI-11. Но выпуск пока придержали — устройство сложное, куча режимов, еще отлаживать надо, а спрос непонятен, когда есть датчики 1-Wire.
Это другая сфера, другие подходы, все другое.
Есть декларации о соответствии ТР ТС 004/2011«О безопасности низковольтного оборудования» и ТР ТС 020/2011 «Электромагнитная совместимость».
Есть боковой модуль AI-DV-12 с токовыми входами 0..20, 4..20 мА.
Для датчиков типа Pt100/1000 и термопар разработали MAI-11. Но выпуск пока придержали — устройство сложное, куча режимов, еще отлаживать надо, а спрос непонятен, когда есть датчики 1-Wire.
Да, согласен. Совсем другая область применения и другие требования. Модуль входов, правда, только под заказ (судя по сайту). Жаль, что свернули MAI-11 — можно было бы в вентиляцию попробовать запихнуть. Что ж, полновесной конкуренции ОВЕНу не случилось, но всё равно радуют такие новости.
Мы не стремились конкурировать со всеми устройствами Овена, у нас своя ниша (при этом с некоторой их периферией мы дружим, а клиенты регулярно наши контроллеры с устройства Овена «спаривают»).
А вы обычно автоматизацией в каких областях занимаетесь?
А вы обычно автоматизацией в каких областях занимаетесь?
Пищевая отрасль, ИТП, холодоснабжение, вентиляция, химические производства (бытовая химия), общая автоматика по мелочам. Для большинства применений нужны сертификаты, а вот бюджетная вентиляция в первую очередь — почему бы и нет, как аналог Carel, поддержание уровня всякие. С ОВЕН столько проблем хлебнули, что больше ни-ни. У Logo слишком скромные возможности. В основном полновесные Siemens используем, иногда B&R, но для компактных решений это слишком дорогие варианты.
Расскажите, с чем столкнулись при работе с Овен?
О… я недавно составлял для них целое письмо по этому поводу, сейчас найду. Вот оно:
—
— Добавлю к этому, что тех поддержка предлагает влезть в плату управления с паяльником чтобы «поменять батарейку», что является прямым нарушением условий гарантийного обслуживания.
—
Обзор встреченных косяков
Продукция компании ОВЕН, представленная ПЛК-100 и ПЛК-150 показала себя с худшей из возможных сторон. Неудачная архитектура организации памяти контроллера приводит к фатальным проблемам при загрузке проектов в контроллер — ОЗУ используется в качестве загрузочной памяти и система возвращает ошибку #0 в 9 попытках подключения из 10. Возможностей контроллера катастрофически недостаточно для корректной работы с ПИД регуляторами — штатные библиотеки нерабостопособны в принципе. При добавлении более десятка переменных в обмен по ModBus время загрузки программы в контроллер возрастает экспоненциально, до неприемлимых десятков минут. Встроенный OPC сервер работает не стабильно и имеет свойство отваливаться до перезагрузки при потери связи. Штатные средства диагностики не содержат никакой информации об ошибках, тех поддержка так же не в состоянии связно и в адекватные сроки объяснить что значат те или иные коды ошибок. Такое впечатление, что разработчики встроенной ОС контроллера давно не работают в ОВЕН и не предоставили ОВЕНу никакой документации. Продолжая список недостатков, особо хочется отметить конструктивное убожество ПЛК данной серии, требующее разборки корпуса для обновления прошивки, а также сдохшую через несколько месяцев эксплуатации ПЗУ ПЛК-100 — при попытке создания загрузочной программы на 2/3 загрузки она прерывается с неопознаваемой ошибкой. Стабильность работы фирменного модема ОВЕН не способна обеспечить надежного предоставления заявленных услуг по рассылке смс оповещений, так как требуется регулярная перезагрузка модема путём сброса питания (что подтверждено техподдержкой), а так же предоставленные библиотеки для работы с ним не актуальны и крайне несовершенны — перестают работать в непредсказуемый момент и не предоставляют никакой диагностической информации по возникшей проблеме, в т.ч. негативно сказывается полное отсутствие документации в свободном доступе. Попытка добавления переменных из библиотек работы с смс в ОРС сервер приводит к полной неработоспособности встроенного ОРС.
Предложенные на замену ПЛК новой модели вызвали ещё больше нареканий, т.к. в них не завелись даже надёжные на старых моделях UDP подключения для обмена данными между контроллерами. Два контроллера общаются между собой стабильно, при подключении третьего — произвольно ложится и перестаёт отвечать один из трёх ПЛК. Количество ошибок при загрузке программы (неправильно завершённые сеансы, обрывы передачи данных, #0 без конца и края) полностью исключает возможность использования данного оборудования на ответственных применениях вне рамок тупого мониторинга небольшого количества переменных.
Предложенные на замену ПЛК новой модели вызвали ещё больше нареканий, т.к. в них не завелись даже надёжные на старых моделях UDP подключения для обмена данными между контроллерами. Два контроллера общаются между собой стабильно, при подключении третьего — произвольно ложится и перестаёт отвечать один из трёх ПЛК. Количество ошибок при загрузке программы (неправильно завершённые сеансы, обрывы передачи данных, #0 без конца и края) полностью исключает возможность использования данного оборудования на ответственных применениях вне рамок тупого мониторинга небольшого количества переменных.
— Добавлю к этому, что тех поддержка предлагает влезть в плату управления с паяльником чтобы «поменять батарейку», что является прямым нарушением условий гарантийного обслуживания.
Да уж, серьезные предъявы… А я уже подумывал использовать их ПЛК все-таки для системы умного дома, в том числе и отопления… Рассуждал по принципу «ну у них такое количество инсталляций, должно же это работать».
Может, у вас откровенный брак был?
Вы получили ответ на ваше письмо? Было бы интересно услышать ответ (или ответ — замена ПЛК)?
Может, у вас откровенный брак был?
Вы получили ответ на ваше письмо? Было бы интересно услышать ответ (или ответ — замена ПЛК)?
Нет, к сожалению, это был не брак. Как честно заявил один из представителей ОВЕНа на одной из выставок по поводу очередной новой линейки ПЛК (200 серия, кажется — на сайте пока нет, хотя бы выглядящих прилично, но внутри всё те же ужасные винты… да, схема подключению и конструкция винтовых клемм отдельная головная боль) — их контроллеры не предназначены для автоматизации, это системы диспетчеризации. И правда, если их модули подключить к скаде по ModBus — они идеально работают. Без контроллера. А контроллером можно… ну, скажем, уровень в баке поддерживать. Или в двух. Как нам ответила тех поддержка в процессе допытывания почему всё так плохо работает — программа на 3 ПИД регулятора «избыточна» для их ПЛК, но, увы, пруфы давать отказались и просто выдали на тесты обновлённые модели серии 110, с которыми стало ничуть не легче. Которые мы благополучно сдали обратно через месяц попыток запустить в офисе.
Ответ на последнее письмо пока не получили и вряд ли он будет — нас попросили оставить положительный отзыв об опыте внедрения их оборудования в ответственном месте, а получили вместо «спасибо всё круто» такой список проблем… самое грустное, что техподдерка при всём желании не может их решить. Эти проблемы были заложены ещё на стадии проектирования железа.
Ответ на последнее письмо пока не получили и вряд ли он будет — нас попросили оставить положительный отзыв об опыте внедрения их оборудования в ответственном месте, а получили вместо «спасибо всё круто» такой список проблем… самое грустное, что техподдерка при всём желании не может их решить. Эти проблемы были заложены ещё на стадии проектирования железа.
Интересно канеш, но раз уж так, то необходимо пожалуй, больше деталей, заявления достаточно «сильные»)))
Что значит избыточна программа для 3х ПИД — не хватает ресурсов? В контроллере можно проверить количество этих самых ресурсов, чтобы оценить?
Обновленные модели также отказались работать с 3ПИД?
Я к тому — что наверно не могут тысячи (а я думаю у них партии именно такие) устройств не работать?
Что значит избыточна программа для 3х ПИД — не хватает ресурсов? В контроллере можно проверить количество этих самых ресурсов, чтобы оценить?
Обновленные модели также отказались работать с 3ПИД?
Я к тому — что наверно не могут тысячи (а я думаю у них партии именно такие) устройств не работать?
Написал кучу текста, скользнула мышка и всё коту под хвост… Сейчас в блокнотике всё напишу, потом выложу.
Начнём по порядку.
1) ПИД
Фирменная библиотека PID_Regulators не имеет в своём составе адекватного аналогового регулятора, способного выдать выходной сигнал в диапазоне 0..100% для управления аналоговым выходом. При этом управляющий сигнал для аналогового выхода должен подаваться в формате 0..100, что прописано в документации к модулю. Поэтому были взяты библиотеки с сайта oscat.de и минимизированы для реализации требуемого функционала, в частности задействованы функции:
FUNCTION CTRL_IN: REAL
FUNCTION_BLOCK CTRL_OUT
FUNCTION_BLOCK CTRL_PI
FUNCTION_BLOCK CTRL_PID
FUNCTION DEAD_ZONE: REAL
FUNCTION_BLOCK FT_DERIV
FUNCTION_BLOCK FT_PIDWL
FUNCTION_BLOCK FT_PIWL
FUNCTION T_PLC_US: DWORD
Всё, что делает программа, это регулирует давление скоростью насосов, температуру на выходе из драйкулеров скоростью вентиляторов и температуру обратной воды из кондиционера трёхходовым клапаном. Ну и переключается на резервный насос по наработке и аварии. Совсем немного, не правда ли?
2) Средства диагностики
Для мониторинга состояния ПЛК ОВЕН в CoDeSyS 2.3 используется блок Statistic, содержащий следующую информацию:
— время цикла — держится в районе 6-10 мс в нашем проекте;
— time to backup power down
— температура ПЛК
— флаг питания
— флаг перегрузки CPU
— свободное время процессора на 1 цикл
Так же в настройках можно принудительно задать минимальное время цикла, по рекомендации тех поддержки — не меньше минимального времени, измеренного в статистике. По моему личному опыту — не влияет ни на что.
Как вы уже заметили, вся диагностика ПЛК крутится вокруг контроля времени цикла и нагрузки процесссора, упуская из виду другую важную деталь — свободное место в ОЗУ.
3) Память
После работы в Siemens у меня есть привычка все ценные переменные делать Retain, и при использовании контроллеров B&R, Omron, Carel проблемм с нехваткой памяти не возникало ни разу. В ОВЕН пришлось минимизировать число Retain переменных до минимума, а всем остальным задавать стартовые значения, чтобы после запуска система могла корректно работать. Вот результат компиляции программы одного из контроллеров на текущий момент:
POE индексов 295(1%)
Использовано данных: 3336 из 131072 байт(2,55%)
Энергонезависимых данных: 1582 из 4096 байт (БАЙТ, КАРЛ!) (38,62%)
Вроде бы тоже довольно скромные цифры и программа неплохо ужата.
На данном этапе ситуация выглядит довольно радужно. Теперь давайте рассмотрим тонкости мониторинга ПЛК ОВЕН, прежде чем вернуться к #0, ставшей в этом проекте главным стопором пусконаладки. Про кривой-косой таймер в библиотеке я даже не вспоминаю, пришлось отсчёт времени на аварии делать через сложение и сравнение числа с уставкой.
4) Мониторинг данных
ПЛК серии 150/100 поддерживают 2 способа передачи данных на верхний уровень: ModBus TCP/RTU и встроенные OPC CoDeSyS (не рекомендуется техподдержкой). В случае добавления переменных в коммуникацию ModBus TCP (RTU уже занят на опрос модулей IO) мы встречаем первую проблему: при добавлении в коммуникацию больше 20 переменных время загрузки программы в контроллер возрастает экспоненциально. На 5ой минуте я плюнул и выкинул этот обмен данными из конфигурации (а ведь надо ещё в программе обеспечить перекладывание значений в эти переменные и чтение данных из них, что неоправданно раздувает код). OPC сервер же наоборот, крайне удобен и прост: Проект — Опции — Сивольная конфигурация — поставить 2 галочки и вы получаете полный доступ на чтение-запись ко всем переменных проекта с лёгким импортом в SCADA через менеджер OPC сервера, который настраивается в два клика и автоматически формирует список переменных. Разница возможностей, на мой взгляд, очевидна, но… при обрыве коммуникации (у нас был плохо обжат один разъём RJ45 долгое время) сервер падает и поднимается только после нажатия Reset на контроллере. После загрузки программы и перевода контролелра в Run он тоже может не подняться, в таком случае приходилось отключаться от контроллера и тоже жать Reset.
Уже начинает напрягать такое… странное поведение.
5) ОЗУ
И вот мы переходим к самому интересному. Загрузили программу, перевели контроллер в Run, допустим даже пошли данные в ОРС. Вы хотите подключиться и поправить кусочек кода… #0. Отказано. Снова попытка… снова ошибка #0. Какого хрена, спросите вы и будете правы. Тех поддержка может сваливать проблему на кабель, на ваши кривые руки, на что угодно, но истина в другом: система использует общую ОЗУ для обработки программы и для обеспечения сервисных функций, в том числе подключения и онлайн мониторинга и… её не хватает. Свободных ресурсов недостаточно для этих задач при загруженной и запущенной программе, описанной выше. Соответственно частичное обновление кода также невозможно и цитирую переписку с саппортом: «Сбросьте контроллер на заводские настройки и загрузите программу заново». С этого места начинается АД — систему нельзя останавливать (перегреется охлаждаемое оборудование), а заказчик хочет новую фичу. Спасало только наличие двух резервируемых независимых контуров охлаждения и пока обновляли один — работал на костылях другой. Состанояние ОЗУ никак не мониторится через штатные средства диагностики. А процессору хорошо, он справляется — фигня вопрос.
6) ПЛК 110
Замученная в усмерть техподдержка выдала нам на тестирование ПЛК110, которые «больше, лучше, сильнее», поскольку официально признавать проблему нехватки памяти представители ОВЕН отказались. После пересборки проекта на новый контроллер к ошибке #0 добавились постоянные обрывы связи и сообщения «неправильно завершён сеанс». Про UDP я вроде уже говорил, что он вообще не поднялся (нам нужно было с двух контролллеров передавать данные в третий, отвечающий за рассылку смс оповещений и мониторинг приточно-вытяжной вентиляции здания).
В общем, будем скоро переделывать на Carel и больше никогда с ОВЕН связывать не собираемся. Время в разгребание этих проблем и пытки тех поддержки улетело немеряно, а выхлопа ноль. Да, для каких-то примитивных задач задач возможностей этих недоконтроллеров может и хватит, но…
1) ПИД
Фирменная библиотека PID_Regulators не имеет в своём составе адекватного аналогового регулятора, способного выдать выходной сигнал в диапазоне 0..100% для управления аналоговым выходом. При этом управляющий сигнал для аналогового выхода должен подаваться в формате 0..100, что прописано в документации к модулю. Поэтому были взяты библиотеки с сайта oscat.de и минимизированы для реализации требуемого функционала, в частности задействованы функции:
FUNCTION CTRL_IN: REAL
FUNCTION_BLOCK CTRL_OUT
FUNCTION_BLOCK CTRL_PI
FUNCTION_BLOCK CTRL_PID
FUNCTION DEAD_ZONE: REAL
FUNCTION_BLOCK FT_DERIV
FUNCTION_BLOCK FT_PIDWL
FUNCTION_BLOCK FT_PIWL
FUNCTION T_PLC_US: DWORD
Всё, что делает программа, это регулирует давление скоростью насосов, температуру на выходе из драйкулеров скоростью вентиляторов и температуру обратной воды из кондиционера трёхходовым клапаном. Ну и переключается на резервный насос по наработке и аварии. Совсем немного, не правда ли?
2) Средства диагностики
Для мониторинга состояния ПЛК ОВЕН в CoDeSyS 2.3 используется блок Statistic, содержащий следующую информацию:
— время цикла — держится в районе 6-10 мс в нашем проекте;
— time to backup power down
— температура ПЛК
— флаг питания
— флаг перегрузки CPU
— свободное время процессора на 1 цикл
Так же в настройках можно принудительно задать минимальное время цикла, по рекомендации тех поддержки — не меньше минимального времени, измеренного в статистике. По моему личному опыту — не влияет ни на что.
Как вы уже заметили, вся диагностика ПЛК крутится вокруг контроля времени цикла и нагрузки процесссора, упуская из виду другую важную деталь — свободное место в ОЗУ.
3) Память
После работы в Siemens у меня есть привычка все ценные переменные делать Retain, и при использовании контроллеров B&R, Omron, Carel проблемм с нехваткой памяти не возникало ни разу. В ОВЕН пришлось минимизировать число Retain переменных до минимума, а всем остальным задавать стартовые значения, чтобы после запуска система могла корректно работать. Вот результат компиляции программы одного из контроллеров на текущий момент:
POE индексов 295(1%)
Использовано данных: 3336 из 131072 байт(2,55%)
Энергонезависимых данных: 1582 из 4096 байт (БАЙТ, КАРЛ!) (38,62%)
Вроде бы тоже довольно скромные цифры и программа неплохо ужата.
На данном этапе ситуация выглядит довольно радужно. Теперь давайте рассмотрим тонкости мониторинга ПЛК ОВЕН, прежде чем вернуться к #0, ставшей в этом проекте главным стопором пусконаладки. Про кривой-косой таймер в библиотеке я даже не вспоминаю, пришлось отсчёт времени на аварии делать через сложение и сравнение числа с уставкой.
4) Мониторинг данных
ПЛК серии 150/100 поддерживают 2 способа передачи данных на верхний уровень: ModBus TCP/RTU и встроенные OPC CoDeSyS (не рекомендуется техподдержкой). В случае добавления переменных в коммуникацию ModBus TCP (RTU уже занят на опрос модулей IO) мы встречаем первую проблему: при добавлении в коммуникацию больше 20 переменных время загрузки программы в контроллер возрастает экспоненциально. На 5ой минуте я плюнул и выкинул этот обмен данными из конфигурации (а ведь надо ещё в программе обеспечить перекладывание значений в эти переменные и чтение данных из них, что неоправданно раздувает код). OPC сервер же наоборот, крайне удобен и прост: Проект — Опции — Сивольная конфигурация — поставить 2 галочки и вы получаете полный доступ на чтение-запись ко всем переменных проекта с лёгким импортом в SCADA через менеджер OPC сервера, который настраивается в два клика и автоматически формирует список переменных. Разница возможностей, на мой взгляд, очевидна, но… при обрыве коммуникации (у нас был плохо обжат один разъём RJ45 долгое время) сервер падает и поднимается только после нажатия Reset на контроллере. После загрузки программы и перевода контролелра в Run он тоже может не подняться, в таком случае приходилось отключаться от контроллера и тоже жать Reset.
Уже начинает напрягать такое… странное поведение.
5) ОЗУ
И вот мы переходим к самому интересному. Загрузили программу, перевели контроллер в Run, допустим даже пошли данные в ОРС. Вы хотите подключиться и поправить кусочек кода… #0. Отказано. Снова попытка… снова ошибка #0. Какого хрена, спросите вы и будете правы. Тех поддержка может сваливать проблему на кабель, на ваши кривые руки, на что угодно, но истина в другом: система использует общую ОЗУ для обработки программы и для обеспечения сервисных функций, в том числе подключения и онлайн мониторинга и… её не хватает. Свободных ресурсов недостаточно для этих задач при загруженной и запущенной программе, описанной выше. Соответственно частичное обновление кода также невозможно и цитирую переписку с саппортом: «Сбросьте контроллер на заводские настройки и загрузите программу заново». С этого места начинается АД — систему нельзя останавливать (перегреется охлаждаемое оборудование), а заказчик хочет новую фичу. Спасало только наличие двух резервируемых независимых контуров охлаждения и пока обновляли один — работал на костылях другой. Состанояние ОЗУ никак не мониторится через штатные средства диагностики. А процессору хорошо, он справляется — фигня вопрос.
6) ПЛК 110
Замученная в усмерть техподдержка выдала нам на тестирование ПЛК110, которые «больше, лучше, сильнее», поскольку официально признавать проблему нехватки памяти представители ОВЕН отказались. После пересборки проекта на новый контроллер к ошибке #0 добавились постоянные обрывы связи и сообщения «неправильно завершён сеанс». Про UDP я вроде уже говорил, что он вообще не поднялся (нам нужно было с двух контролллеров передавать данные в третий, отвечающий за рассылку смс оповещений и мониторинг приточно-вытяжной вентиляции здания).
В общем, будем скоро переделывать на Carel и больше никогда с ОВЕН связывать не собираемся. Время в разгребание этих проблем и пытки тех поддержки улетело немеряно, а выхлопа ноль. Да, для каких-то примитивных задач задач возможностей этих недоконтроллеров может и хватит, но…
Спасибо, достаточно подробно! Может, когда нибудь Овеновцы услышат вас…
Я правильно вас понял — на ПЛК 150 крутилось 3 ПИДа + кое какая дискретная логика, обмен с I\O, плюс коммуникиция наверх и это еле-еле(никак) крутилось?!? Мда.
А я так хотел использовать Овен для домашней автоматизации, возложить на него «серьезные» задачи по отоплению и свету…
ПРки использовали? Про них я не слышал, чтобы глючили. Про ПР200 в частности, интересно
Я правильно вас понял — на ПЛК 150 крутилось 3 ПИДа + кое какая дискретная логика, обмен с I\O, плюс коммуникиция наверх и это еле-еле(никак) крутилось?!? Мда.
А я так хотел использовать Овен для домашней автоматизации, возложить на него «серьезные» задачи по отоплению и свету…
ПРки использовали? Про них я не слышал, чтобы глючили. Про ПР200 в частности, интересно
А расскажите пожалуйста, как именно думали применять модуль? Какие сигналы и сколько штук опрашивать? Может быть что-нибудь и подберём из своего оборудования или гарантированно поддерживаемого стороннего.
Абстрактно — бюджетные шкафы вентиляции и простейшей автоматики, где в качестве датчика температуры приточного воздуха и обратной воды обычно используются простейшие датчики сопротивления, а частотники для защиты от помех управляются по 4… 20 мА. А конкретно — один заказчик сейчас хочет 10 кнопок аварийного останова в ряд в отдельной коробочке под рукой у оператора и при этом не хочется тянуть многожильный кабель до шкафов управления черти где или ставить RS485 конвертер… Не устраивают его кнопочки F1… 10 на клавиатуре, близко они слишком.=_=
Как производится менеджмент ключей шифрования?
Слежу за Wiren Board с самого начала — сразу понравилось, что в комбайне всё на борту "из коробки", а то в RPi приходится все обвязки самому колхозить. Если б карман был шире, накупил бы ваших плат и забыл про долбанное велосипедо-строительство. В общем, рад, что ваш девайс совершенствуется.
При цене устройства 13к, делать стоимость модуля расширения на KNX — 20к… ну извините ребята, проще тогда через IP-KNX гейт от шнайдера/абб/зенио завести всё на небольшой сервачок с Qt KNX.
KNX — отдельная область, неключевая для нас. При этом ценообразование там особое. Мы в эту область идём как вариант, позволяющий объединить экономичные исполнительные Modbus устройства (диммеры, релейные модули) и красивые KNX-панели.
А какой бы вы рекомендовали IP-KNX гейт по разумной цене?
А какой бы вы рекомендовали IP-KNX гейт по разумной цене?
При разговоре о KNX оборудовании планка разумности резко уезжает в сторону высоких цен, но у Zennio есть KNX-IP Interface PLess, который у нас продается за 300евро, что практически равно вашему модулю. Но даже банально по себестоимости KNX-IP стоит весьма дороже модуля расширения. А уж если озаботиться достать оборудование по дешевле, что тогда совсем не в вашу пользу сравнение. (upd. в Риге можно за 220 взять)
Я то сперва подумал, что вы за KNX много берете, чтобы отбить сертификацию, но походу её у вас нету…
Я то сперва подумал, что вы за KNX много берете, чтобы отбить сертификацию, но походу её у вас нету…
> гейт от шнайдера/абб/зенио
Это голимая проприетарщина, гвоздями прибитая к вендору с узким специфичным набором (1-2 штуки) языков программирования, которые ещё нужно учить и качать специальные IDE (for Windows 10 only) для них.
Здесь же полноценный полностью открытый Linux с 20 популярными языками пр-я, хотя бы один из которых точно знает каждый хабровчанин. Хотя бы по этой причине нужно брать WB.
Да и по цене максимум — сопоставимо, но я уверен что и дешевле, чем большинство «сименсов» и прочих. А если учесть, что все плюшки у WB «искаропки», а сименсы, если начнёшь плюшками обвешивать, то многократно переплатишь. Да и приколотишь себя гвоздями к вендору.
Нужен кому-то дома в роли автоматики дорогой закрытый вендорсос? Мне, например — нет.
Это голимая проприетарщина, гвоздями прибитая к вендору с узким специфичным набором (1-2 штуки) языков программирования, которые ещё нужно учить и качать специальные IDE (for Windows 10 only) для них.
Здесь же полноценный полностью открытый Linux с 20 популярными языками пр-я, хотя бы один из которых точно знает каждый хабровчанин. Хотя бы по этой причине нужно брать WB.
Да и по цене максимум — сопоставимо, но я уверен что и дешевле, чем большинство «сименсов» и прочих. А если учесть, что все плюшки у WB «искаропки», а сименсы, если начнёшь плюшками обвешивать, то многократно переплатишь. Да и приколотишь себя гвоздями к вендору.
Нужен кому-то дома в роли автоматики дорогой закрытый вендорсос? Мне, например — нет.
KNX — известный протокол, но вообще это скорее экосистема, которая гарантирует качество применяемых изделий(а именно — сегмент пром. автоматики). На мой взгляд системы автоматизации должны быть в первую очередь надежными, а уже потом — дешевыми, опенсорсными и т.д. Не призываю вас ранжировать требования так же, как и я :)
PS. KNX подразумевает возможность программирования каждого исполнительного или сенсорного блока, поэтому «центральный блок», который предлагает WB, в принципе не является необходимым. Отсюда и надежность — выгорание любого из блоков системы не приводит к отказу системы в целом.
PS. KNX подразумевает возможность программирования каждого исполнительного или сенсорного блока, поэтому «центральный блок», который предлагает WB, в принципе не является необходимым. Отсюда и надежность — выгорание любого из блоков системы не приводит к отказу системы в целом.
Интеграторы, которые ставят людям KNX, привыкли иметь 30%+ от цены оборудования себе. Наши контроллеры многие из них не берут, потому что они стоят слишком дёшево. Огромная розница в 20к за модуль — наша попытка решить проблему слишком маленькой цены.
Интеграторская цена там уже сильно более адекватная, а в опте (25+ устройств) снижается до наших стандартных цен, т.е. до нескольких тысяч рублей за модуль.
Интеграторская цена там уже сильно более адекватная, а в опте (25+ устройств) снижается до наших стандартных цен, т.е. до нескольких тысяч рублей за модуль.
А почему на плате нет механического крепежа для вашего SODIMM модуля проца? Полагаете, он на вибрации не отщелкнется?
Сначала было подумал что за 13 кило рублей в принципе неплохой комплект и можно вязть поиграться, но выяснилось что 3G это еще +3 т.р. wifi… итого 18 т.р. — ну не поигрался и ладно.
Скажите а из чего сделана кнопка питания на корпусе за 500 рублей?
Скажите а из чего сделана кнопка питания на корпусе за 500 рублей?
На всякий случай: цена с 3G и Wi-Fi+Bluetooth и антенной 16700 рублей. По такой цене похожих устройств с 3G я не знаю.
Цена за крышку с кнопкой питания — это отдельная история: мы поставляем 95% устройств без кнопки питания, потому что контроллер обычно работает 24/7, и на многих объектах возможность выключить контроллер неспециалистом — это минус. Но так как иногда всё-таки просят кнопку, мы выставили цену за такую модификацию на сайт, и держим для таких заказов отдельную коробку со специально фрезерованными верхними крышками с кнопкой и коннектором.
Цена за крышку с кнопкой питания — это отдельная история: мы поставляем 95% устройств без кнопки питания, потому что контроллер обычно работает 24/7, и на многих объектах возможность выключить контроллер неспециалистом — это минус. Но так как иногда всё-таки просят кнопку, мы выставили цену за такую модификацию на сайт, и держим для таких заказов отдельную коробку со специально фрезерованными верхними крышками с кнопкой и коннектором.
Спасибо, прочел с удовольствием. Понятно, что «игрушка» для энтузиастов, но все таки, на сайте, не могли бы для примера, описать пару тройку реализаций, с более подробным описанием, на чуть более понятном для неискушенных?
Для начал простейшие, управление освещением. Если не трудно, и про умный дом, было бы интересно. Ваша концепция очень легко масштабируемая, как на квартиру\дом так и на здания разной специфики, от складов до рабочих зон.
У вас 'CE' для прибора сделано? (Сертификация для Европы) Прибор звучит интересно, но я боюсь, что местные электрики его завернут из-за сертификации.
Нет — всё собираемся, но пока не сделали. Сейчас предварительно планируем комплекс мер на осень: европейская сертификация, нормальный перевод сайта, базовый перевод документации.
А как вы полагаете, где в Европе его можно было бы применить?
А как вы полагаете, где в Европе его можно было бы применить?
Ну я бы себе на Кипре поставил для управления умным домом. В моём представлении умный дом довольно примитивно — датчик температуры, датчик Co2, два ввода питания (ночное дешёвое электричество и дорогое обычное) — и всё, задча рулить кондеями и вентиляцией.
А процедура сертификации сильно сложная? Если не секрет, какой порядок цен на оную?
Чем все закончилось? Что из вышеуказанного было сделано по результату?
Собственно, всё и сделали:
- сертификат https://wirenboard.com/ru/pages/certificate/,
- перевод сайта, в том числе страницы контроллера: https://wirenboard.com/en/product/wiren-board-6/,
- базовый перевод документации https://wirenboard.com/wiki/Wiren_Board_6/en
А вы планируете за рубежом применять?
Нет ли модулей для работы со стандартными Wiegand-считывателями? D0-D1, пара светодиодов, пара сухих контактов, пара реле
А чем обусловлен выбор SODIMM для процессорного модуля? Планируете далее менять на что-то более серьезное? 800 МГц тоже не шибко много для ряда задач.
А для каких задач нужно больше?
Видео обрабатываем. Пользуем RPi3 с платой самодельной.
У вас есть какие-либо аппаратные кодеры/декодеры?
Наш контроллер точно не для обработки видео. А если не секрет, какая у вас задача, в которой нужна и автоматизация (RS-485, входы-выходы), и обработка видео на одном устройстве?
На объектах устанавливаем USB-камеры (получается дешевле, чем IP и нет проблемы с подводом питания, при том, что устанавливаем бывает на расстоянии до 10 м) и локально на RPi выполняем обработку видео — сжатие, нарезку на части, извлечение кадров для превью, организация параллельной трансляции.
Про видеочасть примерно понятно, наверно, можно попробовать (но будет точно не так быстро, как на Raspberry Pi). А автоматизацию какую выполняете этим же устройством на объекте?
Про видео. Если аппаратного кодека нет или нет его поддержки в ffmpeg, то это беда-беда. Если в RPi не использовать аппаратный кодер, то решение становится негодным к продакшену.
> А автоматизацию какую выполняете этим же устройством на объекте?
Некоторое количество датчиков открытия (герконы), датчики темп. и влажности (1-wire), напряжения на АКБ, счетчики электроэнергии, по Ethernet еще снимаем статистику по SNMP (c ИБП в частности).
> А автоматизацию какую выполняете этим же устройством на объекте?
Некоторое количество датчиков открытия (герконы), датчики темп. и влажности (1-wire), напряжения на АКБ, счетчики электроэнергии, по Ethernet еще снимаем статистику по SNMP (c ИБП в частности).
Добрый день. Не нашёл, есть ли интерфейс OpenTherm?
Добрый день!
Пока нет. Думали, но вы пока только третий человек, который интересуется.
А для какой вам задачи?
Пока нет. Думали, но вы пока только третий человек, который интересуется.
А для какой вам задачи?
газовым котлом управлять например, многие имеют такую вывод, и «фирменный» контроллер стоимостью в полкотла.
Это что ж за горелки такие…
не совсем понял вопрос, но сам интерфейс есть и в Buderus и Baxi оба котла ~30-40к, проводной регулятор с датчиком от 5 вроде как, с поддержкой беспроводных дороже. Вплоть до «систем управления» под 100к
Хм. Я сталкивался с небольшими котлами контейнерного исполнения на Logo, бюджет шкафчика явно меньше даже 1/10 остального оборудования. Видел ОВНОвое решение для котельной больницы, как бы цена тоже не может дойти и до 1/10. Для полноценных котлов обязательно наличие сертифицированного автомата горения, вокруг которого строится вся обвязка. К примеру на котле ДЕ-30 цена нормального привода паровой задвижки выше всего шкафа управления вместе взятого. Мы, полагаю, говорим сейчас о принципиально разных классах устройств — вы о «бытовых» котлах для отопления помещений, а я о промышленных генераторах пара и системах отопления для целых зданий и комплексов, отсюда вышло небольшое недопонимание соотношения цен системы управления и самого котла.)
Смотря как управлять.
Сам модуль сопряжения с opentherm несложный. Можно наколхозить преобразователь opentherm — rs232.
А как у него с живучестью по холоду? Интересует с какой стороны: если буду ставить, то на дачу. В зимнее время соответственно для него задачей станет пережить отключение электричества на 4-6 часов и проседание температуры до -10-15 (врядли больше), при подаче напряжения включиться и поднять обогреватели.
Этой зимой «умная» терморозетка не справилась, увы. У неё конечно по паспорту была эксплуатация от нуля до 50, но я надеялся, что выживет. Зря.
Городить вокруг мозгов дома обогрев от ИБП на 6 часов мне как-то не хочется.
Этой зимой «умная» терморозетка не справилась, увы. У неё конечно по паспорту была эксплуатация от нуля до 50, но я надеялся, что выживет. Зря.
Городить вокруг мозгов дома обогрев от ИБП на 6 часов мне как-то не хочется.
Очень не хватает документации, примеров сценариев использования, онлайн демки веб-интерфейса. Бегло пробежался по сайту и wiki, но так и не понял на кого позиционируется ваше решение. Больше на частников или на бизнес.
Начал строить дом и сейчас как раз раздумываю — что брать за основу для его автоматизации.
То ли какую-нибудь RPI/odroid + колхозинг из всевозможных релюх c esp, sonoff, xiaomi aqara и прочего бюджетного c HomeAssistant/Domoticz, то-ли доплатить и взять какое-нибудь законченное решение с возможностью расширения.
Начал строить дом и сейчас как раз раздумываю — что брать за основу для его автоматизации.
То ли какую-нибудь RPI/odroid + колхозинг из всевозможных релюх c esp, sonoff, xiaomi aqara и прочего бюджетного c HomeAssistant/Domoticz, то-ли доплатить и взять какое-нибудь законченное решение с возможностью расширения.
Примеры сценариев — я как интегратор использую данные решения для комплексной автоматизации инженерной инфраструктуры зданий. Нормально идет в банковском, продуктовом и топливном ритейле. Решил много задач по мониторингу базовых станций и телекомуникационных узлов и датацентров — уже более двух тысяч внедрений. Сделал несколько мноквартирных домов — умные квартиры и диспетчерезация для УК. Основные системы которые мониторю и чем управляю — контроль электро/газо/водо/теплоснабжения, резервное ДГУ и бесперебойное ИБП электроснабжение, освещение, вентиляция, кондиционирование, ИТП, СКУД. Есть интеграции с охранно-пожарной сигнализацией. Спектр применения очень широкий.
С документацией почти у всех производителей подобного оборудование мягко сказать очень скудно, т.к. разработчики концентрируются на внутренней начинке и совсем забывают про пользователей. Лично я не один раз сталкивался с подобными проблемами и часто приходилось искать инфу по форумам и т.д. Прежде чем начинать делать автоматизацию на UNIX подобных и не только системах, оцените свои возможности, сможете ли самостоятельно во всем разобраться, иначе «геморрой» будет в подарок с оборудованием. Для умного дома есть бюджетные, законченные и почти работающие решения например Loxone и ему подобные. Почему почти? Потому, что тоже «глючит» или «глючило», т.к. последний раз я с ним работал 4 года назад, может уже все изменилось. Каждый по своему себе представляет умный дом и исходя из этого необходимо подбирать соответствующее решение. В любом случае приятно видеть, что отечественные производители следят за тенденциями и стремятся к совершенству. WB, это мощный комбайн, но ребята… Для кого вы делаете продукт? Если для себя, то пойдет как есть, если для людей, то занимайтесь документацией и примерами реализации. Удачи вам!
«Очень не хватает документации, примеров сценариев использования, онлайн демки веб-интерфейса.»
Вы наверное действительно очень бегло пробежались по сайту))) я как и вы зашел и сразу же нашел и демо интерфейс и еще есть видео стенда, где можно всем порулить через интерфейс!!! Ну и на форуме тысячи сценариев применения!!!
Демо WEB интерфейс:
demo.contactless.ru/#
Онлайн-видео демонстрационного стенда:
contactless.ru/stand-online
Ну WiKi и Форум то сами найдете я надеюсь)))
Вы наверное действительно очень бегло пробежались по сайту))) я как и вы зашел и сразу же нашел и демо интерфейс и еще есть видео стенда, где можно всем порулить через интерфейс!!! Ну и на форуме тысячи сценариев применения!!!
Демо WEB интерфейс:
demo.contactless.ru/#
Онлайн-видео демонстрационного стенда:
contactless.ru/stand-online
Ну WiKi и Форум то сами найдете я надеюсь)))
Это все как бы есть. Но в данный момент Демо WEB интерфейс не работает, а когда работал, то на Онлайн-видео демонстрационном стенде ничего не происходило. Как вы успели выполнить более 2000 внедрений? Если устанавливать каждый день по WB, то у вас ушло бы 5,5 лет. Мне кажется, что WB 5-6 лет на рынке, может ошибаюсь.
Ну я был на новом сайте (тот что в статье).
И к великому моему стыду я там вэб-демки до сих пор не нашел.
А по вашей ссылке кроме навбар-меню тоже ничего не фурычит, к сожалению.
Wiki с форумом нашел. Спасибо :)
И к великому моему стыду я там вэб-демки до сих пор не нашел.
А по вашей ссылке кроме навбар-меню тоже ничего не фурычит, к сожалению.
Wiki с форумом нашел. Спасибо :)
Вот бы ещё Вики довели до ума. А то очень много не рабочих ссылок. И развитие железа опережает описательную часть (очень важную для продвижения продукта) на пару поколений.
Многие нюансы вообще не затронуты.
А как обстоят дела с ресурсом flash памяти? Есть ли оптимизация ОС под это дело?
Для той же Raspberry существует проблема быстрого износа флешки.
Для той же Raspberry существует проблема быстрого износа флешки.
У нас используются чипы eMMC, распаянные на плате вместо SD-карт. По своей сути это почти одно и то же, но с качеством у eMMC дела обстоят гораздо лучше. У нас до сих пор отказы eMMC являются одной из первых по частоте причин отказа контроллеров, но в абсолютных числах это единицы штук на тысячи проданных. Пока ни одного отказа из-за собственно износа (ограниченного количества стираний ячеек) у нас зафиксировано не было: это проверяется по служебной информации в регистрах EXTCSD.
Позвольте полюбопытствовать: что за клеммы на плате — пружинные wago 250 серия?
Давно «слежу» за вами, вы делаете классную вещь, но:
Другие написали вроде, но от себя тоже хочется все-таки: доки и софт, доки и софт! Опять статья про то, какое мы сделали железо… А я хочу принести, открыть «первые шаги», запустить IDE без линуксов и дебианов, перетащить блок пид-регулятора или RS-триггера и управлять диодиком\теплым полом\воротами etc!((
Кстати, нет в планах делать те же устройства, только с Ethernet на борту?
Другие написали вроде, но от себя тоже хочется все-таки: доки и софт, доки и софт! Опять статья про то, какое мы сделали железо… А я хочу принести, открыть «первые шаги», запустить IDE без линуксов и дебианов, перетащить блок пид-регулятора или RS-триггера и управлять диодиком\теплым полом\воротами etc!((
Кстати, нет в планах делать те же устройства, только с Ethernet на борту?
Sign up to leave a comment.
Wiren Board 6: снова на Хабре с новой версией контроллера для автоматизации