Сейчас на многих станках, линиях и агрегатах стоят панели оператора, либо сенсорные панельные контроллеры. Вы сами понимаете, что это очень удобно. На экране можно вывести множество функций: графики физических величин, архивация данных, рецепты, настройки оповещений по смс, рецепты вкусных булочек. Да и просто удобная и красивая индикация: лампочки, кнопочки и переключатели. На чём это всё пишется? Среди разнообразия ПО, я остановился на CoDeSyS 3.5. В CoDeSyS 3.5 визуализация обладает рядом преимуществ, которые будут рассматриваться в этой статье.
Привет, друзья! Это одна из основных сред разработки, которую я использую при внедрении и наладке автоматизации оборудования. Сегодня мы с вами поговорим во всех подробностях.
О программном продукте CoDeSyS 3.5
Среда разработки является продуктом 3S-Smart Software. CoDeSyS-это аппаратно-независимая система для программирования ПЛК. Она поддерживает все языки стандарта МЭК. Сочетает в себе объектно-ориентированное программирование(то есть с помощью визуальных функциональных блоков). Возможна работа с несколькими устройствами и приложениями.
В этой среде можно писать программы стандарта МЭК FBD, IL, LD, CFC, ST.
В чём же принципиальное отличие от версии CoDeSyS 2.3? Принципы программирования и построения языков остаются теми же. Давайте рассмотрим преимущества данной системы:
Добавилось очень много полезных функций (в основном, касающиеся визуализации);
Рабочее окно среды разработки стало гораздо удобнее;
Существуют готовые библиотеки модулей ввода-вывода;
Возможность Веб-визуализации;
Ну и конечно самый главный козырь, это сама визуализация;
Мне, честно говоря, нравится работать в двух версиях, и в CoDeSyS 2.3, и в 3.5. Каждая по-своему удобна. Единственный недостаток новой среды заключается в том, что она в постоянной разработке, то есть всё время обновляется. И периодически при компиляции возникает куча ошибок, с которыми иногда невозможно разобраться.
Какое оборудование поддерживает CoDeSyS 3.5? Из отечественных контроллеров я знаю СПК сотой и двухсотой серии, ПЛК 323 и ПЛК304. Из «Буржуйских» мне известно о WAGO и Berghof.
На самом деле, работать в этой среде разработки сложно. Очень много нюансов. Каждый новый проект у меня начинается с самого начала. Для изучения требуется перелопатить кучу инструкций и помучить ребят из тех. поддержки компании ОВЕН. В следующих своих статьях я ознакомлю вас со многими фишками, если будет кому интересно.
Визуализация CoDeSyS 3.5
Отдельно бы хотелось поговорить о визуализации в среде разработки. Это шикарный инструмент для реализации большинства задач в производстве. Весь технологический процесс можно отобразить на экранах, сделать красивые графики, архивацию, анимацию и т.п. Ниже приведу видео для наглядной демонстрации возможностей визуализации.
Особенности визуализации в Codesys 3.5
1. Графический редактор
Одной из ключевых особенностей Codesys 3.5 является графический редактор, который позволяет создавать визуальные элементы интерфейса для взаимодействия с операторами. Этот инструмент предоставляет широкий набор графических объектов, таких как кнопки, индикаторы, графики и т.д., которые могут быть легко настроены и анимированы.
2. Поддержка множества форматов
Codesys 3.5 поддерживает множество форматов визуальных элементов, включая векторные и растровые изображения, SVG, а также веб-компоненты. Это обеспечивает более высокое качество и гибкость визуализации, что особенно важно при работе с современными мультимедийными элементами.
3. Анимация и визуальные эффекты
Визуализация в Codesys 3.5 предоставляет возможности для создания анимаций и визуальных эффектов, которые помогают операторам быстрее и точнее интерпретировать данные. Это включает в себя анимированные графики, изменение цвета и формы объектов в зависимости от состояния системы, а также создание плавных переходов между различными экранами и состояниями.
4. Мультиязычность
Для многих проектов промышленной автоматизации важно иметь мультиязычный интерфейс для операторов. Codesys 3.5 позволяет легко локализовать визуальные элементы и тексты, обеспечивая комфортное использование системы на разных языках.
5. Интеграция с внешними источниками данных
Часто визуализация должна отображать данные, получаемые из внешних источников, таких как базы данных, датчики или веб-сервисы. Codesys 3.5 обладает мощными средствами интеграции, что позволяет легко получать и обновлять данные из различных источников и отображать их на визуальных элементах.
Простейший пример проекта
Мы с вами сейчас создадим простой проект в среде разработки CoDeSyS 3.5. Давайте сделаем так, чтобы от кнопки включалась и выключалась лампочка. Дистрибутив можно скачать с официального сайта компании ОВЕН. Стандартная установка. Всё, как обычно. Запускаем программу и создаём проект.
Так как у меня под рукой нет сенсорной панели, я задам устройство-эмулятор, которое загружается с компьютера. Работать будем на наиболее наглядном языке CFC.
Для начала в правом нижнем углу нам нужно запустить эмулятор контроллера. Затем нажимаем Scan Network, и система должна обнаружить ваш компьютер.
Давайте создадим простейшую программу.
Добавляем визуализацию в наш проект. Правой кнопкой мыши вызываем контекстное меню и жмем Добавить объект.
Рисуем визуализацию под наш алгоритм. Выбираем элементы во вкладке панели инструментов.
Присваиваем переменные элементам во вкладке свойства. Для кнопки:
Для лампочки:
Из настроек на этом у нас всё. Теперь нажимаем на кнопку Логин. И в результате у вас должна получиться вот такая картинка:
Я реализовывал несколько проектов в этой программе. Но наиболее удачный и «красивый» проект у меня получился на автоматизации холодильных камер. Задача заключалась в том, чтобы охлаждать камеры до определённой температуры.
В первой камере охлаждается воздух с помощью заслонки в приточной системе. Во второй и третьей камере охлаждается воздух каскадным включением компрессоров в зависимости от времени наработки. Все эти физические данные архивируются. В случае аварии контроллер отправляет сообщение смс на указанный номер. Писал программу я на сенсорном панельном контроллере СПК207.03.CS.WEB.
Давайте покажу вам несколько иллюстраций моей работы. Главное меню панельного контроллера:
Аварии компрессоров:
Компрессорная
И наконец, WEB-визуализация:
Выкладываю видео, где вся эта система работает:
На этом я заканчиваю, напишите в комментариях, в каких средах вы пишите и что вы программируете?
Если интересна статья, подписывайтесь, ставьте рейтинг, дальше будет интереснее.
Многие процессы в автоматизации (например порошковая покраска, изготовление выпечки, поддержание давления в трубопроводе) требуют точного регулирования физического параметра. С такими задачами хорошо справляется библиотека CoDeSyS ПИД регулятор. Эта тема довольно сложная, многогранная. Целые институты занимаются разработкой таких сложных и многоуровневых алгоритмов.
Приветствую посетителей моего блога! В сегодняшней статье я отвечу на вопрос — как работает ПИД-регулирование, для чего это нужно и как его использовать на практике…
Как работает ПИД-регулятор?
Начнём с теории. Пропорционально-интегрально-дифференциальный (ПИД) регулятор — прибор в управляющем контуре с обратной связью. Устройство, формирующий сигнал с целью достижения высокого качества и точности переходного процесса в системе. Наиболее эффективный вид регулятора для обеспечения высокой точности параметра(температуры, длины, давления).
Существует специальная формула для формирования сигнала…
Ниже приведена таблица составляющих формулы:
Давайте поговорим о параметрах, которые непосредственно участвуют в процессе работы регулятора:
Хр — полоса пропорциональности. В общих чертах, чем шире Хр, тем меньше величина Y при одном и том же E. То есть чем больше Хр, тем короче импульсы.
Ти — интегральная составляющая. Эта величина позволяет выдавать сигнал в зависимости от накопленной ошибки ( или от накопленного отклонения Е). Чем выше параметр, тем он реже и меньше выдаёт сигнал при рассогласовании Е. Это для того, чтобы сигнал не раскачивал систему и не совершал перерегулирование.
Тд — дифференциальная составляющая. Эта величина позволяет выдавать сигнал Y, при дополнительных резких возмущениях в системе. по — русски говоря, этот параметр срабатывает, когда нужно быстро среагировать на возмущающие воздействия. Естественно, чем он больше, тем длиннее импульс.
Я думаю с точки зрения теории все понятно. Тогда переходим непосредственно к практике. Для чего и как используется ПИД-регулятор?
Описание библиотеки для CoDeSyS
Я говорил об этом, скажу ещё раз, библиотеки обязательно скачивайте с официальных источников. С сайта ОВЕН или библиотеки OSCAT. Рекомендую не использовать библиотеки с форумов или с других источников. Пишите лучше сами. Только вы понимаете от начала до конца, как у вас всё работает.
Для задвижек я рекомендую использовать данный функциональный блок, он хорошо зарекомендовал себя, и за всё время работы на реальном объекте у меня не было к нему никаких вопросов. На изображении ниже приведён функциональный блок ПИД-регулятора.
Описание каждого входа и выхода:
Входные значения:
Выходные значения:
Хочу заметить, функциональный блок универсальный. То есть подходит и для дискретных задвижек, и для аналоговых.
Рабочая схема ПИД-регулятора
Возникает сразу же вопрос, а как же на самом деле правильно использовать данную библиотеку, чтобы она правильно функционировала и не глючила?
Предлагаю вам рабочую схему библиотеки ПИД-регулятора:
setAPID_otopl является вспомогательным блоком для ввода коэффициентов ПИД-регулятора. Хочу сказать, что на входах блока обязательно должны стоять какие-то переменные, пускай даже если будут стоять в положении FALSE.
А какие вы используете библиотеки в своих проектах? Пишите в комментариях. На этом я заканчиваю, хорошего вам настроения, всего наилучшего. Пока, пока.
В этой статье приведены настройки связи между ПЛК и Модулем ввода тензометрических датчиков. Такая комбинация автоматики удобна для конфигурации различных дозаторов с медленными процессами.
Эту систему не назовёшь сверхточной, так как обмен данных между контроллером и модулями порядка около 20 мс.
5 лет назад мы реализовывали проект дозатора сыпучих материалов, работает до сих пор. Система довольно надёжная.
Приветствую, на связи автор блога, Гридин Семен и я начинаю писать….
Технология программируемых логических контроллеров совершенно точно достигла зрелости – ей уже 60 лет. В связи с чем возникает вопрос: станут ли нынешние ПЛК «пенсионерами» и сойдут ли их будущие версии в могилу? Такое предположение кажется уместным, учитывая быстрое, а порой экспоненциальное развитие компьютерного оборудования, программного обеспечения, искусственного интеллекта, облачных сервисов и средств связи. Благодаря этим достижениям информационные технологии постепенно проникли в ранее изолированную сферу операционных технологий.
В свете этих событий приводим статью Джеффа Пейна, опубликованную в журнале Control Engineering о будущем контроллеров и приложений промышленной автоматизации на фоне происходящей в последние десятилетия эволюции ПЛК.
Оставаться верным своему делу
Основная задача ПЛК остается той же, что и всегда: обеспечение надежного управления и мониторинга физических полевых устройств даже в сложных условиях эксплуатации. Это было достигнуто благодаря использованию специализированных процессоров, операционных систем и сред программирования, встроенных в защищенные платформы. Тем не менее, эффект масштаба продолжает стимулировать внедрение основных потребительских и коммерческих технологий в ПЛК везде, где это осуществимо. Принцип «меньше, быстрее, лучше» сохранился и будет оставаться верным, но в основном в отношении более быстрых и лучших аспектов, поскольку тенденция к дальнейшей миниатюризации за последнее десятилетие выровнялась.
Многие преимущества развития электронных компонентов, процессоров и твердотельной памяти – снижение стоимости, уменьшение размера, минимизация энергопотребления и увеличение возможностей – уже реализованы в ПЛК и другой промышленной электронике. Однако несмотря на то, что незначительные улучшения в размерах, стоимости и производительности будут происходить и впредь, реальный прогресс будет заключаться в возможностях. На данный момент размер платформы в значительной степени ограничен необходимостью физической проводки для взаимодействия с модулями ввода-вывода ПЛК. Традиционный проводной ввод-вывод по-прежнему необходим, но во многих случаях связь с полевыми устройствами смещается в цифровые сети и распределяется удаленно с использованием таких технологий, как IO-Link и беспроводная связь.
Многоядерные процессоры, встроенные в конструкции ПЛК, теперь позволяют дополнять детерминированное управление обширными дополнительными вычислительными и коммуникационными функциями. На протяжении более 20 лет термин «программируемый контроллер автоматизации» (programmable automation controller – PAC) широко использовался для описания промышленного контроллера с более широкими возможностями, чем классический ПЛК.
Хотя поначалу ПАК (PAC) мог показаться отдельным продуктом по сравнению с ПЛК, время показало, что инженеры по автоматизации меньше озабочены названием и номенклатурой и гораздо больше интересуются производительностью и доступными функциями. В дальнейшем пользователи будут готовы рассматривать практически любой тип аппаратной части или операционной системы в качестве платформы автоматизации, которая может продолжать называться ПЛК, хотя на самом деле это будет нечто большее, если она сможет обеспечить управление в реальном режиме времени, обеспечивая при этом расширенные вычислительные возможности.
Сочетание гибкости и логики
Хотя системы на базе Windows доминируют в мире потребительских и коммерческих компьютеров и занимают видное место в сфере промышленной визуализации, это не относится к управлению в реальном времени. Платформы ПЛК/ПАК обычно работают под управлением специализированной операционной системы, хотя существуют некоторые варианты на базе Linux. В самых общих чертах пользователи должны сбалансировать свое стремление к открытости, которая обеспечивает большую гибкость и низкую стоимость продукта, с требованием надежности промышленного уровня, которое исторически обеспечивалось только проприетарными системами. Эти запатентованные системы также обеспечивают высокую степень кибербезопасности, хотя в первую очередь за счет некоторой неизвестности хакерам.
В течение многих лет наблюдалась тенденция или, по крайней мере, большой интерес к более открытым промышленным системам, как с точки зрения аппаратных платформ, так и с точки зрения языков программирования. Некоторые конечные пользователи применяют стандартное оборудование Raspberry Pi и Arduino для реализации проектов автоматизации и обработки данных. Другие избегали подобных экспериментов с продуктами потребительского уровня из-за опасений по поводу надежности. Но теперь несколько версий этих платформ превратились в устройства промышленного уровня (Рис. 1). Пользователи предъявляют большой спрос на возможность сочетания современной платформы программирования с проверенными промышленными устройствами ввода-вывода.
Рис. 1. Теперь, когда современные процессорные платформы с открытым исходным кодом доступны в форм-факторах промышленного уровня у конечных пользователей появилась возможность интеграции традиционных методов автоматизации с более современными языками, осно
При таком разнообразии аппаратных средств следующим препятствием на пути к открытости стала гомогенизация среды программирования. В классических ПЛК использовалось программное обеспечение, разработанное конкретным поставщиком, которое было трудно перенести на другие бренды. Стандарт IEC 61131-3 представил упорядоченные языки программирования ПЛК и типы данных, но реализации, специфичные для конкретного поставщика, по-прежнему препятствовали переносу кода между брендами. В конечном счете интегрированная среда разработки (integrated development environment – IDE) CODESYS предложила более согласованный способ создания кода с использованием стандартных языков для его кроссплатформенного развертывания на промышленных контроллерах.
Однако ни одна из этих инициатив не учитывала тот факт, что программисты, поступающие на работу, часто предпочитали писать код на более современных языках, основанных на ИТ, таких как C++ или Python.
Несмотря на все эти усилия, направленные на открытость и современные языки программирования, можно с уверенностью сказать, что классическая релейная (лестничная) логика сохранится в обозримом будущем. Релейная логика имеет обширную базу инсталляций и остается простой методологией кодирования, предпочитаемой многими электриками, техническими специалистами АСУ ТП и даже разработчиками. Ее графический стиль позволяет выполнять основные функции поиска и устранения неисправностей, а также выполнять типичные функции промышленной автоматизации, а широкое распространение дает дополнительные преимущества.
Сегодня большинство аппаратных платформ поддерживают релейную логику – как собственную, так и реализованную через другие IDE, например, CODESYS, а многие из них также допускают другие методы кодирования, которые можно комбинировать по мере необходимости. Различные языки программирования имеют свои сильные и слабые стороны для конкретных задач, а большинству пользователей нравится разрабатывать собственный вариант лучшего инструмента для решения проблемы, балансируя при между гибкостью и сложностью. Дополнительным бонусом для пользователей является то, что выход за пределы проприетарных языков позволяет им создавать библиотеку кода, которую можно развернуть на любом типе целевого оборудования, сводя к минимуму доработку.
Главным моментом сегодня и в будущем является то, что пользователям нужны платформы автоматизации, предлагаемые и поддерживаемые проверенными и опытными промышленными поставщиками, с возможностью поддержки любого типа предпочтительного языка программирования.
Коммуникации
Некоторые из достижений промышленной автоматизации в последнее время связаны с улучшением коммуникаций, что привело к полной взаимосвязи всех систем предприятия. Как и в случае с аппаратным обеспечением и программированием контроллеров, здесь наблюдается переход от проприетарных реализаций к более открытым предложениям.
Традиционные промышленные шины, такие как DeviceNet давно предлагаются пользователям в виде проверенных и надежных устройств. Но сейчас преобладают проводные и даже беспроводные варианты Ethernet, при этом доступны несколько ведущих протоколов промышленной связи. Улучшения физического форм-фактора, в том числе во влагозащитном корпусе со стандартными разъемами и питанием по PoE, теперь позволяют Ethernet-устройствам подходить и для промышленных сред.
Некоторые протоколы, такие как EtherNet/IP, PROFINET и Modbus-TCP, связаны с марками и моделями конечных устройств, тогда как другие оптимизированы для типов задач автоматизации (например, EtherCAT для управления движением). Хотя EtherCAT не нов, включение этого протокола в более функциональные ПЛК теперь означает, что приложения управления движением низкой и средней сложности могут быть интегрированы в платформу автоматизации без необходимости использования отдельных контроллеров движения.
Ethernet-APL – это среда, оптимизированная для операционных технологий (OT), которая упрощает развертывание проводного Ethernet на полевых устройствах. IO-Link развивается как оптимизированная полевая шина для базовых дискретных устройств автоматизации с соответствующими коммуникационными возможностями и интеллектом.
Соединение ОТ с ИТ для безопасного включения приложений Промышленного интернета вещей (IIoT) и передачи данных для поддержки удаленной визуализации и аналитики требует другого класса протоколов связи. OPC UA и MQTT доминируют в этой роли. Хотя некоторые из их возможностей частично совпадают, для обоих протоколов существуют оптимальные варианты применения, и пользователи могут реализовать их одновременно. Другие вспомогательные инструменты, такие как Node-RED, стали предпочтительными в качестве графического метода обработки и передачи данных в облако для использования другими приложениями.
От датчика до контроллера, от локального сервера, до облачных ресурсов и браузера – что все это означает? В «старые времена» контроллеры меньшего размера имели ограниченный набор функций, поэтому для достижения полной возможности подключения требовались более крупные устройства или несколько уровней интеграции. Сегодня и в будущем пользователи захотят, чтобы эти опции были доступны даже на самых простых и недорогих платформах автоматизации (Рис. 2).
Рис. 2. Сегодня даже недорогая платформа автоматизации ПЛК оснащена расширенными логическими возможностями, управлением движением, проводным/беспроводным подключением, протоколами связи ИТ/ОТ и многим другим
Роль интегрированной робототехники
На протяжении многих лет робототехника в основном существовала как специализированная разновидность автоматизации, требующая индивидуальной интеграции в вышестоящие и последующие системы. Ситуация меняется по мере того, как робототехника в целом и коллаборативные роботы (коботы) в частности, похоже, станут одной из крупнейших областей роста во всей промышленной автоматизации в течение следующих 5–10 лет (Рис. 3). Что касается сопутствующих разработок, системы машинного зрения значительно продвинулись за последнее десятилетие, и многие из них стали совместимы с роботами, что позволяет легко интегрировать их во множество приложений.
Рис. 3. Робототехника представляет собой быстрорастущую область промышленного дизайна – спрос на функциональные платформы автоматизации и связанные с ними сенсорные технологии будут расти, поскольку пользователи стремятся повсеместно интегрировать робототе
Современные платформы автоматизации должны быть готовы идти в ногу со временем, предоставляя необходимую вычислительную мощность, инструкции по программированию и технологии плавной интеграции с робототехникой и машинным зрением. Современный ПЛК с такими возможностями, размещенный рядом с робототехникой в качестве платформы автоматизации будет обладать явным преимуществом.
Роль искусственного интеллекта в будущем ПЛК
Ни одна перспективная статья о промышленной автоматизации, написанная в 2024 году, не может упустить из виду потенциальное влияние искусственного интеллекта (AI) и машинного обучения (ML) для анализа ситуации и реагирования на нее режиме реального времени. Однако с этой темой связано много шума, поскольку в настоящее время в качестве платформы автоматизации программируемые логические контроллеры для этой задачи подходят не идеально. Хотя в будущем некоторые продвинутые версии ПЛК смогут запускать в реальном времени алгоритмы AI/ML.
Вместо этого ПЛК имеют хорошие возможности выступить в качестве полевого интерфейса для ресурсов искусственного интеллекта и машинного обучения более высокого уровня, предоставляя пользователям оперативные, всеобъемлющие и связанные с конкретной обстановкой данные.
С другой стороны, генеративный искусственный интеллект (Gen-AI) в ближайшие годы будет играть более важную роль в ПЛК с точки зрения создания кода. Среды разработки с интегрированными инструментами поддержки искусственного интеллекта могут помочь пользователям, возможно, даже специалистам начального уровня, разрабатывать логику автоматизации на основе библиотек и проверенного кода. ИИ, используемый в качестве инструмента разработки, может помочь ускорить разработку, повысить надежность кода и свести к минимуму ненужный и рутинный труд.
Будущий ПЛК – это часть платформы автоматизации
В течение следующего десятилетия программируемые логические контроллеры, какими мы их знаем, определенно не прекратят свое существование, даже если их будут называть ПАК, периферийными контроллерами, платформами автоматизации или чем-то еще. Но и не будет единой технологии контроллера, которая могла бы выполнять все функции во всех ценовых категориях.
Вместо этого ПЛК будут продолжать развиваться в зависимости от доступных технологий и потребностей пользователей, как они делали это на протяжении последних пяти десятилетий. Приоритетом будет обеспечение контроля в реальном времени и надежного мониторинга, но они добавят еще более совершенные функции программирования и подключения для улучшения пользовательского опыта и скорости реализации проектов.
Итак, ПЛК в ближайшее время не исчезнут, а новые технологии, подкрепленные требованиями пользователей, помогут им эволюционировать в качестве базовой платформы автоматизации.
Материал подготовлен Московским заводом тепловой автоматики (МЗТА)
Компания ОВЕН предоставила возможность в своей среде разработки Owen Logic писать алгоритмы на языке программирования ST. Это новшество ввели в принципе давно. Где-то полгода назад, просто руки дошли именно сейчас. Приступим.
Приветствую всех, на связи автор блога Гридин Семен, пишу статью про программируемые реле и их среду разработки Owen Logic. Скачать её вы можете на официальном сайте компании ОВЕН.
Как создать функциональный блок?
Заходим в дистрибутив, создаём новый проект. После этого создаём ФБ на языке ST.
После этого мы получаем шаблон полотна функционального блока.
Дальше все операторы очень схожи с Codesys, единственная разница в том, что нельзя пока написать какие-нибудь сложные формулы. Если только очень сильно постараться. Ну это пока. В Owen Logic ST язык очень динамично развиваается.
Принцип какой, задаем блоку имя, в нашем случае Functionblock1. Задаём входные переменные Var_input, выходные переменные Var_output.
Var — это локальные внутренние переменные ФБ.
Типы данных для Owen Logic:
Далее тело программы с логикой. Операторы те же самые, как и в Codesys. Я писал об этом статью.
Простенький пример
Когда я реализовывал досветку для автоматизации теплиц. У меня есть проект на Codesys 3.5 на ПЛК200. Мне удалось перенести несколько функции. Одна из них это TOD_IS_Between. Это функция предназначена на срабатывание выхода в определенный промежуток времени.
То есть получается почти сквозная поддержка функции из Codesys. Это просто супер!
Код выглядит следующим образом:
FromTime — временной вход ОТ
ToTime — временной вход ДО
CurrTime — часы реального времени
Функция возвращает выход True, когда часы попадают во временной промежуток ОТ и ДО.
Пишу вкратце, чтобы не отнимать много времени. Если есть вопросы, пишите в комментариях.
С функцией ПЛК разработан преобразователь частоты Delta VFD серии E. Интересная вещь. Это как один из вариантов, как можно делать простые станки без дорогостоящего контроллера.
Преобразователь DELTA VFD-E
Тайваньский преобразователь частоты с дополнительной платой расширения(3 доп. релейных выхода):
Программирование осуществляется так же, как и программируемым логическим контроллером Delta DVP с помощью софта WPLSoft.
Связь c ПК осуществляется по интерфейсу RS232.
Распиновка кабеля RJ-45
Не забываем поставить нужный режим в настройках ПЧ.
Программное обеспечение WPLSoft
С официального сайта скачиваем ПО, и производим настройки связи.
Для того чтобы связаться с ПЧ. Достаточно вот таких настроек:
Появился заказ на разработку шкафа Варочно-сушильной печи для мясных изделий. Печь сломалась и стояло оборудование на базе европейского готового контроллера с кнопочным управлением. Выглядит он следующим образом:
Это достаточно избыточный по функциям и сложный в эксплуатации термоконтроллер. Задание шагов и рецептура по факту заказчику были не нужны. Хотели, чтоб было по простому, два режима — Сушка и Варка. Задание уставки по температуре камеры и по температуре продукта.
Решили делать своими силами.
На каком оборудовании…
Искали много вариантов, много времени было потрачено. Сложность в том, что измерять влагу нужно только Психрометрическим способом. Простой датчик на 4-20 сразу же забьет жиром.
Замер ИТР — 02П не подходил, потому что по удобству эксплуатации оператора не устроило (маленький зелёный экран, не понятно куда там тыкать на кнопочки, выставлять там шаги и т.д.). Есть ещё у ОВЕНА — ТРМ 151. Но получался громоздкий и не комфортный вариант из готовых приборчиков.
Решили делать всю логику своими силами. Поставили оборудование — ПЛК100 и обвязку модулей МВ к нему.
ПЛК управляет следующими органами — ТЭНами, двухскоростным двигателем, клапаном для воды и воздушными заслонками.
Сложность модернизации была в том, чтобы найти все нужные провода и связать их между собой, вот в таком шкафу:
Условия работы были тяжелыми, так как рядом стояла коптилка и работала в штатном режиме, соотвествено чадил дым вперемешку с парами.
Вся печь была в тяжелой несмываемой копоти. Ну несмотря на трудности мы справились с задачей.
Ставили панель оператора Weintek для визуализации процесса. Панель Master — ПЛК Slave. Связь была обеспечена по протоколу Modbus TCP.
Эта статья посвящена, как просто и без мучений реализовать кнопку без фиксации. Нажал кнопку один раз сработал механизм, нажал кнопку ещё раз механизм выключился.
Приветствую всех, на связи автор блога. Часто задают вопрос по реализации кнопки без фиксации, будет посвящена коротенькая статья.
Реализация кнопки без фиксации
На официальном сайте ОВЕН нужно скачать программу последней версии. Этот кусок программы подойдёт для любого устройства реле.
Создаем новую программу и запускаем.
Самой простой способ- это загрузить нужную библиотеку с онлайн базы макросов.
Выбираем элемент ON_OFF и жмем кнопку загрузить в библиотеку проекта.
Теперь когда мы жмем кнопку без фиксации один раз запускаем механизм, жмем ещё раз выключаем.
