Комментарии 26
Вопросы:
1) На мой взгляд нужно вынести в самое начало ответ на вопрос А какую проблему Вы решаете? Пока, мне кажется, слишком размыто
2) Связана ли Ваша задача с НОРЭМ? Если да, то как?
1) На мой взгляд нужно вынести в самое начало ответ на вопрос А какую проблему Вы решаете? Пока, мне кажется, слишком размыто
2) Связана ли Ваша задача с НОРЭМ? Если да, то как?
0
В более-менее крупной организации, имеющей промышленные здания, необходимо контролировать потребляемые энергоресурсы. На практике это выливается в десятки счетчиков (электроэнергия, газ, отопление, холодная и горячая вода, стоки). Система, о которой идет речь в этой статье, помогает главному энергетику оперативно учитывать расход энергоресурсов, не бегая при этом по подвалам.
С НОРЭМ я не сталкивался, но думаю, что модуль, подобный тому, которыя я разработал пригодился бы и в глабальных системах контроля энергоресурсов.
С НОРЭМ я не сталкивался, но думаю, что модуль, подобный тому, которыя я разработал пригодился бы и в глабальных системах контроля энергоресурсов.
+1
Занимаемся на работе созданием более функциональной системы, чем просто АСКУЭ, с поддержкой более трёх десятков моделей счётчиков. Плюс ещё минимум сотня других устройств. Могу сказать, что на весь этот зоопарк устройств у нас целых три (три!) версии CRC: CRC16-Modbus, CRC16-Xmodem и CRC8. Так что выносить всё это в библиотеку — полезно и нужно.
Если вы планируете разрабатывать систему, к которой можно подключать несколько различных устройств — стоит предусмотреть очень и очень многое. В некоторых устройствах RS485 адрес задается как char, в некоторых — uint16 или uint32, а в некоторых — даже char *. Некоторые устройства способны объединяться в локальную сеть по PLC или CAN-интерфейсу, и в этом случае одно-единственное устройство с RS485 будет служить роутером для всех остальных устройств в сети. Всё это часто осложняется плохой документацией от производителей оборудования, или невозможностью эту документацию получить.
Если вы планируете разрабатывать систему, к которой можно подключать несколько различных устройств — стоит предусмотреть очень и очень многое. В некоторых устройствах RS485 адрес задается как char, в некоторых — uint16 или uint32, а в некоторых — даже char *. Некоторые устройства способны объединяться в локальную сеть по PLC или CAN-интерфейсу, и в этом случае одно-единственное устройство с RS485 будет служить роутером для всех остальных устройств в сети. Всё это часто осложняется плохой документацией от производителей оборудования, или невозможностью эту документацию получить.
+1
Спасибо, что обнадежили насчет CRC. А то у меня сложилось впечатление именно такое, о котором я написал в статье.
0
У нас сначала тоже. Но чем больше было устройств — тем приятнее становилось, что CRC вынесено в библиотеку.
Печальнее всего, что современные устройства используют бинарные протоколы, а не XML, например.
Печальнее всего, что современные устройства используют бинарные протоколы, а не XML, например.
0
При плохой или отсутствующей документации вид протокола не спасет от проблем при разработке.
0
Не спасёт от всех проблем, но реверсить протокол от железки, использующей XML, куда легче, чем реверсить бинарный протокол. Помню, много нервов мне попортили железки Eltek, у которых в контроллерах SmartPack используется протокол с регистрами-многомерными массивами. Задача осложнялась тем, что заводское ПО опрашивало параметры железки не в строго заданном порядке, а в случайном.
0
Думаю, что по RS-485 и подобным протоколам XML передавать слишком накладно. Но должны быть железки, потключаемые прямо по TCP/IP. У них тогда и настроечною морду можно сделать на HTTP. Что-то вроде того, как роутеры сейчас работают. Ну и полный стек Web-сервисов с XML можно организовать.
+1
На линиях RS485 без проблем можно получить как минимум 9600 бит/с, для текстового протокола с умеренным количеством передаваемых данных вполне достаточно. Я железок с XML по RS485 или RS232 не встречал, и только пару раз видел железки с вменяемыми текстовыми протоколами.
Зато очень часто попадались железки, которые через RS232 подключались по PPP. И через установленное соединение показывали web-интерфейс и отправляли snmp-трапы.
Зато очень часто попадались железки, которые через RS232 подключались по PPP. И через установленное соединение показывали web-интерфейс и отправляли snmp-трапы.
0
Старые простые и надёжные протоколы используются и потому, что подобные железяки частенько подключаются к промышленным контроллерам, для которых разбор xml будет очень накладным.
К тому же пром. контроллеры уже содержат на борту перечисленные интерфейсы, и частенько имеют готовые библиотечные блоки для работы по всяким модбасам.
А задача пром. интерфейсов: циклично гнать данные. Очень часто, очень надежно, но по чуть-чуть
К тому же пром. контроллеры уже содержат на борту перечисленные интерфейсы, и частенько имеют готовые библиотечные блоки для работы по всяким модбасам.
А задача пром. интерфейсов: циклично гнать данные. Очень часто, очень надежно, но по чуть-чуть
+2
Вот мы как раз и разрабатывали на работе промышленный контроллер, который должен был поддерживать целый зоопарк оконечного оборудования. И когда в таблице из 4000 наименований устройств мы находили какое-нибудь с MODBUS, то очень сильно радовались. Средний проприетарный протокол от «умного» устройства мы «раскуривали» около недели, включая всевозможные тесты с разными модификациями одного устройства.
+2
Странные у вас представления, однако…
Основное назначение этих протоколов — связь между устройствами. В устройствах часто используются относительно слабые процессоры. Более того, собирать/разбирать бинарные протоколы несколько проще, чем кучу текста — особенно, на устройствах.
например, автор называет ModBus надёжным и проверенным решением. В какой-то степени он прав, но когда на объекте сталкиваешься с небольшим зоопарком, висящим на одной шине — он перестаёт казаться надёжным :)
Основное назначение этих протоколов — связь между устройствами. В устройствах часто используются относительно слабые процессоры. Более того, собирать/разбирать бинарные протоколы несколько проще, чем кучу текста — особенно, на устройствах.
например, автор называет ModBus надёжным и проверенным решением. В какой-то степени он прав, но когда на объекте сталкиваешься с небольшим зоопарком, висящим на одной шине — он перестаёт казаться надёжным :)
0
Всё верно, основное назначение протоколов — связь между устройствами. Вот только использовать слабые процессоры в мелкосерийке сейчас почти бессмысленно — по стоимости конечных устройств много не выгадаешь, а по скорости/удобству разработки и отлаженности результирующего кода разработка на ассемблере и парсинг бинарных протоколов сливают ЯВУ и сериализованным в XML/JSON протоколам. За счёт этого компания, в которой я работал раньше, и выиграла тендер — поставила чипы условно на бакс дороже, чем у конкурентов, но зато мощные ARM, и смогла выпустить готовый продукт быстрее и более высокого качества.
Многие протоколы, которые пришлось поддерживать, были бинарными. Часть из них была крайне сложной и запутанной, в том числе с признанными багами со стороны производителя (например, счётчик внезапно мог зависнуть и выплюнуть содержимое всей своей памяти на RS485). Реализации modbus у разных производителей тоже порой значительно отличались, особенно для float-значений и массивов. И только текстовые протоколы с контрольными суммами были эффективны (при условии, что интервал между запросами >> времени на передачу запроса) и надежны. Такая вот история.
Многие протоколы, которые пришлось поддерживать, были бинарными. Часть из них была крайне сложной и запутанной, в том числе с признанными багами со стороны производителя (например, счётчик внезапно мог зависнуть и выплюнуть содержимое всей своей памяти на RS485). Реализации modbus у разных производителей тоже порой значительно отличались, особенно для float-значений и массивов. И только текстовые протоколы с контрольными суммами были эффективны (при условии, что интервал между запросами >> времени на передачу запроса) и надежны. Такая вот история.
0
Я вам ниже написал, почему и для чего используются бинарные протоколы и не используются текстовые.
Даже если предположить, что мы засунули в контроллер условный 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 нервно курит в сторонке.
+1
Я понял ваше мнение, и в значительной степени с ним согласен — как разработчик железок. Как программист — я хочу использовать простые человекочитаемые форматы данных, с которыми легко работать.
Есть как минимум www.greenbuttondata.org/use/
В общем, предлагаю дискуссию закончить. Мне нравятся ваши аргументы.
По этим причинам никто и никогда не будет использовать в автоматике XML.
Есть как минимум www.greenbuttondata.org/use/
В общем, предлагаю дискуссию закончить. Мне нравятся ваши аргументы.
0
Они вполне себе человекочитаемые, если есть карта регистров :)
К слову, транспортные протоколы, типа TCP — совершенно нечеловекочитаемые, но вас не смущает, что ваши данные передаются с их использованием.
И, в ряде случаев, с бинарными данными работать даже легче. Не всё так однозначно.
А дискуссия, согласен, зашла в тупик. Дальше есть шансы продолжить по Жванецкому: «Убедить мне вас не удастся, поэтому сразу перейду к оскорблениям» :)))
PS Я с вами совершенно согласен в том, что заглянуть внутрь текстового XML протокола гораздо легче. Но даже не в контексте промышленной автоматики для того, чтоб распарсить XML, желательно иметь библиотеки для этого, всякие типы данных Variant и прочие блэкджеки. Поэтому, даже на ЯВУ работать с бинарным протоколом может быть удобнее и уж точно менее требовательно к количеству передаваемых данных, объёму памяти и быстродействию процессора.
Другое преимущество XML — в него проще добавить какие-либо новые данные либо данные переменной длины без того, чтоб развалить весь пакет к чОртовой бабушке.
К слову, транспортные протоколы, типа TCP — совершенно нечеловекочитаемые, но вас не смущает, что ваши данные передаются с их использованием.
И, в ряде случаев, с бинарными данными работать даже легче. Не всё так однозначно.
А дискуссия, согласен, зашла в тупик. Дальше есть шансы продолжить по Жванецкому: «Убедить мне вас не удастся, поэтому сразу перейду к оскорблениям» :)))
PS Я с вами совершенно согласен в том, что заглянуть внутрь текстового XML протокола гораздо легче. Но даже не в контексте промышленной автоматики для того, чтоб распарсить XML, желательно иметь библиотеки для этого, всякие типы данных Variant и прочие блэкджеки. Поэтому, даже на ЯВУ работать с бинарным протоколом может быть удобнее и уж точно менее требовательно к количеству передаваемых данных, объёму памяти и быстродействию процессора.
Другое преимущество XML — в него проще добавить какие-либо новые данные либо данные переменной длины без того, чтоб развалить весь пакет к чОртовой бабушке.
+1
Поясню на примере. Есть у меня, скажем, мотор. Применительно к нему у меня может быть несколько флагов, например: состояние (включен/выключен), переключатель режима (автомат/ручной), ручной выключатель (вкл/выкл), состояние автомата (включен/отключен), выключатель по месту (вкл/откл), защита по перегреву, контроль изоляции, выходная команда контроллера. Итого получилось 7 бит. Всё это я упихиваю в слово, которое обычно называют словом состояния. Именно в таком виде я использую это в контроллере (у меня там обычная битовая логика) — сношаться с XML и прочими текстами в контроллере я никому не пожелаю. Это слово я в том виде, в каком оно есть, передаю в скаду, например. Там разбираю на биты с помощью битовых масок и and/or, чтобы отобразить на экране. Кроме того, отдаю это одну переменную, а не семь — скады почти всегда лицензируются по количеству переменных.
Моторов этих на установке может быть до и больше, и все их надо циклически читать (а есть ещё ряд параметров, кроме слова состояния, да и другие объекты, кроме моторов). Всё это можно с приемлемым интервалом обновления засунуть в интерфейс со скоростью 9.6/19.2 кбит/с. А если некто сторонний хочет XML — то флаг ему в руки, меня это не волнует :)
Моторов этих на установке может быть до и больше, и все их надо циклически читать (а есть ещё ряд параметров, кроме слова состояния, да и другие объекты, кроме моторов). Всё это можно с приемлемым интервалом обновления засунуть в интерфейс со скоростью 9.6/19.2 кбит/с. А если некто сторонний хочет XML — то флаг ему в руки, меня это не волнует :)
0
Для такой задачи — да, бинарный протокол от устройства может быть наилучшим решением. У нас управляемые устройства были значительно сложнее, с тысячами и десятками тысяч параметров разных типов — int, float, str, двумерные и трехмерные массивы.
p.s. А в чём проблема отформатировать строку на контроллере, если пропускная способность интерфейса позволяет? :)
p.s. А в чём проблема отформатировать строку на контроллере, если пропускная способность интерфейса позволяет? :)
0
А что за устройства такие?
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 м в укладке), высокие помехи, малые объёмы данных.
Опять же — битовая логика она такая битовая :) Это надо данные выгнать в текст, потом на другой стороне его распарсить… А тут мастер читает определённые области памяти слэйва как они есть.
0
Мы в основном работали с промышленными электропитающими установками, которые в свою очередь являлись мастерами для других ЭПУ или по крайней мере модулей инверторов, байпассов и так далее. Для нормальной работы с таким количеством данных порой нужно было держать 115200, при этом в бинарном протоколе часто было такое количество «мусора», что xml+gzip нервно курили в сторонке. Это я не говорю про некоторые особо упоротые устройства отечественного производителя, который реализовал в своих железках нечто похожее (но лишь похожее) на SLIP, поверх которого передавал нечто похожее (но лишь похожее) на IP, по которому он передавал нечто похожее на UDP-пакеты. И вдобавок «MTU» был в районе сотни байт, для «надежности», наверное. После такого я был бы рад простому бинарному протоколу. :)
0
За что я люблю российских производителей — они любят изобретать свои, ни на что не похожие, протоколы :) Profibus в моих проектах, как правило, имеет скорость 1.5 или 12 мегабит, часто по оптике, хватает за глаза. Всё чаще вместо Profibus используем Profinet — в сущности, те же яйца, но физика ethernet вместо 485.
А с Profibus самый большой геморрой, если вдруг случится — настроить телеграмму какого-либо хитрого ведомого устройства. Но это уже не физика, а уровень выше.
В моих случаях даже в системах с количеством точек ввода-вывода порядка 4000 таких гигантских объёмов передавать не требовалось. Было несколько сторонних подсистем, обмен с которыми, как правило, по ModBus. На каждую подсистему свой физический канал.
А с Profibus самый большой геморрой, если вдруг случится — настроить телеграмму какого-либо хитрого ведомого устройства. Но это уже не физика, а уровень выше.
В моих случаях даже в системах с количеством точек ввода-вывода порядка 4000 таких гигантских объёмов передавать не требовалось. Было несколько сторонних подсистем, обмен с которыми, как правило, по ModBus. На каждую подсистему свой физический канал.
+1
Даже в стандартизированном и понятном Modbus бывают чудеса:
производитель железяки и пром. контроллера могут каждый по-своему начинать отсчет адресов (с 0 либо 1), библиотечные функции разных версий могут автоматически сдвигать адреса для нужной области регистров (а могут и не сдвигать).
Пример: нужен первый Holding Register. в итоге может оказаться, что адресом для обращения может оказаться 40000, 40001, 0, 1.
Очень понимаю все те эмоции, что испытал автор :-)
производитель железяки и пром. контроллера могут каждый по-своему начинать отсчет адресов (с 0 либо 1), библиотечные функции разных версий могут автоматически сдвигать адреса для нужной области регистров (а могут и не сдвигать).
Пример: нужен первый Holding Register. в итоге может оказаться, что адресом для обращения может оказаться 40000, 40001, 0, 1.
Очень понимаю все те эмоции, что испытал автор :-)
+2
Про MODBUS согласен. Там есть еще раздел USER_FUNC, в котором может быть все, что угодно.
+1
этот сдвиг — наше всё :)
А ещё некоторые ленивые товарищи могут игнорировать команду 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 не столкнулся — что довольно странно, если участь, что автор делал АСКУЭ ;) Вот тогда бы автор понял, что такое счастье. Но было бы поздно :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изменить настройки темы
Разработка и тестирование модуля АСКУЭ