Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Вопросы:
1) На мой взгляд нужно вынести в самое начало ответ на вопрос А какую проблему Вы решаете? Пока, мне кажется, слишком размыто
2) Связана ли Ваша задача с НОРЭМ? Если да, то как?
1) На мой взгляд нужно вынести в самое начало ответ на вопрос А какую проблему Вы решаете? Пока, мне кажется, слишком размыто
2) Связана ли Ваша задача с НОРЭМ? Если да, то как?
В более-менее крупной организации, имеющей промышленные здания, необходимо контролировать потребляемые энергоресурсы. На практике это выливается в десятки счетчиков (электроэнергия, газ, отопление, холодная и горячая вода, стоки). Система, о которой идет речь в этой статье, помогает главному энергетику оперативно учитывать расход энергоресурсов, не бегая при этом по подвалам.
С НОРЭМ я не сталкивался, но думаю, что модуль, подобный тому, которыя я разработал пригодился бы и в глабальных системах контроля энергоресурсов.
С НОРЭМ я не сталкивался, но думаю, что модуль, подобный тому, которыя я разработал пригодился бы и в глабальных системах контроля энергоресурсов.
Занимаемся на работе созданием более функциональной системы, чем просто АСКУЭ, с поддержкой более трёх десятков моделей счётчиков. Плюс ещё минимум сотня других устройств. Могу сказать, что на весь этот зоопарк устройств у нас целых три (три!) версии CRC: CRC16-Modbus, CRC16-Xmodem и CRC8. Так что выносить всё это в библиотеку — полезно и нужно.
Если вы планируете разрабатывать систему, к которой можно подключать несколько различных устройств — стоит предусмотреть очень и очень многое. В некоторых устройствах RS485 адрес задается как char, в некоторых — uint16 или uint32, а в некоторых — даже char *. Некоторые устройства способны объединяться в локальную сеть по PLC или CAN-интерфейсу, и в этом случае одно-единственное устройство с RS485 будет служить роутером для всех остальных устройств в сети. Всё это часто осложняется плохой документацией от производителей оборудования, или невозможностью эту документацию получить.
Если вы планируете разрабатывать систему, к которой можно подключать несколько различных устройств — стоит предусмотреть очень и очень многое. В некоторых устройствах RS485 адрес задается как char, в некоторых — uint16 или uint32, а в некоторых — даже char *. Некоторые устройства способны объединяться в локальную сеть по PLC или CAN-интерфейсу, и в этом случае одно-единственное устройство с RS485 будет служить роутером для всех остальных устройств в сети. Всё это часто осложняется плохой документацией от производителей оборудования, или невозможностью эту документацию получить.
Спасибо, что обнадежили насчет CRC. А то у меня сложилось впечатление именно такое, о котором я написал в статье.
У нас сначала тоже. Но чем больше было устройств — тем приятнее становилось, что CRC вынесено в библиотеку.
Печальнее всего, что современные устройства используют бинарные протоколы, а не XML, например.
Печальнее всего, что современные устройства используют бинарные протоколы, а не XML, например.
При плохой или отсутствующей документации вид протокола не спасет от проблем при разработке.
Не спасёт от всех проблем, но реверсить протокол от железки, использующей XML, куда легче, чем реверсить бинарный протокол. Помню, много нервов мне попортили железки Eltek, у которых в контроллерах SmartPack используется протокол с регистрами-многомерными массивами. Задача осложнялась тем, что заводское ПО опрашивало параметры железки не в строго заданном порядке, а в случайном.
Думаю, что по RS-485 и подобным протоколам XML передавать слишком накладно. Но должны быть железки, потключаемые прямо по TCP/IP. У них тогда и настроечною морду можно сделать на HTTP. Что-то вроде того, как роутеры сейчас работают. Ну и полный стек Web-сервисов с XML можно организовать.
На линиях RS485 без проблем можно получить как минимум 9600 бит/с, для текстового протокола с умеренным количеством передаваемых данных вполне достаточно. Я железок с XML по RS485 или RS232 не встречал, и только пару раз видел железки с вменяемыми текстовыми протоколами.
Зато очень часто попадались железки, которые через RS232 подключались по PPP. И через установленное соединение показывали web-интерфейс и отправляли snmp-трапы.
Зато очень часто попадались железки, которые через RS232 подключались по PPP. И через установленное соединение показывали web-интерфейс и отправляли snmp-трапы.
Старые простые и надёжные протоколы используются и потому, что подобные железяки частенько подключаются к промышленным контроллерам, для которых разбор xml будет очень накладным.
К тому же пром. контроллеры уже содержат на борту перечисленные интерфейсы, и частенько имеют готовые библиотечные блоки для работы по всяким модбасам.
А задача пром. интерфейсов: циклично гнать данные. Очень часто, очень надежно, но по чуть-чуть
К тому же пром. контроллеры уже содержат на борту перечисленные интерфейсы, и частенько имеют готовые библиотечные блоки для работы по всяким модбасам.
А задача пром. интерфейсов: циклично гнать данные. Очень часто, очень надежно, но по чуть-чуть
Вот мы как раз и разрабатывали на работе промышленный контроллер, который должен был поддерживать целый зоопарк оконечного оборудования. И когда в таблице из 4000 наименований устройств мы находили какое-нибудь с MODBUS, то очень сильно радовались. Средний проприетарный протокол от «умного» устройства мы «раскуривали» около недели, включая всевозможные тесты с разными модификациями одного устройства.
Странные у вас представления, однако…
Основное назначение этих протоколов — связь между устройствами. В устройствах часто используются относительно слабые процессоры. Более того, собирать/разбирать бинарные протоколы несколько проще, чем кучу текста — особенно, на устройствах.
например, автор называет ModBus надёжным и проверенным решением. В какой-то степени он прав, но когда на объекте сталкиваешься с небольшим зоопарком, висящим на одной шине — он перестаёт казаться надёжным :)
Основное назначение этих протоколов — связь между устройствами. В устройствах часто используются относительно слабые процессоры. Более того, собирать/разбирать бинарные протоколы несколько проще, чем кучу текста — особенно, на устройствах.
например, автор называет ModBus надёжным и проверенным решением. В какой-то степени он прав, но когда на объекте сталкиваешься с небольшим зоопарком, висящим на одной шине — он перестаёт казаться надёжным :)
Всё верно, основное назначение протоколов — связь между устройствами. Вот только использовать слабые процессоры в мелкосерийке сейчас почти бессмысленно — по стоимости конечных устройств много не выгадаешь, а по скорости/удобству разработки и отлаженности результирующего кода разработка на ассемблере и парсинг бинарных протоколов сливают ЯВУ и сериализованным в XML/JSON протоколам. За счёт этого компания, в которой я работал раньше, и выиграла тендер — поставила чипы условно на бакс дороже, чем у конкурентов, но зато мощные ARM, и смогла выпустить готовый продукт быстрее и более высокого качества.
Многие протоколы, которые пришлось поддерживать, были бинарными. Часть из них была крайне сложной и запутанной, в том числе с признанными багами со стороны производителя (например, счётчик внезапно мог зависнуть и выплюнуть содержимое всей своей памяти на RS485). Реализации modbus у разных производителей тоже порой значительно отличались, особенно для float-значений и массивов. И только текстовые протоколы с контрольными суммами были эффективны (при условии, что интервал между запросами >> времени на передачу запроса) и надежны. Такая вот история.
Многие протоколы, которые пришлось поддерживать, были бинарными. Часть из них была крайне сложной и запутанной, в том числе с признанными багами со стороны производителя (например, счётчик внезапно мог зависнуть и выплюнуть содержимое всей своей памяти на RS485). Реализации modbus у разных производителей тоже порой значительно отличались, особенно для float-значений и массивов. И только текстовые протоколы с контрольными суммами были эффективны (при условии, что интервал между запросами >> времени на передачу запроса) и надежны. Такая вот история.
Я вам ниже написал, почему и для чего используются бинарные протоколы и не используются текстовые.
Даже если предположить, что мы засунули в контроллер условный i7 вместо условного 486 — это не поменяет абсолютно ничего по следующим причинам:
1. для управления процессом производительности 486 — за глаза.
2. логика в управляющей программе битовая, минимально адресуемая единица — бит, а не байт.
3. линии передачи часто используются на 9600 и т.д. Это даёт меньше помех и большую дальность связи.
4. для промышленной автоматики битовая логика в 100 раз удобнее.
По этим причинам никто и никогда не будет использовать в автоматике XML.
Приведу пример. Есть такое понятие — распределённая периферия (distributed I/O)
Допустим, у нас есть корзина периферии на 64 дискретных входа, 64 дискретных выхода, 16 аналоговых входов и 4 аналоговых выхода.
Итого получается:
8 байт — дискретные входы,
8 байт — дискретные выходы,
32 байт — аналоговые входы (по слову на канал),
8 байт — аналоговые выходы (по слову на канал).
Итого 66 байт без учёта служебной информации.
Сколько это займёт в виде XML?
И ещё одby любопытный факт: система Profibus-DP ограничивает полезные данные в телеграмме от ведомого устройства 244 байтами. В ряде случаев это создаёт некоторые неудобства (особенно, при использовании Y-link), но в большинстве случаев этого хватает за глаза.
Вы просто не берёте в расчёт, что до сих пор существуют системы (и просуществуют ещё очень долго), которые прекрасно обходятся или без ЯВУ совсем, или специфическими ЯВУ, в которых бинарные данные обрабатывать проще.
Приведу простой пример. Практически у каждого сейчас смартфон. при том, что все его свистелки и перделки, блэкджек и мамзели нужны далеко не каждому. На каждый день — вполне себе вариант. Я таким пользуюсь. Но если мне нужно пойти в поход, или просто постоянно находиться в пересечённой местности — я предпочту либо старую нокию с внешней антенной, аккумулятором не на 3.7 вольт, а на 7.4 (были и такие, когда телефоны были большими) и монохромным экраном в полторы строки — по дальности связи и времени автономной работы этот дедушка уложит смарты на обе лопатки. Ещё может быть, что я предпочту NMT-450, или один из предыдущих вариантов в стационарном/автомобильном исполнении с внешней антенной или, вообще, рацию :) Не нужно пихать XML с его блекджеком и дамами туда, где он не нужен.
А глюки — это глюки. Ничего не мешает ведомому устройству точно так же выдать поток сознания в XML.
PS что до надёжности — вы, видимо, с Profibus не работали. По моему опыту, это лучшая полевая шина. Достаточно всё аккуратно соединить, правильно выставить адреса и проверить правильность включения терминаторов — это не больше одного дня работы. После чего он поднимается сразу и без всяких плясок с бубнами, даёт полную диагностику и вообще, очень устойчиво работает. ModBus нервно курит в сторонке.
Даже если предположить, что мы засунули в контроллер условный i7 вместо условного 486 — это не поменяет абсолютно ничего по следующим причинам:
1. для управления процессом производительности 486 — за глаза.
2. логика в управляющей программе битовая, минимально адресуемая единица — бит, а не байт.
3. линии передачи часто используются на 9600 и т.д. Это даёт меньше помех и большую дальность связи.
4. для промышленной автоматики битовая логика в 100 раз удобнее.
По этим причинам никто и никогда не будет использовать в автоматике XML.
Приведу пример. Есть такое понятие — распределённая периферия (distributed I/O)
Допустим, у нас есть корзина периферии на 64 дискретных входа, 64 дискретных выхода, 16 аналоговых входов и 4 аналоговых выхода.
Итого получается:
8 байт — дискретные входы,
8 байт — дискретные выходы,
32 байт — аналоговые входы (по слову на канал),
8 байт — аналоговые выходы (по слову на канал).
Итого 66 байт без учёта служебной информации.
Сколько это займёт в виде XML?
И ещё одby любопытный факт: система Profibus-DP ограничивает полезные данные в телеграмме от ведомого устройства 244 байтами. В ряде случаев это создаёт некоторые неудобства (особенно, при использовании Y-link), но в большинстве случаев этого хватает за глаза.
Вы просто не берёте в расчёт, что до сих пор существуют системы (и просуществуют ещё очень долго), которые прекрасно обходятся или без ЯВУ совсем, или специфическими ЯВУ, в которых бинарные данные обрабатывать проще.
Приведу простой пример. Практически у каждого сейчас смартфон. при том, что все его свистелки и перделки, блэкджек и мамзели нужны далеко не каждому. На каждый день — вполне себе вариант. Я таким пользуюсь. Но если мне нужно пойти в поход, или просто постоянно находиться в пересечённой местности — я предпочту либо старую нокию с внешней антенной, аккумулятором не на 3.7 вольт, а на 7.4 (были и такие, когда телефоны были большими) и монохромным экраном в полторы строки — по дальности связи и времени автономной работы этот дедушка уложит смарты на обе лопатки. Ещё может быть, что я предпочту NMT-450, или один из предыдущих вариантов в стационарном/автомобильном исполнении с внешней антенной или, вообще, рацию :) Не нужно пихать XML с его блекджеком и дамами туда, где он не нужен.
А глюки — это глюки. Ничего не мешает ведомому устройству точно так же выдать поток сознания в XML.
PS что до надёжности — вы, видимо, с Profibus не работали. По моему опыту, это лучшая полевая шина. Достаточно всё аккуратно соединить, правильно выставить адреса и проверить правильность включения терминаторов — это не больше одного дня работы. После чего он поднимается сразу и без всяких плясок с бубнами, даёт полную диагностику и вообще, очень устойчиво работает. ModBus нервно курит в сторонке.
Я понял ваше мнение, и в значительной степени с ним согласен — как разработчик железок. Как программист — я хочу использовать простые человекочитаемые форматы данных, с которыми легко работать.
Есть как минимум www.greenbuttondata.org/use/
В общем, предлагаю дискуссию закончить. Мне нравятся ваши аргументы.
По этим причинам никто и никогда не будет использовать в автоматике XML.
Есть как минимум www.greenbuttondata.org/use/
В общем, предлагаю дискуссию закончить. Мне нравятся ваши аргументы.
Они вполне себе человекочитаемые, если есть карта регистров :)
К слову, транспортные протоколы, типа TCP — совершенно нечеловекочитаемые, но вас не смущает, что ваши данные передаются с их использованием.
И, в ряде случаев, с бинарными данными работать даже легче. Не всё так однозначно.
А дискуссия, согласен, зашла в тупик. Дальше есть шансы продолжить по Жванецкому: «Убедить мне вас не удастся, поэтому сразу перейду к оскорблениям» :)))
PS Я с вами совершенно согласен в том, что заглянуть внутрь текстового XML протокола гораздо легче. Но даже не в контексте промышленной автоматики для того, чтоб распарсить XML, желательно иметь библиотеки для этого, всякие типы данных Variant и прочие блэкджеки. Поэтому, даже на ЯВУ работать с бинарным протоколом может быть удобнее и уж точно менее требовательно к количеству передаваемых данных, объёму памяти и быстродействию процессора.
Другое преимущество XML — в него проще добавить какие-либо новые данные либо данные переменной длины без того, чтоб развалить весь пакет к чОртовой бабушке.
К слову, транспортные протоколы, типа TCP — совершенно нечеловекочитаемые, но вас не смущает, что ваши данные передаются с их использованием.
И, в ряде случаев, с бинарными данными работать даже легче. Не всё так однозначно.
А дискуссия, согласен, зашла в тупик. Дальше есть шансы продолжить по Жванецкому: «Убедить мне вас не удастся, поэтому сразу перейду к оскорблениям» :)))
PS Я с вами совершенно согласен в том, что заглянуть внутрь текстового XML протокола гораздо легче. Но даже не в контексте промышленной автоматики для того, чтоб распарсить XML, желательно иметь библиотеки для этого, всякие типы данных Variant и прочие блэкджеки. Поэтому, даже на ЯВУ работать с бинарным протоколом может быть удобнее и уж точно менее требовательно к количеству передаваемых данных, объёму памяти и быстродействию процессора.
Другое преимущество XML — в него проще добавить какие-либо новые данные либо данные переменной длины без того, чтоб развалить весь пакет к чОртовой бабушке.
Поясню на примере. Есть у меня, скажем, мотор. Применительно к нему у меня может быть несколько флагов, например: состояние (включен/выключен), переключатель режима (автомат/ручной), ручной выключатель (вкл/выкл), состояние автомата (включен/отключен), выключатель по месту (вкл/откл), защита по перегреву, контроль изоляции, выходная команда контроллера. Итого получилось 7 бит. Всё это я упихиваю в слово, которое обычно называют словом состояния. Именно в таком виде я использую это в контроллере (у меня там обычная битовая логика) — сношаться с XML и прочими текстами в контроллере я никому не пожелаю. Это слово я в том виде, в каком оно есть, передаю в скаду, например. Там разбираю на биты с помощью битовых масок и and/or, чтобы отобразить на экране. Кроме того, отдаю это одну переменную, а не семь — скады почти всегда лицензируются по количеству переменных.
Моторов этих на установке может быть до и больше, и все их надо циклически читать (а есть ещё ряд параметров, кроме слова состояния, да и другие объекты, кроме моторов). Всё это можно с приемлемым интервалом обновления засунуть в интерфейс со скоростью 9.6/19.2 кбит/с. А если некто сторонний хочет XML — то флаг ему в руки, меня это не волнует :)
Моторов этих на установке может быть до и больше, и все их надо циклически читать (а есть ещё ряд параметров, кроме слова состояния, да и другие объекты, кроме моторов). Всё это можно с приемлемым интервалом обновления засунуть в интерфейс со скоростью 9.6/19.2 кбит/с. А если некто сторонний хочет XML — то флаг ему в руки, меня это не волнует :)
Для такой задачи — да, бинарный протокол от устройства может быть наилучшим решением. У нас управляемые устройства были значительно сложнее, с тысячами и десятками тысяч параметров разных типов — int, float, str, двумерные и трехмерные массивы.
p.s. А в чём проблема отформатировать строку на контроллере, если пропускная способность интерфейса позволяет? :)
p.s. А в чём проблема отформатировать строку на контроллере, если пропускная способность интерфейса позволяет? :)
А что за устройства такие?
PS а нафига козе баян? Если у меня дискретный вход/выход = 1 бит, это поддерживается операционной системой контроллера, зачем мне эти фокусы с текстом?
Грубо говоря, 2 строчки на ассемблероподобном языке:
A DB100.DBX100.0 // некоторый флаг в памяти контроллера по адресу: блок данных (подобие массива) номер 100, байт номер 100, 0 бит в байте
= Q10.0 // дискретный выход 0, грубо, в плате с номером 10 (считаем с нуля).
прочитали бит/записали бит. Включили реле и запустили мотор в работу.
Ну нафига тут всякие XML? ;)
В графическом виде программа будет выглядеть примерно так:
DB100.DBX100.0 Q10.0
|----------------| |-----------------------------------------------( )
Если… на том же ModBus на 9600 бит/с устойчивое соединение поднять — иной раз за счастье. Всё-таки, промышленные условия, свои нюансы. Большая дальность (больше 100 м в укладке), высокие помехи, малые объёмы данных.
Опять же — битовая логика она такая битовая :) Это надо данные выгнать в текст, потом на другой стороне его распарсить… А тут мастер читает определённые области памяти слэйва как они есть.
PS а нафига козе баян? Если у меня дискретный вход/выход = 1 бит, это поддерживается операционной системой контроллера, зачем мне эти фокусы с текстом?
Грубо говоря, 2 строчки на ассемблероподобном языке:
A DB100.DBX100.0 // некоторый флаг в памяти контроллера по адресу: блок данных (подобие массива) номер 100, байт номер 100, 0 бит в байте
= Q10.0 // дискретный выход 0, грубо, в плате с номером 10 (считаем с нуля).
прочитали бит/записали бит. Включили реле и запустили мотор в работу.
Ну нафига тут всякие XML? ;)
В графическом виде программа будет выглядеть примерно так:
DB100.DBX100.0 Q10.0
|----------------| |-----------------------------------------------( )
если пропускная способность интерфейса позволяет
Если… на том же ModBus на 9600 бит/с устойчивое соединение поднять — иной раз за счастье. Всё-таки, промышленные условия, свои нюансы. Большая дальность (больше 100 м в укладке), высокие помехи, малые объёмы данных.
Опять же — битовая логика она такая битовая :) Это надо данные выгнать в текст, потом на другой стороне его распарсить… А тут мастер читает определённые области памяти слэйва как они есть.
Мы в основном работали с промышленными электропитающими установками, которые в свою очередь являлись мастерами для других ЭПУ или по крайней мере модулей инверторов, байпассов и так далее. Для нормальной работы с таким количеством данных порой нужно было держать 115200, при этом в бинарном протоколе часто было такое количество «мусора», что xml+gzip нервно курили в сторонке. Это я не говорю про некоторые особо упоротые устройства отечественного производителя, который реализовал в своих железках нечто похожее (но лишь похожее) на SLIP, поверх которого передавал нечто похожее (но лишь похожее) на IP, по которому он передавал нечто похожее на UDP-пакеты. И вдобавок «MTU» был в районе сотни байт, для «надежности», наверное. После такого я был бы рад простому бинарному протоколу. :)
За что я люблю российских производителей — они любят изобретать свои, ни на что не похожие, протоколы :) Profibus в моих проектах, как правило, имеет скорость 1.5 или 12 мегабит, часто по оптике, хватает за глаза. Всё чаще вместо Profibus используем Profinet — в сущности, те же яйца, но физика ethernet вместо 485.
А с Profibus самый большой геморрой, если вдруг случится — настроить телеграмму какого-либо хитрого ведомого устройства. Но это уже не физика, а уровень выше.
В моих случаях даже в системах с количеством точек ввода-вывода порядка 4000 таких гигантских объёмов передавать не требовалось. Было несколько сторонних подсистем, обмен с которыми, как правило, по ModBus. На каждую подсистему свой физический канал.
А с Profibus самый большой геморрой, если вдруг случится — настроить телеграмму какого-либо хитрого ведомого устройства. Но это уже не физика, а уровень выше.
В моих случаях даже в системах с количеством точек ввода-вывода порядка 4000 таких гигантских объёмов передавать не требовалось. Было несколько сторонних подсистем, обмен с которыми, как правило, по ModBus. На каждую подсистему свой физический канал.
Даже в стандартизированном и понятном Modbus бывают чудеса:
производитель железяки и пром. контроллера могут каждый по-своему начинать отсчет адресов (с 0 либо 1), библиотечные функции разных версий могут автоматически сдвигать адреса для нужной области регистров (а могут и не сдвигать).
Пример: нужен первый Holding Register. в итоге может оказаться, что адресом для обращения может оказаться 40000, 40001, 0, 1.
Очень понимаю все те эмоции, что испытал автор :-)
производитель железяки и пром. контроллера могут каждый по-своему начинать отсчет адресов (с 0 либо 1), библиотечные функции разных версий могут автоматически сдвигать адреса для нужной области регистров (а могут и не сдвигать).
Пример: нужен первый Holding Register. в итоге может оказаться, что адресом для обращения может оказаться 40000, 40001, 0, 1.
Очень понимаю все те эмоции, что испытал автор :-)
Про MODBUS согласен. Там есть еще раздел USER_FUNC, в котором может быть все, что угодно.
этот сдвиг — наше всё :)
А ещё некоторые ленивые товарищи могут игнорировать команду 16 (чтение нескольких регистров подряд) — и будьте любезны читать их поштучно :)
А насчёт перестановки байтов — всё не так мрачно. Обычно максимум 4 варианта для double и 2 для word:
0. всё ок.
1. Swap bytes — поменяны местами байты в слове.
далее для двойного слова:
2. Swap word — поменяны местами слова в двойном слове.
3. 1+2: swap byte + swap word.
3 байта — это какое-то суровое извращение, в таких случаях обычно используется двойное слово с одним неиспользуемым байтом (как правило, старшим).
Числа с дробной частью (плавающей точкой), как правило, кодируются в формате IEEE 754 и передаются двойным словом. Остаётся разобраться с особенностями передачи двойного слова (см. выше). Другого я на серийном оборудовании не встречал, надо быть редким извращенцем, чтоб иное использовать.
В простых случаях, и довольно широко, используется фиксированная запятая, где целочисленный регистр надо делить на 10 или 100 (или даже 1000).
Относительно извращённый способ, который мне встречался без использования двойных слов — одно слово обозначает нижний предел, второее — верхний, а само значение — это, по сути, 32768 ступенек между ними :)
И это автор ещё с МЭК 104 не столкнулся — что довольно странно, если участь, что автор делал АСКУЭ ;) Вот тогда бы автор понял, что такое счастье. Но было бы поздно :)
А ещё некоторые ленивые товарищи могут игнорировать команду 16 (чтение нескольких регистров подряд) — и будьте любезны читать их поштучно :)
А насчёт перестановки байтов — всё не так мрачно. Обычно максимум 4 варианта для double и 2 для word:
0. всё ок.
1. Swap bytes — поменяны местами байты в слове.
далее для двойного слова:
2. Swap word — поменяны местами слова в двойном слове.
3. 1+2: swap byte + swap word.
3 байта — это какое-то суровое извращение, в таких случаях обычно используется двойное слово с одним неиспользуемым байтом (как правило, старшим).
Числа с дробной частью (плавающей точкой), как правило, кодируются в формате IEEE 754 и передаются двойным словом. Остаётся разобраться с особенностями передачи двойного слова (см. выше). Другого я на серийном оборудовании не встречал, надо быть редким извращенцем, чтоб иное использовать.
В простых случаях, и довольно широко, используется фиксированная запятая, где целочисленный регистр надо делить на 10 или 100 (или даже 1000).
Относительно извращённый способ, который мне встречался без использования двойных слов — одно слово обозначает нижний предел, второее — верхний, а само значение — это, по сути, 32768 ступенек между ними :)
И это автор ещё с МЭК 104 не столкнулся — что довольно странно, если участь, что автор делал АСКУЭ ;) Вот тогда бы автор понял, что такое счастье. Но было бы поздно :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка и тестирование модуля АСКУЭ