Codesys control win v3 что это
CODESYS V3.5 – это интегрированная среда разработки (IDE) приложений для программируемых контроллеров.
Демо-проекты
Название
Версия CODESYS*
Первый старт (для СПК1хх)
Функционал таргет-файлов (для СПК1хх)
Первый старт (для ПЛК210)
Функционал таргет-файлов (для ПЛК210)
* 3.5.11.5 - CODESYS V3.5 SP11 Patch 5.
* 3.5.14.3 - CODESYS V3.5 SP14 Patch 3.
Визуализация
Название
Версия CODESYS*
Примеры работы с графическими элементами
Типичные параметры графических примитивов
Комбинированное окно (Combobox)
Отображение линейки и Потенциометр
Таблица тревог (базовый пример)
Таблица тревог (расширенный пример)
Примеры решения типовых задач
Переключение экранов визуализации
Использование интерфейса фрейма
Создание мульти язычного проекта
Управление пользователями и организация парольного доступа
Дополнительные примеры
Использование русскоязычной клавиатуры
Работа с динамическими точками
Считывание координат курсора
Примеры от 3S-Smart Software Solutions GmbH
Менеджер тревог (API)
Менеджер рецептов (API)
Дополнительные элементы визуализации
* 3.5.11.5 - CODESYS V3.5 SP11 Patch 5.
Архивация
Название
Версия CODESYS*
Использование компонента OwenArchiver (базовый пример)
Использование компонента OwenArchiver (расширенный пример)
Работа с библиотекой CAA File
Работа с библиотекой CAA File
* 3.5.11.5 - CODESYS V3.5 SP11 Patch 5.
* 3.5.11.5 - CODESYS V3.5 SP14 Patch 3.
Настройка обмена
Название
Версия CODESYS*
Протокол Modbus
Опрос модулей Mx110 с использованием шаблонов
Опрос модулей Mx210 с использованием шаблонов
Опрос модулей Mx110 с использованием конфигурации
Опрос модулей Mx210 с использованием конфигурации
Настройка контроллера в режиме Modbus RTU Slave через конфигурацию
Настройка контроллера в режиме Modbus TCP Slave через конфигурацию
Настройка контроллера в режиме Modbus RTU Master через библиотеку OwenCommunication
Настройка контроллера в режиме Modbus RTU Slave через библиотеку OwenCommunication
Настройка контроллера в режиме Modbus TCP Master через библиотеку OwenCommunication
Настройка контроллера в режиме Modbus TCP Slave через библиотеку OwenCommunication
Чтение файлов с контроллера с помощью 20 функции Modbus через библиотеку OwenCommunication
Тонкости использования Codesys Control Win (Soft PLC)
Если ваш целевой ПЛК работает на операционной системе Linux, то будут некоторые отличия в том как ведут себя библиотечные функции Codesys. Это касается, к примеру, работы с последовательными портами, разделяемой памятью, файловой системой. Ниже я приведу несколько советов, которые помогут в поиске причин неправильной или неочевидной работы Soft PLC.
Вопрос: Как управлять Soft PLC?
Ответ: Прежде чем начать нужно кое-что знать о том, как управлять Soft PLC. Программный ПЛК реализован как сервис и режим его работы может быть установлен из списка служб Windows.
Доступ к управлению службами можно получить несколькими способами:
Службы Windows
Если у вас установлено несколько версий Codesys 3.5, то каждая из них по умолчанию устанавливает свою версию компонента Codesys Control Win V3.
Разница по большому счёту только в их разрядности. Доступ к службам нужен, чтобы настроить запуск необходимых вам компонентов. К примеру, если я использую в проекте 32-разрядные библиотеки, то и ПЛК выбираю 32-разрядный, переведя его службу в ручной режим управления. Этот режим необходим при отладке, чтобы при старте Soft PLC не начал выполнять программу из папки PlcLogic, которая может работать с ошибками и нагрузить ваш ПК.
Остальные службы с таким же названием, но другой версией можно также перевести в ручной режим или вообще отключить. Лучше отключить, т.к. они будут конфликтовать друг с другом при запуске.
Существует и стандартный способ управления Soft PLC через иконку в системном трее (лотке). Если ПЛК остановлен (в стоп режиме), то иконка будет серая, если он запущен, то станет цветной. На 64-разрядной версии будет нарисована соответствующая цифра.
Если среда разработки Codesys перестаёт реагировать при отладке или загрузке приложения в ПЛК, то нужно посмотреть на его состояние в системном трее. Далее либо запустить его, либо сначала остановить и потом запустить снова (перезагрузить).
Все версии дистрибутивов Codesys 3.5
Вопрос: У меня уже установлен 32-разрядный Soft PLC, но в текущем проекте используется другая версия. Что делать?
Ответ: Можно обновить устройство в проекте, поставив галочку для выбора из всего списка доступных ПЛК. Также среда разработки при загрузке проекта в ПЛК может задать дополнительный вопрос о совместимости версий и можно ли использовать имеющуюся. Отвечаем, что попробуем. Как правило, это тоже работает.
Вопрос: Где находится папка с проектом?
Ответ: Обычно здесь: C:\Program Files (x86)\3S CODESYS\GatewayPLC\PlcLogic
Вопрос: Как правильно очистить проект в ПЛК?
Ответ: Есть два способа:
Вопрос: Как правильно отлаживать проект, работающий с последовательным портом?
Ответ: Если у вас используется последовательный порт, то обычно вы открываете его для работы, но не закрываете при выходе из режима отладки. Программный ПЛК, как обычная программа, захватывает дескриптор устройства и не освобождает его. В результате при следующей попытке открыть порт вы не сможете этого сделать и получите INVALID_HANDLE в качестве результата. Чтобы этого не происходило нужно каждый раз останавливать ПЛК, полностью удалять проект и снова запустить ПЛК. Удалять проект нужно, т.к. после остановки службы освобождённый порт будет снова захвачен сохранённой программой при запуске ПЛК. Вероятно это можно как-то автоматизировать.
То же происходит и в Linux, где можно заметить, что дескриптор получаемого устройства при постоянном входе в режим отладки инкрементируется, т.е. не освобождается с предыдущего сеанса. Но Linux не на столько жесток к обычным пользователям. Доступ к порту вы получите.
Вопрос: Как нумеруются порты в Windows?
Ответ: Если для доступа к последовательному порту используется библиотека SysCom, то в функции открытия вы можете использовать свои константы типа: COM1: byte := 1, COM2: byte := 2 и т.д.
Вопрос: Поддерживаются ли нестандартные скорости при работе с последовательным портом?
Ответ: Да, поддерживаются, но из типового их перечня. Вы можете определить свою, например так: SYS_BR_2400: dword := 2400.
Объектно-ориентированное программирование CDS V3
История «Священной войны» сторонников процедурного подхода против сторонников объектно-ориентированного подхода насчитывает более 3-х десятков лет. Объектно-ориентированное программирование, впервые появившись в 1967 году в языке Симула, резко набрало обороты и уступало процедурному подходу только в области системного программирования. В программировании ПЛК в силу консервативности этой области до сих пор понятия ООП были неприменимы. Стандарт МЭК предоставлял нам статический надежный, проверенный временем программный компонент – Функциональный блок (ФБ). ФБ формировал хорошую основу для развития его до классического понятия класса. Этот шаг был совершен в 3-й версии CoDeSys, который предоставил программистам ПЛК новый инструмент - ООП, тем самым открыв новую площадку для “Holy War”. Но это все лирика. Давайте перейдем к практике и рассмотрим объектный подход на примерах.
Итак, постановка задачи:
Представим, что у нас есть гостиница с тремя типами номеров: простой, полулюкс и люкс. В простом номере ночью загорается одна лампочка общего освещения, днем она гаснет. В полулюксе ночью загорается лампочка общего освещения и дополнительного освещения. Днем также все лампочки гаснут. В номере люкс помимо основного и дополнительного освещения присутствует климатическая установка, которая поддерживает разную температуру ночью и днем.
Объектно-ориентированный подход решения:
Сначала мы создаем класс простых комнат и описываем логику работы (включение и выключение) с одной лампочкой. Затем класс простых комнат наследуем в новый класс – класс комнат полулюкс, где дополняем код описанием логики дополнительной лампочки, логика основной лампочки наследуется от предка, и описывать её уже не надо. И в конце класс комнат полулюкс наследуем в класс комнат люкс, где добавляем методы работы с климатической установкой, лампочки в последнем классе нам программировать не придется, они были описаны в классах-предках, и в классе люкс мы их получаем по наследству.
Людям, которые сталкивались с ООП, может показаться искусственным некоторые приемы, которые мы рассмотрим ниже. Но мы сразу оговоримся, что задача учебно-ознакомительная, цель которой показать существующие механизмы, а методы применения этих механизмов мы оставим на выбор программистам.
Запускаем CoDeSys 3.3 и создаем новый Standard Project. Указываем Device: CoDeSys SP Win V3, язык ST. После этих действий получаем новый пустой проект (рис. 1).
Рис 1. Главное окно CoDeSys 3.3.
Наша первоначальная задача - создать класс простых комнат.
Все комнаты обладают методами включения и выключения лампочки и методами, описывающими операции днем (выключение лампы) и ночью (включение лампы). Эти методы должны быть внешними для того, чтобы мы могли обращаться к ним вне объекта. Выведем эти методы в отдельные интерфейсы, которые реализуем в классах комнат.
Для этого создадим интерфейс ILight, который определит методы работы с лампочкой, и интерфейс IRoom, который определит операции дня и ночи в комнате.
В левой части окна рис. 1 на ветке Application щелкаем Левой Клавишей Мышки (ниже сократим последние три слова этой фразы, как ЛКМ) и в выпадающем меню выбираем Add Object. Откроется окно добавления новых объектов к проекту (рис. 2). На всякий случай отметим, что это объекты - элементы самой системы CoDeSys, и их не надо путать с объектами, которые мы описываем и создаем в проекте.
Рис 2. Окно добавления объектов CoDeSys.
В левой части выбираем Interface, в правой части задаем Name ILight, нажимаем Open.
После этих действий в дереве вкладки Devices появится новый элемент – интерфейс ILight (рис. 3)
Рис 3. Интерфейс ILight.
Теперь нам требуется определить в этом интерфейсе методы, которые будут работать с лампочкой. Определим два метода – это SetLight, который будет включать, и выключать лампочку и метод GetLight будет сообщать нам текущее состояние лампочки. Последний метод нам нужен для соблюдения правил инкапсуляции («некрасиво» обращаться к переменным объекта напрямую, не используя методы этого объекта, да и некоторые объекты этого не позволяют).
Добавим эти методы в интерфейс. Для этого щелкаем ЛКМ на этом интерфейсе и выбираем Add Object. Обращаем внимание на новое содержание уже знакомого нам окна добавления объектов (рис. 4).
Рис 4. Добавление методов в интерфейс.
Выбираем Method, задаем имя SetLight и устанавливаем возвращаемый тип bool (тут можно воспользоваться ассистентом ввода – кнопка правее Return Type). Вообще, в нашем примере нам возвращаемый тип понадобится только в методах Get, но отдавая дань традициям ООП (внешние методы должны возвращать хотя бы код ошибки выполнения этого метода) мы введем bool и использовать будем по необходимости.
Нажимаем Open.
В дереве объектов главного окна в ветке интерфейса появляется метод, а в центре окна открывается текстовая часть описания метода на ST Рис. 5.
Рис 5.Метод в интерфейсе.
В тестовой части в секцию VAR_INPUT добавим переменную b:bool; , которая будет получать и устанавливать состояние лампочки. Реализация методов всех интерфейсов будет происходить в классах.
Аналогично методу SetLight добавляем метод GetLight с возвращаемым типом bool (рис. 6).
Рис 6.Метод GetLight в интерфейсе ILight.
Следующим шагом сделаем интерфейс IRoom и добавим в него методы OperationDay и OperationNight (рис. 7). Оба метода возвращают bool.
Рис 7.Интерфейс IRoom.
Теперь у нас есть необходимые методы для описания первого класса простых комнат.
На ветке Application ЛКМ и в выпадающем меню выбираем Add Object. Тут выбираем POU, задаем имя, тип POU – Function Block, язык реализации ST. Ставим галочку Implements и в поле правее через запятую пишем названия интерфейсов, которые мы хотим реализовывать в данном классе (Рис. 8).
Рис 8.Создание класса простых комнат RoomType1.
На рис. 8 мы видим два поля выбора языка реализации. Первый Method implementation language задает язык реализации Методов класса. Второй Implementation language задает язык реализации функционального блока (ФБ), если этот ФБ будет использоваться как ФБ, а не как Класс.
Нажимаем Open и видим, что в дереве Devices появился ФБ с автоматически включенными методами вышеописанных интерфейсов. ФБ с методами представляет собой Класс. Обратим внимание: входной параметр b:bool метода SetLight нового класса RoomType1 был также автоматически взят из описания интерфейса (Рис. 9).
Рис 9.Класс простых комнат RoomType1.
Теперь нам нужна сама лампочка, введем переменную bLight, опишем ее работу, и пропишем работу этой лампочки в операциях дня и ночи. Двойным щелчком правой КМ на имени класса RoomType1 во вкладке Devices попадаем в окно редактора, где в верхней части опишем переменные (свойства), а нижнюю часть, предназначенную для реализации ФБ, трогать не будем.
Таким образом, в секцию VAR введем нужную нам лампочку - переменную bLight типа bool.
Рис 10.Свойства Класса RoomType1.
Переходим к реализации методов. Двойным щелчком по имени метода в классе (не в интерфейсе) переходим в редактор, где будем реализовывать методы. Начнем сверху вниз. Первым идет SetLight который получает входной параметр b и присваивает его bLight.
Рис 11.Реализация метода SetLight в классе RoomType1.
Следующий метод GetLight просто возвращает значение переменной bLight.
Рис 12.Реализация метода GetLight в классе RoomType1.
Метод OperationDay выключает лампочку.
Рис 13.Реализация метода OperationDay в классе RoomType1.
Метод OperationNight включает лампочку.
Рис 14.Реализация метода OperationNight в классе RoomType1.
Все, класс простых комнат готов. Можем приступать к созданию объектов и использованию оных.
Отредактируем PLC_PRG (аналогичным образом как редактировали методы), как показано на рис 15.
Рис 15.Описание PLC_PRG.
В строке 3 верхней части окна мы создали экземпляр (объект) r1 класса RoomType1.
В строке 4 ввели переменную Day, которая будет объявлять время суток. Закат и восход солнца будет производиться вручную.
В нижней части окна реализована логика: если день, то выполняем операции дня этого объекта, если ночь - соответственно операции ночи.
Запускаем проект и проверяем работу!
Рис 16.Окно PLC_PRG запущенного проекта.
Тут мы видим, что изначально у нас ночь (Day=FALSE) и лампочка горит (bLight=TRUE). Двойным щелчком мышки в поле Prepared value в строке переменной Day устанавливаем TRUE и производим запись этого значения в переменную нажав Ctrl+F7. Замечаем, что переменная bLight стала FALSE – свет выключился с восходом солнца.
Останавливаем проект Online->Stop Application и отключаемся от устройства.
На данный момент, мы сделали класс простых комнат и поработали с объектом этого класса.
Следующим действием будет создание класса комнат полулюкс путем наследования класса простых комнат и дополнением методов работой лампы дополнительного освещения. Это будет проще, чем то что мы уже делали.
Создаем новый класс (добавляем в дерево вкладки Devices новый ФБ как RoomType1) RoomType2 рис 17. Выбираем галочку Extend и указываем в поле правее наследуемый класс RoomType1.
Рис 17.Добавление класса с наследованием.
После нажатия Open появится новый класс RoomType2 не содержащих (на первый взгляд) в своем составе методов. В действительности же этот класс имеет все свойства и методы родительского класса RoomType1, т.е. так же неявно имеет переменную bLight и может с ней работать теме же методами что и класс предок. Нам остается добавить только дополнительную лампочку. По аналогии добавления свойств (bLight) в классе RoomType1 добавим bAdditionalLight:bool; в RoomType2 (рис. 18).
Рис 18. Добавление дополнительного освещения.
За включение и выключение лампы отвечает метод SetLight. Нам требуется научить его включать дополнительное освещение. Для этого добавим этот метод, как новый в RoomType2, но с тем же названием, с тем же возвращаемым типом и с тем же входным параметром. В тело метода добавляем две строки, как на рис. 19.
Рис 19. Переписанный метод SetLight в классе RoomType2.
Первая строка в теле метода вызывает метод SetLight предка с параметром b. Метод предка включит основную лампочку. Вторая строка включает дополнительное освещение.
Таким образом, тот же самый метод SetLight в классе RoomType2 включает 2 лампочки.
Все, класс комнат полулюкс готов. Добавим объект этого класса в PLC_PRG и проведем те же эксперименты, переключая переменную Day (рис. 20 и рис. 21).
Рис 20. Добавление объекта класса RoomType2.
Рис 21. Работа объектов в исполняемом проекте.
Как хорошо видно на рис. 21, в комнате r2 синхронно зажигаются две лампочки. Одна лампочка - доставшаяся по наследству bLight, вторая - добавленная нами.
Итак, мы вышли на финишную прямую и приступаем к созданию самого сложного класса - комнат люкс. Мы создадим интерфейс ITemperature который будет содержать методы работы с климатической установкой. Метод SetTemperature с входным параметром типа INT будет устанавливать требуемую температуру. Метод GetTepmerature будет возвращать значение температуры типа INT. Так же сделаем это, как сделали до этого ILght и IRoom (рис 22). Только не забудем остановить работающий проект и отключиться от Симулируемого Девайса.
Рис 22. Добавление интерфейса климатической установки.
При создании метода GetTemperature возвращаемый тип должен быть INT - не забываем про это.
Теперь у нас есть интерфейс Климатконтроля. Создаем Класс Люкс RoomType3, наследуя RoomType2 и реализуя интерфейс ITemperature (рис. 23).
Рис 23. Добавление Класса комнат люкс.
После этого мы добавляем Методы OperationDay и OperationNight для включения в них логики работы климатической установки – аналогично добавлению дополнительного освещения в классе полулюкс. Точно так же как bAdditionalLight в RoomType2 добавляем iTemp:int; (поддерживаемая температура в комнате) в RoomType3 (рис. 24).
Рис 24. Класс RoomType3.
Опишем методы (рис. 25-28)
Рис 25. Метод SetTemperature класса RoomType3.
Рис 26. Метод GetTemperature класса RoomType3.
Рис 27. Метод OperationDay класса RoomType3.
Рис 28. Метод OperationNight класса RoomType3.
В последних двух методах в первых строках происходит включение и выключение обоих ламп методами предка - RoomType2. Во вторых строках устанавливается предпочитаемая температура днем и ночью.
Класс комнат люкс готов.
Добавляем объект в PLC_PRG так же, как мы это делали прежде, и запускаем проект (рис. 29).
Рис 29. Пример рабочего проекта со всеми классами.
Все три класса мы создали и можем теперь порождать объекты в любом количестве и любого класса. Объекты с любым общим интерфейсом можем объединять в массивы для удобства использования. К примеру, в нашем случае три разных комнаты, мы можем их создать множество и обращаться к объектам в цикле (Рис. 30).
Рис 30. Объединение объектов по общему интерфейсу.
Можем объединить все объекты-комнаты в одном объекте (этаж) и работать со всеми комнатами одними методами.
Особенности ПО для программирования и конфигурирования ПЛК CODESYS
В соответствии со стандартом МЭК 61131-3 CODESYS поддерживает 5 языков программирования:
- IL (Instruction List) – язык, по синтаксису схожий с языком низкого уровня Ассемблер.
- ST (Structured Text) – текстовый язык, похожий на Pascal.
- LD (Ladder Diagram) – язык релейно-лестничных схем.
- FBD (Function Block Diagramm) — язык функциональных блоков.
- SFC (Sequental Function Chart) – язык диаграмм, похожих на блок-схемы.
Кроме этих языков CODESYS включает в себя еще один язык – CFC (Continuous Function Chart). Он похож на FBD, но позволяет располагать функциональные блоки свободно на экране и задавать порядок их выполнения.
Первая версия CODESYS увидела свет в 1994 году. С тех пор CODESYS обрел огромную популярность среди пользователей и производителей ПЛК. На данный момент сотни производителей выпускают тысячи моделей контроллеров на базе CODESYS.
CODESYS очень удобен для программиста.
- Тот, кто раньше делал релейные схемы, легко сможет их адаптировать для ПЛК в языке LD.
- Программисты высокого уровня по достоинству оценят язык ST, который для них будет понятным и доступным.
- Разветвленные алгоритмы с четкой последовательностью действий удобно реализовывать с помощью SFC.
- А если человек ни разу не сталкивался с программированием, то возможно стоит начать с FBD или CFC.
Единожды изучив среду программирования, вы будете уметь программировать огромное количество контроллеров, основанных на CODESYS.
ПО CODESYS для программирования ПЛК
CODESYS («кодесис») – комплексный инструмент для программирования промышленных контроллеров (ПЛК).
CODESYS v3 – это совершенно новая разработка. В основу CODESYS v3 положен модульный принцип, который позволяет дополнять систему посредством подключения дополнительных модулей.
Единожды изучив среду программирования, вы будете уметь программировать огромное количество контроллеров, основанных на CODESYS.
Описание ПО для программирования и конфигурирования ПЛК CODESYS
CODESYS – это не только среда программирования — это целый комплекс средств по работе с промышленным оборудованием. Он включает собственный OPC-сервер, графический редактор для создания визуализаций, менеджер рецептов, лог аварий и многое другое. На данный момент выпускаются контроллеры на базе двух версий CODESYS: версия 2 и версия 3.
CODESYS v2 поддерживается производителем только в режиме исправления ошибок. Новые функции в него уже не добавляются. Тем не менее, функционала CODESYS v2 достаточно для подавляющего большинства задач. К тому же он требует меньше ресурсов ПЛК и компьютера.
CODESYS v3 – это совершенно новая разработка. В основу CODESYS v3 положен модульный принцип, который позволяет дополнять систему посредством подключения дополнительных модулей.
Основные отличия СODESYS v3 от v2:
- Поддержка элементов Объектно Ориентированного Программирования (ООП).
- Новый язык программирования UML (Unified Modelling Language), тесно связанный с ООП.
- Сети ПЛК — инструмент управления в одном проекте несколькими контроллерами.
- Управление системами движения (CODESYS SoftMotion).
- Оптимизация программного кода (сложные конструкции типа IF … END_ IF можно «сворачивать» для упрощения просмотра кода).
- Обновленный и улучшенный менеджер визуализаций. Появились стили визуализаций, которые позволяют изменить оформление проекта в один клик, а также существенно расширилась библиотека графических элементов.
И это лишь немногие изменения, которые принесла третья версия CODESYS. Таким образом, CODESYS v3 аккумулировал в себе многие тенденции современной промышленной автоматизации и продолжает регулярно обновляться, обзаводясь всё новыми и новыми функциями.
О тенденциях в промышленных сетях
С тех пор, как в 1979 году появился протокол Modbus, он стал де-факто стандартом промышленной сети. Изначально он был спроектирован для использования с последовательными интерфейсами RS-232/RS-485. Позже практически без изменений он «перекочевал» в сети Ethernet в виде протокола Modbus TCP.
Всемирная популярность протокола Modbus обусловлена несколькими причинами:
- Протокол является полностью открытым, его спецификация доступна всем. При этом нет необходимости в специальных интерфейсных микросхемах для реализации.
- Реализация Modbus очень проста на программном уровне.
- Дешевая среда передачи (обычная витая пара).
- Высокая надежность передачи данных благодаря использованию в каждой посылке контрольной суммы.
При разработке протокол был рассчитан на потребности и вычислительные возможности оборудования того времени. Многие актуальные для сетей нынешнего времени вопросы учтены не были:
- Это низкая пропускная способность шины.
- Отсутствие какой-либо начальной инициализации системы. Пользователю вручную придется настраивать каждое устройство перед включением его в сеть (а именно задавать ему адрес, скорость обмена и т.д.).
- Дешевая среда передачи (обычная витая пара).
- В стандарте четко прописано использование только двух типов данных: BOOL и WORD. Соответственно, при передаче других типов данных зачастую возникают разночтения между устройствами разных производителей.
Стремление к развитию промышленных сетей привело в появлению в 2003 году стандарта EtherCAT.
Основой EtherCAT является технология Ethernet, что позволяет использовать все преимущества данной технологии.
Читайте также: