Создание методики построения коммуникационного объектно-ориентированного канала связи

Размещено на http://www.allbest.ru/

Создание методики построения коммуникационного объектно-ориентированного канала связи

1. Анализ проблематики построения объектно-ориентированного канала связи с ПЛК

1.1 Описание протокола Modbus

Modbus разработан фирмой Modicon (в настоящее время принадлежит Schneider Electric) для использования в контроллерах с программируемой логикой. Впервые спецификация этого протокола была опубликована в 1979 году. Это был открытый стандарт, описывающий формат сообщений и способы их передачи в сети различных электронных устройств.

Первоначально контроллеры MODICON использовали последовательный интерфейс RS-232. Позднее стал применяться интерфейс RS-485, так как он позволяет использовать более длинные линии связи и подключать к одной линии несколько устройств.

Многие производители электронного оборудования поддержали протокол Modbus, на рынке появились сотни использующих его изделий. Сейчас развитием протокола занимается некоммерческая организация Modbus-IDA. Она основана производителями и пользователями электронных приборов.

Основные понятия протокола Modbus

Modbus относится к протоколам прикладного уровня сетевой модели OSI. В соответствии с ним контроллеры взаимодействуют, используя клиент-серверную модель, основанную на транзакциях, состоящих из запроса и ответа.

Обычно в сети есть только один клиент - «главное» устройстово со статусом master, и несколько серверов - «подчиненных» (статус slave) устройств. Главное устройство инициирует транзакции (передаёт запросы). Подчиненные устройства передают запрошенные у них данные или производят указанные действия. Master может адресоваться индивидуально к slave или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Уустройство slave формирует сообщение и возвращает его в ответ на адресованный именно ему запрос. На широковещательные запросы ответное сообщение не формируется.

Основа структуры запросов и ответов протокола Modbus - элементарный пакет протокола, так называемый PDU (Protocol Data Unit). Структура PDU протокола Modbus не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции - это однобайтовое поле. Оно может принимать значения в диапазоне 1…127. Значения 128…255 зарезервированы для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU ограничен 253 байтами.

Для передачи пакета по физическим линиям связи PDU помещается в другой пакет, содержащий дополнительные поля. Этот пакет носит название ADU (Application Data Unit). Формат ADU зависит от типа линии связи.

PDU (Protocol Data Unit) - общая для всех физических уровней часть пакета MODBUS. Включает в себя код функции и данные пакета.

ADU (Application Data Unit) - полный пакет MODBUS. Включает в себя специфичную для физического уровня часть пакета и PDU.

MODBUS специфицирует 4 типа данных:

· Discrete Inputs - однобитовый тип, доступен только на чтение.

· Coils - однобитовый тип, доступен на чтение и на запись.

· Input Registers - 16-битовый знаковый или беззнаковый тип, доступен только на чтение.

· Holding Registers - 16-битовый знаковый или беззнаковый тип, доступен на чтение и на запись.

Стандарты MODBUS состоят из 3 частей:

Документ Modbus Application Protocol содержит спецификацию прикладного уровня сетевой модели OSI:

Элементарный пакет протокола, так называемый PDU (Protocol Data Unit), он един для всех физических уровней. PDU упаковывается в индивидуальный для каждого транспорта application data unit (ADU).

Коды функций и состав PDU для каждого кода.

Документ Modbus over serial line содержит спецификацию канального и физического уровней сетевой модели OSI для физических уровней RS485 и RS232. В принципе может использоваться любой физический уровень основанный на асинхронном приемопередатчике.

Документ MODBUS Messaging on TCP/IP Implementation Guide содержит спецификацию ADU для транспорта через TCP/IP стек.

Основные достоинства стандарта - открытость и массовость. Огромное количество датчиков и исполнительных устройств выпущено промышленностью. Практически все промышленные системы контроля и управления имеют программные драйвера для работы с MODBUS сетями.

Контроллеры на шине Modbus взаимодействуют, используя клиент-серверную модель, основанную на транзакциях, состоящих из запроса и ответа.

Обычно в сети есть только один клиент, так называемое, «главное» (англ. master) устройство, и несколько серверов - «подчиненных» (slaves) устройств. Главное устройство инициирует транзакции (передаёт запросы). Главный может адресоваться индивидуально к подчиненному или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Подчиненное устройство отвечает на запрос, адресованный именно ему. При получении широковещательного запроса ответ не формируется.

Спецификация Modbus описывает структуру запросов и ответов. Их основа - элементарный пакет протокола, так называемый PDU (Protocol Data Unit). Структура PDU не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции кодируется однобайтовым полем и может принимать значения в диапазоне 1…127. Диапазон значений 128…255 зарезервирован для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU ограничен 253 байтами.

Таблица 1. Modbus PDU

код функции	данные
1 байт	N < 253 (байт)

Для передачи пакета по физическим линиям связи PDU помещается в другой пакет, содержащий дополнительные поля. Этот пакет носит название ADU (Application Data Unit). Формат ADU зависит от типа линии связи. Существуют три варианта ADU, два для передачи данных через асинхронный интерфейс и один - через TCP/IP сети:

Modbus ASCII - для обмена используются только ASCII символы. Для проверки целостности используется однобайтовая контрольная сумма. Начало и конец сообщения помечаются специальными символами (начало сообщения»: «, конец сообщения CR/LF).

Modbus RTU - компактный двоичный вариант. Сообщения разделяются по паузе в линии, контроль целостности с помощью CRC.

Modbus TCP - для передачи данных через TCP/IP соединение.

Общая структура ADU следующая (в зависимости от реализации, некоторые из полей могут отсутствовать):

Таблица 2. Структура ADU

адрес ведомого устройства	код функции	данные	блок обнаружения ошибок

где

· адрес ведомого устройства - адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 - зарезервированы;

· код функции - это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство;

· данные - поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции;

· блок обнаружения ошибок - контрольная сумма для проверки отсутствия ошибок в кадре.

Максимальный размер ADU для последовательных сетей RS232/RS485 - 256 байт, для сетей TCP - 260 байт.

Для Modbus TCP ADU выглядит следующим образом:

Таблица 3. Modbus TCP ADU

ID транзакции	ID протокола	длина пакета	адрес ведомого устройства	код функции	данные

где

· ID транзакции - два байта, обычно нули

· ID протокола - два байта, нули

· длина пакета - два байта, старший затем младший, длина следующей за этим полем части пакета

· адрес ведомого устройства - адрес подчинённого устройства, к которому адресован запрос. Обычно игнорируется, если соединение установлено с конкретным устройством. Может использоваться, если соединение установлено с мостом, который выводит нас, например, в сеть RS485.

Поле контроля целостности в Modbus TCP отсутствует, т. к. целостность данных обеспечивает TCP/IP стек.

1.2 Описание возможностей CodeSys для реализации объектно-ориентированного подходапо работе с данными

CoDeSys это универсальный комплекс МЭК программирования высшего класса, немецкой компании Smart Software Solutions GmbH (3S). Комплекс CoDeSys включает специализированные редакторы МЭК языков, конфигуратор контроллера, обеспечивает поддержку промышленных сетей и многое другое. Основная его отличительная особенность это встроенный компилятор кода. МЭК программы непосредственно преобразуются в машинные коды микропроцессора. В итоге достигается очень высокое быстродействие прикладных проектов. Помимо этого, комплекс обеспечивает многозадачность в прикладных проектах (циклические и вызываемые по событиям задачи). Среда программирования имеет встроенный графический интерактивный отладчик и эмулятор, многоканальный графический анализатор, встроенную систему визуализации объекта и программы управления (на ПК, в контроллере и Web), развитый набор библиотек.

CoDeSys обладает рядом особенностей, выделяющих его среди остальных систем:

Быстрое внедрение. 3S-Smart Software Solutions может выполнить тестовую адаптацию системы исполнения (включая базовые он-лайн функции) для любой стандартной процессорной платформы не более, чем за 2 дня. CoDeSys имеет интегрированные компиляторы для большинства широко распространенных аппаратных платформ. Простота адаптации не отражается на быстродействии прикладных проектов. Компилятор и система исполнения тщательно отработаны. Все это позволяет подготовить ваши контроллеры к выходу на рынок в минимальные сроки.

Эффективные средства ввода. Функции автоматического объявления и форматирования, адаптивный Ассистент ввода максимально упрощают работу с CoDeSys. Все команды имеют возможность управления мышью и быстрого ввода с клавиатуры. Это делает работу программиста комфортной и эффективной.

Высокая производительность. Встроенный компилятор непосредственно генерирует быстрый машинный код. Это обеспечивает максимально высокую производительность прикладных проектов. Современные интеллектуальные технологии, включая «инкрементальный компилятор», позволяют обрабатывать проекты, содержащие тысячи переменных и сотни программных компонентов, очень быстро. CoDeSys обеспечивает разработчика набором высокоэффективных инструментальных средств, включая полноценную эмуляцию ПЛК, отладку по шагам, точки останова, визуализацию объекта управления, трассировку значений переменных, «горячую» корректировку кода.

CoDeSys - компоненты:

· Эмулятор ПЛК;

· Редакторы для программирования на языках:

· Список Инструкций (IL);

· Диаграммы Функциональных блоков (FBD);

· Релейно-контактные схемы (LD);

· Структурированный текст (ST);

· Последовательные функциональные схемы (SFC);

· Непрерывные функциональные диаграммы (CFC);

· DDE и OPC серверы;

· Элементы визуализации;

· Графический иерархический ПЛК конфигуратор;

· Менеджер библиотек;

Он-лайн функции:

· мониторинг значений переменных

· запись и фиксация значений переменных в ПЛК

· отладка проекта (точки останова, выполнение по шагам и по циклам, контроль стека вызовов)

· горячая коррекция кода, без остановки ПЛК

· контроль процесса выполнения

· графическая трассировка

Языки программирования:

· Список Инструкций (IL). Простой машинно-независимый ассемблер.

· Структурированный текст (ST). Высокоуровневый «Паскаль-подобный» язык.

· Функциональные блоковые диаграммы (FBD). Графический язык описания логических и аналоговых вычислений в очень простой и выразительной форме. CoDeSys автоматизирует составление FBD диаграмм самостоятельно размещая программные компоненты и соединения.

· Релейно-контактные схемы (LD). Графический язык, описывающий логику работы программы в форме соединения контактов и обмоток реле. Как и в FBD, редактор LD автоматически размещает и проводит соединения компонентов схемы.

· Последовательные функциональные схемы (SFC). Графический язык, ориентированный на описание взаимосвязанных состояний и действий системы. CoDeSys поддерживает все без исключения типы действий предусмотренные стандартом.

Непрерывные функциональные схемы (CFC). Редактор CFC аналогичен FBD, но в отличие от него не разделяет диаграмму на цепи, а оперирует со свободно размещаемыми компонентами. Диаграммы могут иметь обратные связи и настраиваемый порядок выполнения.

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

В значительной степени здесь сказываются ограниченные возможности инструментов программирования. Почти все современные контроллерные платформы дают возможность так или иначе использовать C++. Однако компилятор обеспечивает только лишь аспекты чистого программирования. Функции отладки и ввода в эксплуатацию этих систем практически непригодны для контроллерных приложений. Даже для элементарного мониторинга значений входов-выходов приходится писать вызовы библиотечных функций. О таких приёмах, как «горячая» замена кода прикладной программы без остановки контроллера, вообще нужно забыть. Помимо этого автоматы и задачи с битовыми операциями реализуются в C++ достаточно сложно.

Требования

В результате компанией 3S_Smart Software Solutions было принято решение расширить нормы стандарта МЭК 61131-3, введя поддержку ООП в новое поколение системы программирования CoDeSys. Расширения стандарта должны подчиняться следующим требованиям:

? ООП-расширения должны быть не обязательными, а опциональными;

? ООП- и не ООП-программирование можно совмещать;

? существующие приложения должны полностью поддерживаться с возможностью их плавной трансформации в ООП с учетом целесообразности;

? ООП должно быть применимо во всех языках МЭК 61131-3;

? программист не должен сталкиваться со сложными определениями.

Расширения

Основное расширение МЭК 61131_3 касается превращения функционального блока (FUNCTION_BLOCK) в класс. Подобным образом структуры выросли в классы в языке C++. Это достигается введением методов. Фактически метод - это функция, встроенная в функциональный блок. В реализации функции доступны не только значения её параметров и локальных переменных, но и данные экземпляра функционального блока. В итоге вызов метода всегда включает имена экземпляра и метода.

Помимо пользовательских методов и стандартной реализации, функциональный блок включает два предопределённых метода: Init и Exit. Init вызывается неявно для всех экземпляров всех функциональных блоков после загрузки кода приложения или «холодного» рестарта контроллера. Exit вызывается перед «горячим» обновлением кода экземпляра, перед сбросом или управляемым отключением питания ПЛК. Например, его можно применить для корректного завершения работы.

Однако реальную мощь ООП даёт возможность создания интерфейсов. Под интерфейсом понимается набор методов, работающих с одинаковыми параметрами, но разными реализациями для разных функциональных блоков. Интерфейс можно передать в качестве параметра, и программный компонент (POU) не будет в действительности заботиться о том, какой функциональный блок им применяется.

2. Построение модели объектно-ориентированного канала связи С ПЛК на основе протокола Modbus

С помощью Modbus Communication Library ПЛК использует протокол Modbus TCP и формирует запросы к подчиненным устройствам. ПЛК является master-устройством.

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

· масштабируемая аппаратная платформа.

· стандартизированные интерфейсы связи.

· опциональная возможность установки дополнительных функциональных и технологических модулей.

· идеально подходит для локальных и распределенных архитектур управления.

· индивидуальная возможность установки дополнительных высокоскоростных компонентов визуализации.

· модульные блоки входов / выходов.

IndraControl L45 - компактный модульный блок управления. Объединяет преимущества архитектуры на базе встроенного ПК со стандартизированной системой входов / выходов. Каждый модуль оснащен 8 высокоскоростными входами и выходами. В качестве интерфейсов связи предлагаются Ethernet TCP/IP, SERCOS III, PROFINET IO, EtherNet/IP, PROFIBUS DP и DeviceNet.

Таблица 4. Технические данные контроллера IndraControl L45

Технические данные
Центральный процессор CPU	совместим с x86/500 МГц
Рабочее запоминающее устройство	мин. 256 Мб
Остаточное запоминающее устройство	мин. 128 Кб
Сменное запоминающее устройство	компактная карта памяти flash/мин. 128 Мб
Часы реального времени	встроены
Дисплей	1-строчный, 4 клавиши управления
Тип защиты	IP20
Габариты (Ш x В x Г)	120 x 175 x 97,5 мм
Интерфейсы
Модули входов / выходов	Inline
Интерфейсы связи (стандартные)	1 x Ethernet TCP/IP (RJ45, 10/100 Base-T) 1 x одинарный контакт Ready
Интерфейсы связи (опциональные)	1 x SERCOS III (2 x RJ45) 1 x PROFINET IO-Master/-Slave (2 x RJ45) 1 x PROFIBUS DP-Master/-Slave 1 x сканер / адаптер EtherNet/IP (Master/-Slave) (2 x RJ45) 1 x DeviceNet-Master/-Slave
Входы/выходы (цифровые)	8 гальванически разделенных входов (для прерываний) 8 гальванически разделенных выходов
Расширение входов / выходов	с помощью макс. 63 модулей входов / выходов Inline до 512 входов / выходов (64 байта)
Функциональные модули	до 4
Подача напряжения питания
Номинальное значение	24 В постоянного тока
Допуск	-15/+20% (без учета остаточной пульсации)
Остаточная пульсация	±5%
Максимальное напряжение	30 В постоянного тока
Минимальное напряжение	19,2 В постоянного тока
Потребление тока от ULS	макс. 3 A
Потребление тока от UM + US	макс. 8 A

В основе технологии создания программного обеспечения электроавтоматики лежат обычные для объектно-ориентированного программирования понятия класса и объекта. При этом класс описывает тип оборудования, а объект - конкретный экземпляр. Таким образом, при объявлении класса, согласно принципу инкапсуляции, создаются шаблоны структур данных и методы, которые будут работать с этими данными. В объекте класса по шаблону выстраиваются конкретные данные, и приводится ссылка на обслуживающий их процесс. При появлении нового типа оборудования, благодаря механизму наследования, разработчик не нуждается в том, чтобы заново разрабатывать новый класс - достаточно выбрать наиболее близкий и реализовать отличия в новом классе. Тем самым обеспечивается простота модификаций, сокращаются затраты времени на разработку, снижается общая стоимость разработки. Наиболее важен тот факт, что объектный подход позволяет создавать хорошо структурированные сложные системы управления электроавтоматикой. Основные преимущества, приобретаемые при этом, состоят в следующем:

· повышается уровень унификации разработки; для повторного использования пригодны не только управляющие программы, но и проекты в целом, что служит хорошей основой для построения среды разработки. Снижаются затраты времени и средств на создание нового проекта;

· возникает возможность повторного использования собственных функциональных модулей и готовых модулей других разработчиков, что делает систему управления открытой. Уменьшается вероятность ошибок при разработке сложных систем, увеличивается уверенность в правильности принимаемых решений. Все эти достоинства обеспечиваются благодаря лежащим в основе объектно-ориентированной технологии принципам наследования, инкапсуляции и полиморфизма.

Структура функциональных блоков диагностики параметров технологических команд

Функциональный блок шпинделя

Функциональный блок шпинделя (рис. 5) содержит в себе информацию о работе команд группы управления шпинделем. M03/M04 - включение вращения шпинделя по/против часовой стрелки. После предустановленного времени разгона начинается отработка других функций кадра. Функция деактивируется либо командой М05 (останов шпинделя), либо командой завершения программы.

В таблице 2 представлено описание входных и выходных параметров функционального блока шпинделя.

Таблица 5. Параметры функционального блока шпинделя

Speed	Скорость вращения шпинделя(S)
Rotation	Направление вращения шпинделя
Interpolation mode	Показывает является ли шпиндель осью интерполяции
Address	Начальный адрес хранения информации
Type	Тип данного функционального блока
ID	Уникальный идентификатор
Current speed	Текущая скорость вращения
Current rotation	Текущее направление вращения
Current interpolation mode	Текущее значение Interpolation mode
State	Поле состояния команды

Функциональный блок магазина инструментов

Функциональный блок магазина инструментов (рис. 6) содержит информацию о работе команды замены инструмента. Процедура состоит в следующем: шпиндель выключается, исполнительные органы уходят в безопасную позицию, запускается машинно-зависимая процедура замены инструмента.

В таблице 5 представлено описание входных и выходных параметров функционального блока магазина инструментов.

Таблица 6. Параметры функционального блока магазина инструментов

Number	Номер инструмента(T)
Address	Начальный адрес хранения информации
Type	Тип данного функционального блока
ID	Уникальный идентификатор
Current Number	Текущий номер инструмента
State	Поле состояния команды

Функциональный блок подачи СОЖ

Функциональный блок подачи СОЖ (рис. 7) содержит информацию о работе команд группы функций охлаждения. Подача СОЖ включается с помощью функции М08, а выключается с помощью функции М09. Существует и дополнительная подача СОЖ (команда М07).

В Таблице 7 представлено описание входных и выходных параметров функционального блока подачи СОЖ.

Таблица 7. Параметры функционального блока подачи СОЖ

Address	Начальный адрес хранения информации
Type	Тип данного функционального блока
ID	Уникальный идентификатор
State	Поле состояния команды

Конфигурационный функциональный блок

Конфигурационный функциональный блок (рис. 8) содержит в себе информацию о количестве экземпляров других диагностических функциональных блоков в программе ПЛК.

В таблице 8 представлено описание входных и выходных параметров функционального блока подачи СОЖ.

Таблица 8. Параметры конфигурационного функционального блока

Spindle	Количество экземпляров ФБ шпинделя
Tool	Кол-во экземпляров ФБ магазина инструментов
Coolant	Кол-во экземпляров ФБ подачи СОЖ
Address	Начальный адрес хранения информации
Type	Тип данного функционального блока
Data Size	Размер хранимой диагностической информации

Результатом проведённой работы стала библиотека функциональных блоков, написанная на языке ST (Структурированный текст). Функциональный блок описывает тип оборудования, а объект функционального блока - конкретный экземпляр.

3. Разработка методики кроссплатформенной библиотеки для интеграции устройств на основе протокола Modbus TCP в состав приложений систем управления

Класс Master содержит в себе список контроллеров, за которыми осуществляется наблюдение. Функции AddPLC() и DeletePLС() позволяют редактировать список этих контроллеров. Контроллеры описываются классом PLC. Поле Name содержит имя контроллера, поле State отображает наличие связи с ПЛК, а поле IPAdress хранит его сетевой адрес. Связь с контроллером осуществляется средствами класса TCPConnection, который содержит в себе функции для работы с коммуникационным каналом.

Классы Configuration, Spindle, Tool, Coolant содержат в себе информацию о выполнении технологических команд получаемую от ПЛК.

Класс Spindle используется для описания работы шпинделя станка. Поле Speed содержит в себе скорость вращение шпинделя, поле Rotation направление его вращения. Поле InterpolationMode показывает, является ли шпиндель в данный момент осью интерполяции. Поле State отображает, вращается или остановлен шпиндель в данный момент. Поле Type помогает определить принадлежность экземпляра классу. Поле ID содержит в себе порядковый номер шпинделя.

Класс Tool используется для описания работы магазина инструментов. Поле Number содержит номер инструмента, который должен быть установлен в зажиме. Поле State отображает ход выполнения операции смены инструмента. Поле Type помогает определить принадлежность экземпляра классу. Поле ID содержит в себе порядковый номер магазина инструментов.

Класс Coolant используется для описания работы подачи СОЖ. Поле State отображает, идет ли подача охлаждающей жидкости в зоне обработки. Поле Type помогает определить принадлежность экземпляра классу. Поле ID содержит в себе порядковый номер вывода подачи СОЖ.

Класс Configuration содержит в себе информацию необходимую для получения диагностических данных от ПЛК. Поле Spindle содержит в себе число экземпляров функционального блока шпинделя хранящихся в памяти контроллера. Поле Tool содержит число экземпляров функционального блока магазина инструментов. Поле Coolant содержит число экземпляров функционального блока подачи СОЖ. Поле DataSize содержит размер диагностической информации хранящейся в памяти ПЛК.

Схема взаимодействия объектов для создания клиент-серверного соединения

Взаимодействие объектов представлено на диаграмме последовательности. После старта приложения Маster осуществляет попытку установки соединения с ПЛК и запрашивает конфигурационную информацию. В соответствии с полученными конфигурационными данными формируется отправляется запрос для получения информации о состоянии параметров выполнения технологических команд. После анализа полученных данных, в приложении выводится информации о ходе выполнения технологических операций на станке с ЧПУ.

Приложение

Исходный код.

Библиотека функциональных блоков:

FUNCTION_BLOCK Config

VAR_INPUT

address:POINTER TO INT;

spindle:INT;

tool:INT;

coolant:INT;

END_VAR

VAR_OUTPUT

FbType: INT:=0;

DataSize: INT;

END_VAR

VAR

END_VAR

DataSize:=spindle*12+tool*8+coolant*6;

address[0]:=FbType;

address[1]:=spindle;

address[2]:=tool;

address[3]:=coolant;

address[4]:=DataSize;

FUNCTION_BLOCK Spindle

VAR_INPUT

speed:INT;

rotation:INT;

interpolationMode: INT;

address:POINTER TO INT;

id: INT;

END_VAR

VAR_OUTPUT

FbType: INT:=1;

state:INT;

currSpeed: INT;

currRotation:INT;

currIntrepolationMode: INT;

END_VAR

VAR

END_VAR

address[0]:=FbType;

address[1]:=id;

address[2]:=state;

address[3]:=speed;

address[4]:=rotation;

address[5]:=interpolationMode;

FUNCTION_BLOCK Tool

VAR_INPUT

number:INT;

address:POINTER TO INT;

id: INT;

END_VAR

VAR_OUTPUT

FbType: INT:= 2;

currNumber:INT;

state:INT;

END_VAR

VAR

END_VAR

address[0]:=FbType;

address[1]:=id;

address[2]:=state;

address[3]:=number;

FUNCTION_BLOCK Coolant

VAR_INPUT

address:POINTER TO INT;

id: INT;

END_VAR

VAR_OUTPUT

FbType: INT:= 3;

state:INT;

END_VAR

VAR

END_VAR

address[0]:=FbType;

address[1]:=id;

address[2]:=state;

Функция установки соединения с ПЛК:

public void connect (string ip, ushort port)

{

try

{

IPAddress _ip;

if (IPAddress. TryParse (ip, out _ip) == false)

{

IPHostEntry hst = Dns. GetHostEntry(ip);

ip = hst. AddressList[0].ToString();

}

 // Connect asynchronous client

tcpAsyCl = new Socket (IPAddress. Parse(ip).AddressFamily, SocketType. Stream, ProtocolType. Tcp);

tcpAsyCl. Connect (new IPEndPoint (IPAddress. Parse(ip), port));

tcpAsyCl. SetSocketOption (SocketOptionLevel. Socket, SocketOptionName. SendTimeout, _timeout);

tcpAsyCl. SetSocketOption (SocketOptionLevel. Socket, SocketOptionName. ReceiveTimeout, _timeout);

tcpAsyCl. SetSocketOption (SocketOptionLevel. Socket, SocketOptionName. NoDelay, 1);

 // Connect synchronous client

tcpSynCl = new Socket (IPAddress. Parse(ip).AddressFamily, SocketType. Stream, ProtocolType. Tcp);

tcpSynCl. Connect (new IPEndPoint (IPAddress. Parse(ip), port));

tcpSynCl. SetSocketOption (SocketOptionLevel. Socket, SocketOptionName. SendTimeout, _timeout);

tcpSynCl. SetSocketOption (SocketOptionLevel. Socket, SocketOptionName. ReceiveTimeout, _timeout);

tcpSynCl. SetSocketOption (SocketOptionLevel. Socket, SocketOptionName. NoDelay, 1);

_connected = true;

}

catch (System.IO.IOException error)

{

_connected = false;

throw (error);

}

}

Функция формирующая Modbus пакет:

private byte[] CreateReadHeader (ushort id, ushort startAddress, ushort length, byte function)

{

byte[] data = new byte[12];

byte[] _id = BitConverter. GetBytes((short) id);

data[0] = _id[0]; // Slave id high byte

data[1] = _id[1]; // Slave id low byte

data[5] = 6; // Message size

data[6] = 0; // Slave address

data[7] = function; // Function code

byte[] _adr = BitConverter. GetBytes((short) IPAddress. HostToNetworkOrder((short) startAddress));

data[8] = _adr[0]; // Start address

data[9] = _adr[1]; // Start address

byte[] _length = BitConverter. GetBytes((short) IPAddress. HostToNetworkOrder((short) length));

data[10] = _length[0]; // Number of data to read

data[11] = _length[1]; // Number of data to read

return data;

}

Кроссплатфоменная библиотека на основе протокола Modbus

#include <stdio.h>

#include <conio.h>

#include <iostream>

#include <WinSock2.h>

#include <WS2tcpip.h>

#include «modbus.h»

using namespace std;

#pragma comment (lib, «Ws2_32.lib»)

/*

Пример общения с контроллером посредством протокола modbus

Обмен данными идёт поверх протокола TCP на основе Windows Sockets 2

Код документирован, но для более полного понимания работы WinSock2 стоит обратиться к первоисточнику:

http://msdn.microsoft.com/en-us/library/ms740673% 28VS.85% 29.aspx

*/

#define BUF_SIZE 256

int main(void)

{

WSAData wsaData;

struct addrinfo * result = NULL;

struct addrinfo * ptr = NULL;

struct addrinfo hints;

setlocale (LC_ALL, «Russian»);

/*

Инициализирует Windows Sockets.

Такая инициализация требуется во всех windows-подобных системах, включая ReactOS.

При портировании кода на UNIX-подобные системы подобная инициализация не требуется.

*/

int dResult = WSAStartup (MAKEWORD(2, 2), &wsaData);

if (dResult!= 0)

{

cout << «Не удалось инициализировать Winsock.»;

return 1;

}

 // Инициализируем структуру hints, предварительно обнулив её

ZeroMemory (&hints, sizeof(hints));

hints.ai_family = PF_INET;

hints.ai_socktype = SOCK_STREAM;

hints.ai_protocol = IPPROTO_TCP;

 // Записываем в hints адрес и порт контроллера в удобном для сокетов виде

DWORD dwRetval = getaddrinfo («10.134.163.147», «502», &hints, &result); // 192.168.129.12

if (dwRetval!= 0)

{

printf («getaddrinfo() отработала с ошибкой:%d», dwRetval);

WSACleanup();

return 1;

}

ptr = result;

 // Неосредственно создаём сокет

 //SOCKET sSocket = INVALID_SOCKET;

int sSocket;

sSocket = socket (ptr->ai_family, ptr->ai_socktype, ptr->ai_protocol);

if (sSocket == INVALID_SOCKET)

{

printf («Функция socket() отработала с ошибкой:%d», WSAGetLastError());

freeaddrinfo(result);

WSACleanup();

return 1;

}

bool contin = true;

 // Подключаемся к контроллеру

 //dResult = bind (sSocket, ptr->ai_addr, (int) ptr->ai_addrlen);

connect (sSocket, ptr->ai_addr, (int) ptr->ai_addrlen);

/* dResult = connect (sSocket, ptr->ai_addr, (int) ptr->ai_addrlen);

if (dResult == SOCKET_ERROR)

{

closesocket(sSocket);

printf («Функция connect отработала с ошибкой:%d», WSAGetLastError());

sSocket = INVALID_SOCKET;

}*/

/* if (sSocket == INVALID_SOCKET)

{

printf («Функция connect отработала с ошибкой:%d», WSAGetLastError());

WSACleanup();

return 1;

}*/

int len = 12;

/*

Составляем пакет записи данных регистров команда 0x10

*/

/* len = 17; // НУ НА САМОМ ДЕЛЕ LEN БЫЛО 10 (А-0) там пишется 9 байт

char packetForWriteSingleCoil[] =

{

/*

Заголовок MDAP

Это просто заголовок пакета

*/

 // Transaction indentifier

 // Два байта представляют собой идентификационный номер процесса передачи пакета

 // 0x00, 0x00,

 // Protocol identifier

 // Описывает пакет

 // 0x00, 0x00, // Эти два байта должны быть равны 0. Они говорят о том, что это именно modbus-пакет

 // 0x00, 0x0A, // Эти два байта описывают размер передаваемого пакета

 // Unit identifier

 // Данный байт означает номер модуля, с которым идёт обмен данными

 // 0x01, // мб 2?

/*

PDU

Собственно, вот эти данные как раз таки и нужны для выполнения конкретных действий с контроллером

*/

 // Functon code

 // Содержит номер функции, которую следует выполнить

 // 0x03,

 // Start address

 // Адрес начала, куда будем писать

 // 0x00, 0x6B, // адрес старшего-адресс младшего байта

 // Значения, которые будем писать с начала указанного адреса

 // 0x00, 0x03,

 // 0x02, // количество байт данных

 // 0x00, 0x0A, // данные старший байт данные младший байт

 // 0x01, 0x02 //CRC старший байт СRС младший байт

 // };

/*

Составляем пакет чтение

*/

len = 12; // было 7

char packetForWriteSingleCoil2 [] =

{

/*

Заголовок MDAP

Это просто заголовок пакета

*/

 // Transaction indentifier

 // Два байта представляют собой идентификационный номер процесса передачи пакета

0x00, 0x00,

 // Protocol identifier

 // Описывает пакет

0x00, 0x00, // Эти два байта должны быть равны 0. Они говорят о том, что это именно modbus-пакет

0x00, 0x05, // Эти два байта описывают размер передаваемого пакета

 // Unit identifier

 // Данный байт означает номер модуля, с которым идёт обмен данными

0x00,

/*

PDU

Собственно, вот эти данные как раз таки и нужны для выполнения конкретных действий с контроллером

*/

 // Functon code

 // Содержит номер функции, которую следует выполнить

0x04,

 // Start address

 // Адрес начала, откуда будем читать

0x00, 0x02,

 // ЧИСЛО РЕГИСТРОВ ДЛЯ ЧТЕНИЯ

0x00, 0x02,

};

 // len надо определить т. к. эта переменная является параметром send()

while(contin)

{

/*

Обмениваемся данными

*/

dResult = send (sSocket, packetForWriteSingleCoil2, len, 0);

if (dResult == SOCKET_ERROR)

{

printf («Ошибка передачи данных:%d», WSAGetLastError());

closesocket(sSocket);

WSACleanup();

return 1;

}

/*

Принимаем данные от контроллера

*/

char recvbuf [BUF_SIZE];

:ZeroMemory (recvbuf, BUF_SIZE);

dResult = recv (sSocket, recvbuf, BUF_SIZE, 0);

if (dResult > 0)

printf («\n Bytes received:%d\n», dResult);

else if (dResult == 0)

printf («Connection closed\n»);

else

printf («recv failed:%d\n», WSAGetLastError());

int i;

 // Выводим на экран заголовок MDAP, так как у него всегда фиксированный размер

printf («MBAP: \n»);

for (i=0; i<11; i++) // было 7

printf («%x», recvbuf[i]);

 // Теперь выводим остальные данные, зная их длину по заголовку MDAP

 // Длина находится в двух байтах, расположенных по адресу recvbuf+4

printf («\nOur data: \n»);

for (; i < BUF_SIZE; i++)

printf («%x», recvbuf[i]);

 // Ждём нажатия клавиши, чтобы успеть прочитать

cout << endl << «Нажмите любую клавишу для продолжения.»;

char ch = _getch();

if (ch == (char) 32)

contin = false;

}

 // Говорим, что чтение закончено

dResult = shutdown (sSocket, SD_SEND);

if (dResult == SOCKET_ERROR)

{

printf («Функция shutdown() отработала с ошибкой:%d», WSAGetLastError());

closesocket(sSocket);

WSACleanup();

return 1;

}

 // Закрываем сокет

closesocket(sSocket);

 // Деинициализируем WinSock

WSACleanup();

freeaddrinfo(result);

return 0;

}

канал связь modbus коммуникационный

Размещено на Allbest.ru