logo_ea.gif
В будние дни с 08:30 до 19:00
 nomermini.png
sale.energo@mail.ru  

В списке заказов 0 ед. товара
Корзина
  • Главная
  • Каталог
  • Конфигураторы
  • Наши проекты
  • Контакты
  • Протокол Modbus RTU

    Статья от 26.11.2017 Modbus — открытый коммуникационный протокол, основанный на архитектуре ведущий-ведомый (master-slave). Широко применяется в промышленности для организации связи между электронными устройствами. Может использоваться для передачи данных через последовательные линии связи RS-485, RS-422, RS-232, и сети TCP/IP (Modbus TCP).
    Протокол активно используется во многих современных ПЛК контроллерах, панелях оператора, модулях ввода/вывода. Преобразователях частоты, сервоприводах. 
    Достоинства стандарта 
    Основные достоинства стандарта — открытость и массовость. Промышленностью сейчас (2014 г.) выпускается очень много типов и моделей датчиков, исполнительных устройств, модулей обработки и нормализации сигналов и др. Практически все промышленные системы контроля и управления имеют программные драйверы для работы с MODBUS-сетями.
    Недостатки стандарта 
    Стандарт в своей основе был разработан в 1979 году компанией Modicon (в данное время принадлежит Schneider Electric) с учётом потребностей и вычислительных возможностей того времени, и многие актуальные для современных промышленных сетей вопросы не были учтены[6]. Необходимо отметить, что отсутствие перечисленных возможностей является следствием простоты протокола, которая облегчает его изучение и ускоряет внедрение.
    • Стандарт специфицирует метод передачи только двух типов данных. Отсутствие чёткого указания в стандарте привело к тому, что с другими типами данных сторонние производители MODBUS-решений поступали по своему усмотрению. Различие мнений производителей оборудования в этом вопросе не позволило впоследствии сделать уточнения в официальном документе: это вызвало бы всплеск недовольства производителей несогласных с предлагавшимися поправками стандарта и возможную войну форматов.
    • Стандарт не регламентирует начальную инициализацию системы. Назначение сетевых адресов и прописывание в системе параметров каждого конкретного устройства выполняются вручную на этапе адаптации и программирования системы.
    • Не предусмотрена передача сообщений по инициативе подчинённого устройства (прерываний). Ведущее устройство должно периодически опрашивать ведомые.
    • Длина запроса ограничена, а данные могут быть запрошены только из последовательно расположенных регистров. Это увеличивает задержки и накладные расходы при использовании сети, так как для получения данных из регистров, расположенных далеко друг от друга в адресном пространстве, мастер должен либо запрашивать ненужные данные, либо использовать несколько запросов.
    • Не предусмотрен способ, с помощью которого подчинённое устройство могло бы обнаружить потерю связи с ведущим
    И так, в основе интерфейса RS-485 лежит принцип дифференциальной (балансной) передачи данных. Суть его заключается в передаче одного сигнала по двум проводам. Причем по одному проводу (условно A) идет оригинальный сигнал, а по другому (условно B) — его инверсная копия. Другими словами, если на одном проводе «1», то на другом «0» и наоборот. Таким образом, между двумя проводами витой пары всегда есть разность потенциалов: при «1» она положительна, при «0» — отрицательна.
    modBus RTU для чайников

    Именно этой разностью потенциалов и передается сигнал. Такой способ передачи обеспечивает высокую устойчивость к синфазной помехе. Синфазной называют помеху, действующую на оба провода линии одинаково. К примеру, электромагнитная волна, проходя через участок линии связи, наводит в обоих проводах потенциал. Если сигнал передается потенциалом в одном проводе относительно общего, как в RS-232, то наводка на этот провод может исказить сигнал относительно хорошо поглощающего наводки общего («земли»). Кроме того, на сопротивлении длинного общего провода будет падать разность потенциалов земель — дополнительный источник искажений. А при дифференциальной передаче искажения не происходит. В самом деле, если два провода пролегают близко друг к другу, да еще перевиты, то наводка на оба провода одинакова. Потенциал в обоих одинаково нагруженных проводах изменяется одинаково, при этом информативная разность потенциалов остается без изменений.

    Так выглядит типичная посылка, от Ведущего — Ведомому.
    Так выглядит типичная посылка, от Ведущего — Ведомому.

    Так выглядит ответ Ведомого — Ведущему
    Так выглядит ответ Ведомого — Ведущему
    ID — Адрес ведомого устройства. Он может иметь значения от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 — зарезервированы.
    Команда(код функции):
    в данном примере одна, на чтение 0x03.
    Но в действительности их намного больше.
    Все коды функций делятся на:
    Публичные коды, описанные в стандарте MODBUS-IDA. Их список включает уже назначенные и используемые коды, а также коды для будущего использования;
    User-Defined Function Codes (65-72, 100-110) — коды, которые могут использоваться компаниями для собственных функций, и не описаны в спецификации;
    Reserved Function Codes (9, 10, 13, 14, 41, 42, 43, 90, 91, 125, 126 и 127) — зарезервированы коды, которые не доступны для общего использования.
    (0x02) — чтение значений из нескольких дискретных входов (Read Discrete Inputs).
    (0x03) — чтение значений из нескольких регистров хранения (Read Holding Registers).
    (0x04) — чтение значений из нескольких регистров ввода (Read Input Registers).
    (0x05) — запись значения одного флага (Force Single Coil).
    (0x06) — запись значения в один регистр хранения (Preset Single Register).
    (0x07) — Чтение сигналов состояния (Read Exception Status)
    (0x0F) — запись значений в несколько регистров флагов (Force Multiple Coils)
    (0x10) — запись значений в несколько регистров хранения (Preset Multiple Registers)
    (0x16) — запись в один регистр хранения с использованием маски «И» и маски «ИЛИ» (Mask Write Register).
    (0x18) — Чтение данных из очереди (Read FIFO Queue)
    (0x14) — Чтение из файла (Read File Record)
    (0x15) — Запись в файл (Write File Record)
    (0x08) — Диагностика (Diagnostic)
    (0x0B) — Чтение счетчика событий (Get Com Event Counter)
    (0x0C) — Чтение журнала событий (Get Com Event Log)
    (0x11) — Чтение информации об устройстве (Report Slave ID)
    (0x2B) — Encapsulated Interface Transport
    Обработка ошибок
    Ведущий отправляет запрос к Ведомому, в котором в поле «код функции» указывает ему на необходимое действие.
    Байты данных содержат информацию, необходимую для выполнения данной функции.
    Ведомый, в случае удачного выполнения этой функции, повторяет код функции в ответе.
    При возникновении ошибки, код функции в ответе модифицируется — старший бит выставляется в 1.
    В байтах данных передается причина ошибки. Например при исполнении Ведомым функции 0x0F возникла ошибка, тогда он ответит Ведущему полем функции равным 0x8F.
    В дополнении к изменению кода функции, Ведомый размещает в поле данных уникальный код, который указывает на тип и причину ошибки.
    CRC-16, циклически избыточный код.
    Полином:
    modbuspic5.png
    Для расчета есть два метода:
    Простой
    uint16_t GetCRC16(byte *buf, uint8_t len) { uint16_t crc; crc = 0xFFFF; while(len--) 
    { crc = crctable[((crc>>8)^*buf++)&0xFF] ^ (crc<<8); } crc ^= 0xFFFF; return crc; }
    и 
    Табличный
    const uint8_t auchCRCHi[256]= 
          
    {
    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 }; const uint8_t auchCRCLo[256]= {
    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 }; uint16_t CRC16(uint8_t *p, uint16_t len) { uint8_t crc_hi;
    uint8_t crc_lo;
    uint8_t n;
    if (len>256U) { return (0); }
    n = (uint8_t)len;
    crc_hi = 0xFF; // high byte of CRC initialized crc_lo = 0xFF; // low byte of CRC initialized do {
    uint8_t i = crc_hi ^ *p++; // will index into CRC lookup table crc_hi = crc_lo ^
    (uint8_t)(&auchCRCHi[i]); // calculate the CRC crc_lo = (uint8_t)(&auchCRCLo[i]); }
     while (--n); // pass through message buffer (max 256 items) 
     
          
    return ((crc_hi << 8) | crc_lo); }
     
    Использование табличной функции 
    unsigned char mess[3] = {1,108,8}; 
    volatile unsigned short res1 = CRC16(&mess,3); 
    res1 будет равен 0x0СС6 при подстановке в конце команды менять местами старший и младший байты не надо. Эта функция при занесении значения в res1 автоматически меняет местами старший и младший байты.
    modbuspic6.png
    Как указано в даташите на ADM485, для работы на прием выводы RE-DE-DI должны быть в 0, тогда на выводе RO появляются принятые данные. Для работы на передачу — все противоположно, но данные следует слать на DI.

    Простая функция приема
    void USART1_IRQHandler(void) { uint16_t temp; if((Modbus_Progress_Status == M_STAT_REC_ON)|| (Modbus_Progress_Status == M_STAT_CLEAR)) { Modbus_Data[Modbus_Count_Byte] = USART1->DR; 
          
    Modbus_Count_Byte ++;
    if(Modbus_Count_Byte >= LENGTH_PACK)
    { if(Modbus_Data[0] == MY_ID) {
    temp = Modbus_Data[7]; temp = temp<<8; temp |= Modbus_Data[6]; if(CRC_calc(Modbus_Data,9)==temp) { Modbus_Progress_Status = M_STAT_TRAN_ON; Modbus_Count_Byte =0; USART1->CR1 &=~ USART_CR1_RE; USART1->CR1 &=~ USART_CR1_RXNEIE; Modbus_Send(); }; }}}
     
    Ответ выглядит примерно так
    void Modbus_Send(void)
    {
    uint16_t crc;
    uint8_t i;
    USART1->CR1 &=~ USART_CR1_RE;
    USART1->CR1 &=~ USART_CR1_RXNEIE;

    Modbus_DataTX[0]= ID;
    Modbus_DataTX[1]= COMMAND_READ;
    Modbus_DataTX[2]= LENGTH_REDE;

    Modbus_DataTX[3]= Param1L;
    Modbus_DataTX[4]= Param1H;

    Modbus_DataTX[5]= Param2L;
    Modbus_DataTX[6]= Param1H;
    ....
    Modbus_DataTX[21]= Param21L;
    Modbus_DataTX[22]= Param21H;

    crc = CRC(Modbus_DataTX, 23);

    Modbus_DataTX[23]= (crc & 0x00FF);
    Modbus_DataTX[24]= (crc >>8);

    Modbus_Transmit_Select();

    for(i=0; i<LENGTH_PACK_REDE; i++)
    {
    USART_Transmit(Modbus_DataTX[i]);
    }

    USART1->CR1 &=~ USART_CR1_TE;
    Modbus_Receive_Select();
    // Тут очищаем флаги если есть
    Modbus_Data_TransLength = 0;
    Modbus_Progress_Status = M_STAT_CLEAR;
    Modbus_Progress_Status = 0;
    Modbus_Count_Byte = 0;
    Modbus_Count_TransByte =0;

    USART1->CR1 |= USART_CR1_RE;
    USART1->CR1 |= USART_CR1_RXNEIE;
    }
    Все интервалы организованы на прерываниях. Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс, соответственно.

    Количество показов: 30

    Возврат к списку

    Соберите такой шкаф, который нужен именно вам.
    С нашим конфигуратором это просто.
    Конфигуратор