Логика СПТ944 [4/24] Структура сообщений

Содержание

• Логики 1
• Магистральный протокол м4 1
• Ражг 0293 33 1
• Руководство программиста 1
• Ао нпф логика 2012 2014 2016 2
• Кс8 0 2
• Магистральный протокол м4 руководство программиста 2 2
• Общие сведения 3 2
• Отдельные изменения связанные с дальнейшим совершенствованием изделий поддерживаю 2
• Перечень ссылок 8 2
• Приложение а 19 2
• Приложение б 21 2
• Процедуры взаимодействия абонентов 2
• Россия 190020 г санкт петербург наб обводного канала 150 2
• Содержание 2
• Структура сообщений 4 2
• Сяс 16 9 2 2
• Тел факс 812 2522940 4452745 adm logika spb ru www logika spb ru 2
• Щих магистральный протокол м4 могут быть не отражены в настоящем 3 м издании 2
• Я5232 4 5 2
• Область применения 3
• Общие сведения 3
• Принципы организации магистрали 3
• Принятые обозначения 3
• Базовый формат сообщений 4
• Структура сообщений 4
• Сокращенный формат сообщений 5
• Теги 5
• Intu ints leefioat 7
• Основные типы структурных элементов 7
• Asciistring 8
• Time date 8
• Инициализация сеанса обмена 9
• Процедуры взаимодействия абонентов 9
• Обработка ошибок 10
• Чтение параметров 11
• Octet string mixed asciistring leefloat intu ints null 12
• Где ch номер канала рп номер параметра val значение параметра 12
• Запись параметров 12
• Запись параметров осуществляется с помощью запроса 12
• Запрос состоит из произвольного набора параметров запись которых должна быть выполнена структурирование элементов запроса осуществляется тегами pnum tag и tag значение по 12
• Магистральный протокол м4 руководство программиста 12 12
• Не подключаться вообще или подключаться со значением байта flag 0 12
• Оперативный или неоперативный для этого вслед за полем val к описывающей параметр структуре может быть присоединено поле operative flag таким образом каждая из строк представленного выше запроса может иметь вид 12
• По усмотрению отправителя сообщения к неоперативным параметрам поле operative flag может 12
• Поля сообщения tag в зависимости от типа соответствующего им структурного элемента могут 12
• При записи настроечного параметра последний может быть одновременно сконфигурирован как 12
• Принимать значения 12
• Следнего определяется типом передаваемого параметра и в общем случае может быть равным 12
• Байт rectype определяет тип запрашиваемых архивов а также формат их вывода структура байта rectype приведена ниже 13
• Где cnt_l cnt_h номер архивного раздела младший и старший байты n максимальное количество включаемых в ответ записей сй канал 13
• Для получения от абонента накопленных им архивных данных используется запрос 13
• Магистральный протокол м4 руководство программиста 13 13
• Опция archive указывает тип запрашиваемого архива и может принимать следующие значения 0 часовые 1 суточные 2 декадные 13
• Отчет содержит результаты записи каждого параметра из полученного набора в зависимости от 13
• Ошибок соответствуют таблице 3 при успешной записи поле option имеет нулевую длину 13
• Поле option передает коды ошибок если таковые возникают в процессе записи перечень кодов 13
• После обработки запроса записи абонент возвращает отчет вида 13
• Результата поле аск err tag может содержать тег подтверждения аск tag или тег ошибки err tag 13
• Самостоятельно т е без передачи параметру нового значения для этого элемент val может не вклю чаться в запрос с учетом чего каждая строка представленного выше запроса записи может иметь в вид 13
• Формат поля operative flag описан в п процедура назначения параметров оперативными или неоперативными может быть использована 13
• Чтение архивов 13
• Archdate tag dl 0 sequence tag dl 0 15
• End date в сторону убывания при от сутствии таковых поле date 1 будут иметь нулевую длину 15
• Start date присваивается значение соответствующее дате 01 01 00 и времени 00 00 00 15
• Абонента включаются данные предварительно подвергнутые компрессии сжатию посредством ука занного в запросе метода 15
• Запрос с n 0 удобно использовать для определения даты первой архивной записи для этого полю 15
• Магистральный протокол м4 руководство программиста 15 15
• На такой запрос не включаются 15
• Например при полном отсутствии записей в архиве будет сформирован ответ 15
• Поле date 1 содержит дату записи ближайшую к заданному в запросе интервалу времени при 15
• Поле end date не подключается к запросу или заполняется кодом oxff если запрос чтения архива содержит отличное от нуля значение поля compression туре в ответ 15
• Поле n в запросе может принимать значения 0 55 в ответ на запрос с n 0 будет возвращен указатель date 1 собственно архивные данные в ответ 15
• Поле record содержит собственно архивную запись внутри записи отдельные параметры разделены тегами т е каждый параметр представлен струк 15
• Поле tag в зависимости от типа параметра может принимать значения octet string asciistring leefloat intu ints null 15
• При отключенном сжатии данных compression туре 0 ответ абонента имеет вид 15
• Турой 15
• Cmd op ch 0x00 16
• В зависимости от конкретного типа устройства набор формируемых им архивов может быть не 16
• Где cmd код команды ор опции ch код канала 16
• Запрос предназначен для выполнения пуска останова счета сброса накопленных абонентом архив 16
• Магистральный протокол м4 руководство программиста 16 16
• Нента архивных записей осуществляется ограничение длины поля data таким образом чтобы его длина не превышала 1024 байта длина поля регулируется подбором максимального количества включаемых в него целых структурных элементов соответствующих одной архивной записи поля archdata_tag record 16
• Ных данных и тотальных значений параметров общий вид запроса 16
• Ответ абонента на запрос чтения архивной записи при compression type 0 имеет вид 16
• Передачи конкретного устройства абонента а также максимальной длиной поля msg body протоко ла м4 которая составляет 65535 байтов 16
• Поле ответа data содержит подвергнутые компрессии архивные данные структура этого поля по 16
• Полным функции сжатия данных также могут не поддерживаться 16
• Последнее поле ответа т е поле содержащее указатель date 1 компрессии не подвергается при значении опции compression type l вне зависимости от количества запрашиваемых у або 16
• При значении опции compression type 2 предельная длина поля data определяется объемом буфера 16
• При получении запроса с недопустимыми для данного устройства значениями опций compression 16
• Сле декомпрессии на стороне получателя соответствует описанной выше структуре блока архивных данных ответа на запрос чтения архивной записи с опцией compression туре 0 16
• Туре или archive в поле rectype будет сформировано сообщение с кодом ошибки 0x02 недопусти мые значения параметров запроса 16
• Управление счетом 16
• Выбор скорости обмена 17
• Перечень ссылок 18
• Oxff 0x90 0x00 0x00 0x05 0x00 0x3f 0x00 0x00 0x00 0x00 19
• X10 oxff 0x90 0x00 0x00 0x05 0x00 0x3f 0x00 0x00 0x00 0x00 0xd9 0x19 19
• X90 0x00 0x00 0x05 0x00 0x3f 0x00 0x00 0x00 0x00 0xd9 0x19 19
• Контрольные коды сообщений 19
• Контрольный код сообщения 0xl9d9 получен посредством вычислений по приведенному алгорит 19
• Магистральный протокол м4 руководство программиста 19 19
• Му он охватывает все сообщение за исключением кода начала кадра 0x10 т е байты 19
• Ниже приводятся реализации алгоритмов вычисления контрольных кодов сообщений на языке си 19
• При выполнении получателем сообщения проверки контрольного кода crc 16 удобно пользовать 19
• Приложение а 19
• Пример в качестве примера рассмотрим сообщение протокола м4 содержащее запрос сеанса связи 19
• Ся следующим свойством последнего если приписать к произвольному блоку информации его crc 16 а затем пересчитать crc 16 полученного таким образом нового блока то результатом будет ноль для приведенного примера нулевой результат дадут вычисления crc 16 следующего массива 19
• X10 0xff 0xзf 0x00 0x00 0x00 0x00 0хс1 0x16 20
• X3f 0x00 0x00 0x00 0x00 oxcl 20
• Xff 0xзf 0x00 0x00 0x00 0x00 20
• Дующего массива байтов 20
• Контрольная сумма кс8 20
• Контрольная сумма сообщения охс 1 получена по приведенному алгоритму путем обработки сле 20
• Магистральный протокол м4 руководство программиста 20 20
• Описанному для crc 16 если вычислить кс8 блока информации последним байтом которого является кс8 всех предшествующих байтов то результатом будет ноль т е для приведенного примера нуле вой результат даст вычисление кс8 следующего массива байтов 20
• При проверке кс8 на стороне получателя сообщения удобно пользоваться правилом аналогичным 20
• Пример приведем в качестве примера сокращенную форму уже рассмотренного выше запроса сеанса связи 20
• Аппаратное построение магистрального интерфейса 21
• Приложение б 21
• Цепи и сигналы 21
• Протяженность магистрали 22
• Согласование параметров линии связи 22
• Подключение к порту и8232 24
• Электрические параметры 24

Похожие устройства

• Логика СПТ944 Интерфейс связи
• Логика СПТ944 Руководство по эксплуатации
• Логика СПТ961 (мод. 961.2) Руководство программиста
• Логика СПТ961 (мод. 961.2) Руководство по эксплуатации
• Логика СПТ962 Руководство программиста
• Логика СПТ962 Руководство по эксплуатации
• Логика СПТ963 Протокол MODBUS RTU v02
• Логика СПТ963 Магистральный протокол СПСеть
• Логика СПТ963 Руководство по эксплуатации
• Логика СПТ940-ПРЭМ Руководство по эксплуатации
• Bang & Olufsen Beoplay E8 Sport Black Инструкция по эксплуатации
• Bang & Olufsen Beoplay E8 Sport Oxygen Blue Инструкция по эксплуатации
• Airwheel SE3 Silver (SE3G1ZD191231098) Инструкция по эксплуатации
• Airwheel SR5 Silver (SSESRZE190829003) Инструкция по эксплуатации
• Airwheel SE3 Mini Black (SR5G6ZE191109056) Инструкция по эксплуатации
• Square Off Grand Kingdom Set Limited Edition Инструкция по эксплуатации
• A4Tech Bloody W60 Max черный Инструкция по эксплуатации
• Galaxy GL 0120 Инструкция по эксплуатации
• Legrand Keor SPX 600 BA (310300) Инструкция по эксплуатации
• Legrand Keor SPX 800 BA (310301) Инструкция по эксплуатации

4 Магистральный протокол М4 Руководство программиста 2 Структура сообщений 2 1 Базовый формат сообщений Сообщение протокола М4 состоит из заголовка тела и блока контрольной информации Общий вид сообщения приведен ниже III SOH NT FRM ID ATR III DL1 DLO MSG BODY CRC 1 CRCO _____ 1____ 1 1 1 1 1 1 _______1______ Где SOH управляющий код начала сообщения NT сетевой номер абонента адресата сообщения FRM код формата сообщения ID байт идентификатора сообщения ATR байт атрибутов сообщения DL1 DL0 длина тела сообщения младший и старший байты MSG BODY тело сообщения CRC1 CRC0 шестнадцатибитный циклический контрольный код младший и старший байты Управляющий код начала сообщения SOH служит для синхронизации приема на фоне помех Его значение фиксировано SOH OxlO Сетевой номер NT может принимать значения 0 255 причем NT 255 используется для безадрес ного обращения к абоненту При получении запроса с NT 255 абонент выполняет его обработку неза висимо от действительного значения своего сетевого адреса Во всех остальных случаях запросы со держащие NT не соответствующие сетевому адресу абонента игнорируются Поле формата сообщения FRM предназначено для выделения сообщений передача которых ведет ся в сокращенной форме п 2 2 В таких сообщениях значение этого поля отлично от 0x90 В осталь ных случаях его значение фиксировано FRM 0x90 Идентификатор ID служит для организации упорядоченного разбора сообщений при их приеме Байт ID полученный абонентом в запросе без изменений копируется в соответствующее поле ответа Механизм идентификации сообщений позволяет восстановить исходный порядок их следования при использовании сред передачи информации где такой порядок не гарантируется Поле атрибутов ATR зарезервировано для использования в последующих версиях протокола В не го должно подставляться значение ATR 0x00 Тело сообщения MSG BODY может иметь произвольную длину в пределах 0 65535 байтов При этом его структура всегда детерминирована тело сообщения состоит из однобайтового кода запроса FNC и блока данных Data Set FNC Data Set J 1 L