Решим задачу за 30 минут!
Опубликуй вопрос и получи ответ со скидкой 20% по промокоду helpstat20
Данная работа не уникальна. Ее можно использовать, как базу для подготовки к вашему проекту.

Содержание

Введение

1. Работа с протоколом Modbus RTU

Изучение протокола Modbus RTU

Работа с последовательным портом в среде Visual Studio C#.

Тестирование работы протокола Modbus RTU в режиме Slave

2. Работа с ПЛК ОВЕН.

Описание и технические характеристики ОВЕН ПЛК100

Описание GSM/GPRS модем ОВЕН ПМ01

Работа Овен ПЛК 100 через GSM модем ПМ01

Заключение

Список литературы

Введение

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

Задачи практики:

· Получить общее представление о направлениях в деятельности конкретного предприятия, изучить его структуру и основные функции.

· Ознакомиться с формами и методами деятельности основных отделов организации.

· Выполнить намеченный объем заданных работ.

· Подготовить отчет о проделанной работе.

1. Работа с протоколом Modbus RTU

Изучение протокола Modbus RTU

Приведем краткое описание протокола MODBUS/RTU с передачей данных по последовательному интерфейсу.

Модель OSI протокола ModBus/RTU представлена в таблице 1.

Таблица 1 – Модель ISO/OSI протокола ModBus/RTU

Уровень

Модель ISO/OSI

7

Прикладной уровень

прикладной уровень ModBus

6

Представительский уровень

5

Сеансовый уровень

4

Транспортный уровень

3

Сетевой уровень

2

Канальный уровень

протокол последовательного интерфейса ModBus

1

Физический уровень

EIA/TIA-485 (RS-485) или EIA/TIA-232 (RS-232)

1. Физический уровень

В качестве среды передачи данных используется двухпроводный (полудуплексный) или четырехпроводный (дуплексный) дифференциальный интерфейс TIA/EIA-485 (TIA/EIA-422). Требования к параметрам среды передачи данных приведены в стандарте ANSI/TIA/EIA-485-A-98.

2. Канальный уровень

Канальный уровень обеспечивает создание, передачу и прием кадров данных. Этот уровень обслуживает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов.

Протокол MobBus является протоколом типа “ведущий-ведомый”, т.е. в одно и то же время к шине подключено может быть только одно ведущее устройство (мастер) и один или несколько (до 247) ведомых устройств (слейвы). Передача данных инициируется всегда ведущим устройством. Ведомые устройства могут отвечать отвечают только на запросы ведущего.

Ведущее устройство единовременно может инициировать запросы к конкретному ведомому устройству (unicast mode) или всем ведомым устройствам (broadcast mode – широковещательный запрос). Ведомые устройства сети не отвечают на широковещтельные запросы, а только принимают их. Для передачи широковещательных запросов используется адрес 0. Протокол ModBus предполагает использование адресов ведомых устройств в диапазоне 1-247 Каждое устройство в сети должно иметь уникальный адрес.

Формат данных протокола ModBus/RTU представлен на рисунке 1.

Рисунок 1 – Формат данных

Посылка каждого байта начинается со старт-бита, после которого следуют 8 бит данных, бит четности (even) и стоп бит. Таким образом, одна посылка данных состоит из 11 бит.

Для согласования со сторонними изделиями, возможна работа без бита четности, при этом должны использоваться два стоп-бита, как указано на рисунке 2.

Рисунок 2 – Альтернативный формат данных

Обмен данными по протоколу производится фреймами пакетами (данных). Структура фрейма приведена на рисунке 3.

Рисунок 3 – Структура фрейма

Фрейм начинается с посылки адрес устройства, к которому отправляется запрос (или адрес устройства, которое формирует ответ). Диапазон возможных значений адресов: 0-247. Адрес 0 (нулевой) является широкополосным и предназначен для передачи информации всем устройствам в сети. Запрос с нулевым адресом устройства не предполагает ответа.

После передачи адреса следует байт функции, определяющий функциональную принадлежность запроса (ответа). Диапазон возможных значений: 0 – 255.

После передачи Функции следует передача данных. Передача данных осуществляется побайтно. Количество передаваемых байт – 0…252.

После передачи данных следует два байта контрольной суммы, предназначенных для проверки достоверности принимаемой информации.

В соответствии с протоколом ModBus/RTU, длина фрейма может быть переменной, не более 256 байт. Передача байт данных в пределах фрейма производится последовательно с промежутком времени между передачей не более 1,5 времени передачи одного байта данных.

В протоколе используется повременная синхронизация начала и завершения передачи. Диаграмма передачи фреймов приведена на рисунке 4.

Рисунок 4 – Диаграмма передачи фреймов

Перед началом передачи очередного фрейма, необходима выдержка времени, соответствующая 3,5 временам передачи одного байта данных (t3,5) после завершения передачи предыдущего фрейма (или “ложной” передачи данных).

Завершение передачи фрейма является отсутствие передачи данных в течении 1,5 времени передачи одного байта данных (t1,5). Однако, если по истечении времени t1,5 в течение времени t3,5 возобновится передача данных, то фрейм считается недостоверным.

Все устройства в сети должны иметь один формат передачи данных и одну скорость передачи данных. Рекомендуемая скорость передачи данных – 19,2 кБит/c. Допускается передача данных на скоростях 9,6 кБит/c, 57,6 кБит/c, 115,2 кБит/c.

Для определения достоверности принимаемых данных используются:

– контроль бита четности при передаче каждого байта (аппаратная функция приемопередатчика);

– подсчет и сравнение контрольной суммы CRC (Cyclical Redundancy Checking) при передаче фрейма.

Контрольная сумма состоит из 2-х байт в формате [MSB(старший байт)|LSB(младший байт)].

Контрольная сумма подсчитывается и добавляется в конец фрейма передающим устройством, и сравнивается принимающим устройством с контрольной суммой, подсчитанной им по принятым данным. В подсчете контрольной суммы используются все байты фрейма, начиная с первого (адреса).

Подсчет контрольной суммы производится следующим образом:

1) Записывается в 16-ти битный регистр CRC число 0xFFFF.

2) Первому байту данных и регистру CRC применяется функция XOR, результат помещается в CRC регистр;

3) Регистр CRC сдвигается вправо на 1 бит, старший бит CRC регистра устанавливается в 0. Проверяется сдвинутый бит CRC регистра.

4) Если сдвинутый бит CRC регистра равен 1, то CRC регистру и полиномиальному числу (например 0xA001) применяется функция XOR;

5) Выполняются пункты 3,4, пока не будет выполнено 8 сдвигов CRC регистра;

6) Следующему байту данных и регистру CRC применяется функция XOR, результат помещается в CRC регистр;

7) Повторяются действия по пунктам 3-6 для оставшихся данных.

8) Контрольная сумма передается в фрейме младшим байтом вперед, т.е. в формате LSB|MSB

Возможна также табличная форма подсчета контрольной суммы, что значительно ускоряет процесс подсчета.

Класс подсчета CRC16 на языке C# имеет вид:

public static class CRCStuff

{ static byte[] crcHi = {

0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,

0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,

0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,

0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41,

0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81,

0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,

0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,

0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,

0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,

0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,

0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,

0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,

0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,

0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,

0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,

0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40 };

static byte[] crcLo = {

0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4,

0x04, 0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09,

0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD,

0x1D, 0x1C, 0xDC, 0x14, 0xD4, 0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3,

0x11, 0xD1, 0xD0, 0x10, 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7,

0x37, 0xF5, 0x35, 0x34, 0xF4, 0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A,

0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29, 0xEB, 0x2B, 0x2A, 0xEA, 0xEE,

0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C, 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26,

0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0, 0xA0, 0x60, 0x61, 0xA1, 0x63, 0xA3, 0xA2,

0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA5, 0x65, 0x64, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F,

0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68, 0x78, 0xB8, 0xB9, 0x79, 0xBB,

0x7B, 0x7A, 0xBA, 0xBE, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB5,

0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0, 0x50, 0x90, 0x91,

0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9C, 0x5C,

0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B, 0x99, 0x59, 0x58, 0x98, 0x88,

0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,

0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80,

0x40 };

public static byte[] calculateCRC(ref byte[] messageArray, int dataLength)

byte usCRCHi = 0xFF;

byte usCRCLo = 0xFF;

byte[] returnResult = { 0x00, 0x00, 0x00 };

int index = 0;

int messageIndex = 0;

while (dataLength > 0)

index = usCRCLo ^ messageArray[messageIndex];

usCRCLo = Convert.ToByte(usCRCHi ^ crcHi[index]);

usCRCHi = crcLo[index];

messageIndex++;

dataLength–;

//0th item is crcLo

returnResult[0] = usCRCLo;

//1st item is crcHi

returnResult[1] = usCRCHi;

//2nd item is the total CRC16.

return returnResult;

public static bool checkCRC(ref byte[] messageToCheck, int numberOfBytes)

{

byte[] calculatedCRC;

calculatedCRC = calculateCRC(ref messageToCheck, numberOfBytes – 2);

if (calculatedCRC[0] == messageToCheck[numberOfBytes – 2] && calculatedCRC[1] == messageToCheck[numberOfBytes – 1]) return true;

return false;

}

}

3. Прикладной уровень

Прикладной уровень Modbus основан на запросах с помощью кодов функций. Код функции указывает ведомому устройству, какую операцию оно должно выполнить. При использовании протокола прикладного уровня с различными протоколами транспортного и канального уровня сохраняется неизменным основной блок Modbus- сообщения, включающий код функции и данные (этот блок называется PDU – protocol data unit – элемент данных протокола). К блоку PDU могут добавляться дополнительные поля при использовании его в различных промышленных сетях, и тогда он называется ADU – application data unit – элемент данных приложения.

Стандартом Modbus предусмотрены три категории кодов функций: установленные стандартом, задаваемые пользователем и зарезервированные.

Коды функций являются числами в диапазоне от 1 до 127, причём коды в диапазоне от 65 до 72 и от 100 до 110 относятся к задаваемым пользователем функциям. Коды в диапазоне от 128 до 255 зарезервированы для пересылки кодов ошибок в ответном сообщении. Код 0 не используется.

Коды ошибок используются ведомым устройством, чтобы определить, какое действие предпринять для их обработки. Значения кодов и их смысл описаны в стандарте на Modbus RTU.

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

Если ведомое устройство нормально выполнило принятую от ведущего функцию, то в ответе поле «Код функции» содержит ту же информацию, что и в запросе. В противном случае ведомый выдаёт код ошибки. В случае ошибки код функции в ответе равен коду функции в запросе, увеличенному на 128.

Конкретное содержание поля данных устанавливается стандартом для каждой функции отдельно. В некоторых сообщениях поле данных может иметь нулевую длину.

Перечень используемых функций протокола ModBus/RTU приведены в таблице 2. Весь перечень функций приведен в MODBUS Application Protocol Specification V1.1b3.

Таблица 2 – Перечень используемых функций протокола ModBus/RTU

Тип адресации

Описание функции

Код функции (hex)

Битовая адресация

Чтение дискретных входов

0x2

Чтение состояния релейных выходов

0x1

Запись состояния одного релейного выхода

0x5

Запись состояния нескольких релейных выходов

0xF

16-битная адресация

Чтение регистров данных

0x4

Чтение регистров параметров

0x3

Запись одного регистра параметров

0x6

Запись одного нескольких регистров параметров

0x10

Работа с файловыми записями

Чтение данных файла

0x14

Запись данных файла

0x15

Диагностические данные

Чтение ID (серийного номера)

0x11

Коды ошибок:

0x1 – ошибка функции

0x2 – ошибка адреса данных

0x3 – ошибка значения данных

0x4 – ошибка обработки данных устройством

0x8 – ошибка четности данных файла (для функций 0x14, 0x15)

Работа с последовательным портом в среде Visual Studio C#

В среде .Net 2.0 (и в более поздних версиях .NET) компания Microsoft добавила поддержку последовательного порта включением класса SerialPort как части пространства имен System.IO.Ports. Пространство имен System.IO.Ports содержит классы для управления последовательными портами. Наиболее важный класс SerialPort предоставляет средства для синхронного и управляемого событиями ввода-вывода, доступа к состоянию подключения-отключения устройства, а также для доступа к свойствам драйвера последовательного порта.

Чтобы создать экземпляр класса SerialPort class, необходимо передать опции SerialPort конструктору класса:

Все опции для последовательного устройства могут быть отправлены через конструктор класса SerialPort

// —- PortName = “COM4”, Baud Rate = 9600, Parity = None,

// —- Data Bits = 8, Stop Bits = One, Handshake = None

SerialPort _serialPort = new SerialPort(“COM4”, 9600, Parity.None, 8, StopBits.One);

_serialPort.Handshake = Handshake.None;

// Открытие последовательного порта

//Считываение из входного буфера SerialPort определенного число байтов и их запись в //байтовый массив, начиная с указанной позиции.

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

Формирование ответного сообщения Мастеру происходит в функции createRespondMessage, эта функция имеет вид:

private byte[] createRespondMessage()

{

int numberOfPoints = 0;

int bytesToSend = 0;

int startAddress = 0;

numberOfPoints = (_messageReceived[4] << 8) | _messageReceived[5];

bytesToSend = 5 * numberOfPoints + 2;

byte[] respondMessage = new byte[bytesToSend];

respondMessage[0] = _slaveAddress;

respondMessage[1] = 3;

respondMessage[2] = Convert.ToByte(2 * numberOfPoints);

startAddress = (_messageReceived[2] << 8) | _messageReceived[3];

int j = 0;

for (int i = 0; i < numberOfPoints; i++)

{

respondMessage[i + j + 3] = Convert.ToByte((_registerData[startAddress + i] >> 8)& 0xff);

respondMessage[i + j + 4] = Convert.ToByte(_registerData[startAddress + i] & 0xff);

j++;

}

byte[] crcCalculation = CRCStuff.calculateCRC(ref respondMessage, bytesToSend – 2);

respondMessage[bytesToSend – 2] = crcCalculation[0];

respondMessage[bytesToSend – 1] = crcCalculation[1];

return respondMessage;

}

Тестирование работы протокола Modbus RTU в режиме Slave

программируемый логический контроллер фрейм

Описание пользовательских функций, поддерживаемых “Системой бесперебойного питания” при подключении по протоколу Modbus RTU:

0 – светодиот питание от сети

1 – светодиот питание от АБ

2 – светодиот питание от байпас

3 – светодиот авария

4 – надпись питание от дистр. сети

5 – питание от альтернативной сети

6 – питание от локальной сети

7 – питание от акб.

8 – заряд аб от дистриб. сети

9 – заряд аб от альтернативной сети

10 – заряд аб от локальной сети

11 – продажа энергии АБ в локальную сеть

12 – продажа энергии АИ в локальную сеть

Зададим параметры функций (см. Рисунок 5).

Рисунок 5 – Значения функций

Результат работы протокола Modbus RTU представлены на рисунке 6.

Рисунок 6 – Результат работы

2. Работа с ПЛК ОВЕН

ОВЕН ПЛК100 – Программируемый логический контроллер

Программируемый логический контроллер ОВЕН ПЛК100 предназначен для создания систем автоматизированного управления технологическим оборудованием в энергетике, на ж/д транспорте, в различных областях промышленности, жилищно-коммунального и сельского хозяйства, на опасных производственных объектах (например Котлонадзора), подконтрольных органам Ростехнадзора.

Логика работы ПЛК100 определяется потребителем в процессе программирования контроллера. Программирование осуществляется с помощью системы программирования СоDеSуs 2.3.8.1 и старше.

ПЛК100-220.Р-L – контроллер с номинальным напряжением питания 220 В переменного тока, оснащенный э/м реле и имеющий лицензионное ограничение размера области ввода-вывода в 360 байт.

Технические характеристики ПЛК100 представлены в таблице 3.

Таблица 3 – Технические характеристики ПЛК100

Общие сведения

Конструктивное исполнение

Унифицированный корпус для крепления на DIN-рейку (ширина 35 мм), длина 105 мм (6U), шаг клемм 7,5 мм

Степень защиты корпуса

IР20

Напряжение питания: ПЛК100-24 ПЛК100-220

18…29 В постоянного тока (номинальное напряжение 24 В) 90…264 В переменного тока (номинальное напряжение 220 В) частотой 47…63 Гц

Потребляемая мощность, не более ПЛК100-24 ПЛК100-220

6 Вт* 10 Вт

Индикация передней панели

1 индикатор питания 8 индикаторов входов 12 индикаторов выходов

Ресурсы

Центральный процессор

32-х разрядный RISC-процессор 200 МГц на базе ядра АRМ9

Объем оперативной памяти

8 Мбайт

Объем энергонезависимой памяти хранения ядра СоDеSуs, программ и архивов

4 Мбайт**

Размер Retain-памяти

4 кбайт***

Время выполнения цикла ПЛК

Минимальное 250 мкс (не фиксированное), типовое от 1 мс

Дискретные входы

Количество дискретных входов

8

Гальваническая развязка дискретных входов

есть, групповая

Электрическая прочность изоляции дискретных входов

1,5кВ

Максимальная частота сигнала, подаваемого на дискретный вход

1 кГц при программной обработке 10 кГц при применении аппаратного счетчика и обработчика энкодера

Дискретные выходы

Количество дискретных выходов в: ПЛК100-24.Р и ПЛК100-220.Р ПЛК100-24.К

 6 э/м реле 6 сдвоенных транзисторных ключей (всего 12 выходных сигналов)

Гальваническая развязка дискретных выходов Электрическая прочность изоляции дискретных выходов

есть, индивидуальная 1,5кВ

Интерфейсы связи

Интерфейсы

Ethernet 100 Ваsе-Т RS-232 – 2 канала RS-485 USB 2.0 -Device

Скорость обмена по интерфейсам RS

от 4800 до 115200 bps

Протоколы

ОВЕН ModBus-RTU, ModBus-АSCII DСОN МоdBus-ТСР GateWay (протокол СоDеSуs)

Программирование

Среда программирования

СоDеSуs 2.3.8.1 (и старше)

Интерфейс для программирования и отладки

RS-232 USB-Device Ethernet

GSM/GPRS модем ОВЕН ПМ01

GSM/GPRS модем ОВЕН ПМ01 предназначен для удаленного обмена данными через беспроводные системы связи стандарта GSM с оборудованием, оснащенным последовательными интерфейсами связи RS232 или RS485.

Модем имеет возможность выполнять следующие функции:

· прием и передача SMS;

· прием и передача данных с помощью CSD;

· прием и передача данных с помощью GPRS;

· работа с последовательными интерфейсами RS-232 и RS-485;

· управление приемом и передачей данных по последовательным интерфейсам RS-232 и RS-485 с помощью АТ-команд в соответствии со стандартами GSM 07.05 и GSM 07.07.

· индикация наличия обмена данными по последовательным портам RS-485 или RS-232;

· индикация наличия регистрации в сети GSM и наличия передачи данных в режиме GPRS.

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

Работа Овен ПЛК 100 через GSM модем ПМ01

Схеме работы Овен ПЛК 100 через GSM модем ПМ01 представлена на рисунке 7.

Рисунок 7 – Схеме работы Овен ПЛК 100 через GSM модем ПМ01

Создадим новый проект в среде разработки CoDeSys, с конфигурацией, представленной на рисунках 8-9.

Рисунок 8 – Конфигурация проекта

Рисунок 9 – Конфигурация проекта

Зададим минимальное время цикла равное 10 мс (см. Рисунок 10).

Рисунок 10 – Задание минимального времени цикла

Установим интерфейс, при помощи которого подключен модем, RS-485-1 и установим его сетевые настройки (см. Рисунок 11).

Рисунок 11 – Задание интерфейса

Для работы с модемом добавим 2 библиотеки: UNM.lib и SmsOwenLib.lib (см. Рисунок 12).

Рисунок 12 – Подключение библиотек

Зададим логику работы программы, добавив функциональные блоки из ранее подключенных библиотек (см. Рисунок 13).

Рисунок 13 – Логика работы программы

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

Рисунок 14 – Параметры связи ПЛК

Рисунок 15 -Параметры сетевого окружения Windows

Откомпилируем проект и загрузим его в ПЛК ОВЕН 100, после чего выполним тестирование (см. Рисунок 16).

Рисунок 16 – Тестирование проекта

Отправим СМС сообщение с текстом “Пуск” на номер Сим-карты установленной в модеме ПМ01 (см. Рисунок 17).

Рисунок 17 – Отправка СМС сообщения

После доставки СМС сообщения, на ПЛК ОВЕН 100 загорится первое реле (см. Рисунки 18-19).

Рисунок 18 – Сообщение доставлено

Рисунок 19 – Результат доставки сообщения

Заключение

В период прохождения производственной практики я проделала следующую работу:

· изучила работу протокола ModBus RTU;

· научилась работать с последовательным портом в среде Visual Studio C#

· изучила работу ПЛК ОВЕН 100;

· изучила работу GSM/GPRS модема ОВЕН ПМ01

· изучила работу Овен ПЛК 100 через GSM модем ПМ01

· ознакомилась с организационной структурой, задачами и функциями отдела предприятия;

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

Результаты выполненной работы были занесены в данный отчет.

Список литературы

1. http://www.owen.ru

2. https://ru.wikipedia.org/wiki/Modbus

3. Статья: “Visual Studio C#: работа с последовательным портом” http://microsin.net/programming/PC/visual-studio-sharp-dot-net-com-port.html

4. Аннотация протокол передачи данных modbus rtu. http://intellect-odule.ru/downloads/manuals/inode_35D/ModBus_RTU.pdf

4.01
kirill195
бух.учет и аудит, финансовый менеджмент, финансовый анализ, инвестиционный менеджмент, статистика, эконометрика, экономико-математическое моделирование, разработка бизнес-планов (ПО Project Expert), банковское дело и многое другое