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

Содержание

Введение............................................................................................................

Глава 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
	Прикладной уровень	прикладной уровень ModBus
	Представительский уровень	---
	Сеансовый уровень	---
	Транспортный уровень	---
	Сетевой уровень	---
	Канальный уровень	протокол последовательного интерфейса ModBus
	Физический уровень	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;

}

}