Протокол обмена с датчиком ПДЭ-010 модель 130

а в чем проблема запросить документацию у производителя?

Не дадут боюсь они ее, раз на сайте нет, то и так не дадут наверное

Ну так пишут, что протокол похож на Modbus ASCII, а это стандартный и простой протокол. Проверь уж тогда, похоже ли то, что пишет АРМ в прибор на Modbus. В общем, это может быть либо Modbus ASCII (текстовый) либо Modbus RTU.

Преобразователи могут быть подключены через USB-порт к персональному компьютеру (ПК), для обработки и индикации показаний измеренных значений давлений, настройки преобразователей; а также ко вторичной аппаратуре, принимаю- щей цифровой сигнал по специальному протоколу, аналогичному протоколу Modbus ASCII.

http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf

Не дадут боюсь они ее, раз на сайте нет, то и так не дадут наверное

Абсолютно неверно. Часто запрашивал документацию к железкам, которой нет на сайте, по почте - все зависит от адекватности фирмы. Не бойся, просто напиши в техподдержку - не думаю, что побьют или счёт выставят))

Здравствуйте! Благодарю за ответ. С Modbus раньше не работал, немного почитал про формат пакетов - не очень похоже на то, что выдает прибор в АРМ. Вот, например, ответ прибора в хексе на посылки из АРМ:

01: FF 21 32 34 31 3B 34 33 3B 34 37 37 32 30 0D 02: FF 21 32 34 31 3B 24 30 3B 33 36 37 31 33 0D 03: FF 21 32 34 31 3B 37 36 34 30 30 30 30 30 3B 35 34 35 30 31 0D 04: FF 21 32 34 31 3B 35 36 33 33 32 45 33 30 33 33 32 45 33 30 33 30 32 30 34 41 37 35 36 45 32 30 33 32 33 39 32 30 33 32 33 30 33 31 33 31 32 30 30 30 33 32 30 30 30 32 3B 36 30 37 33 37 0D 05: FF 21 32 34 31 3B 30 30 30 30 30 30 30 30 3B 33 35 39 30 0D 06: FF 21 32 34 31 3B 30 30 30 30 43 38 34 32 3B 31 30 38 39 0D 07: FF 21 32 34 31 3B 30 31 3B 36 39 35 32 0D 08: FF 21 32 34 31 3B 30 33 3B 33 31 35 32 39 0D 09: FF 21 32 34 31 3B 30 32 3B 36 30 32 30 30 0D 10: FF 21 32 34 31 3B 30 31 3B 36 39 35 32 0D 11: FF 21 32 34 31 3B 30 30 3B 33 35 36 32 35 0D

01: 02: - это уже я добавил для читаемости. Вижу, конечно, что последовательность FF 21 32 34 31 3B есть в каждой посылке, что каждая посылка заканчивается на 0D и даже знаю, например, что в посылке 3 закодирован заводской номер прибора, который в АРМЕ отображается как «00016502», но вот как именно АРМ вытягивает, например, этот заводской номер из этой посылки - не могу догадаться, в WinHex-е все просматривал, крутил-вертел, не понимаю. АРМ в зависимостях ссылается на crypt32.dll, может быть зашифрованы эти байты даже, не уверен.

Вот пример посылок, которые посылает АРМ в прибор

01: FF 3A 32 34 31 3B 30 3B 30 3B 36 35 34 30 35 0D 02: FF 3A 32 34 31 3B 33 38 3B 30 30 30 30 32 34 3B 46 30 30 30 3B 34 32 31 32 38 0D 03: FF 3A 32 34 31 3B 33 37 3B 30 30 30 30 38 42 3B 34 30 39 30 0D

Формат как будто похож на Modbus ASCII, но попытался просуммировать байты, например, в третьей посылке, начиная с 3-го и не беря последний, т.е. 32 34 31 3B 33 37 3B 30 30 30 30 38 42 3B 34 30 39 30 - нуль не получается, хотя вроде бы должен быть, если я правильно почитал спецификацию modbus asccii, т.к. в пакете зашита проверка LRC.

Извините, если сумбурным вышло изложение. Вам не говорят последовательности эти байтов ни о чем?

напиши в техподдержку - не думаю, что побьют или счёт выставят))

Благодарю за совет, напишу тогда, попытка - не пытка, действительно, тем более что для Линукса не нашел программного обеспечения на сайте производителя.

что в посылке 3 закодирован заводской номер прибора, который в АРМЕ отображается как «00016502»,

Вам не говорят последовательности эти байтов ни о чем?

Я прикинул и кое-что понял. Эти записи в протоколе - это числа в шестнадцатиричном коде, но записанные ASCII символами.

Вот смотри. Смотрим твою третью посылку:

03: FF 21 32 34 31 3B 37 36 34 30 30 30 30 30 3B 35 34 35 30 31 0D
03: FF 21  2  4  1  ;  7  6  4  0  0  0  0  0  ;  5  4  5  0  1 0D

Сразу видно, что 3B везде - это разделитель полей. То есть в этой посылке два поля.

А теперь фокус-покус. Заводской номер 00016502. то есть число 16502 в шестнадцатиричиной записи - это 00004076h, если ее записать в машинном виде как little-endian, то получаем строчку «76 40 00 00». А теперь финт - записываем эту строчку ascii, «37 36 34 30 30 30 30 30». То есть заводской номер - это 32-битное число в little-endian формате, четыре байта, восемь символов, записанных через ascii. Скорее всего и все числа так записаны.

И есть слабое предположение, что последнее поле - это контрольная сумма, но только надо выяснить алгоритм ее подсчета.

Огромное Вам спасибо, прекрасный анализ данных, заводской номер действительно закодирован именно так, как Вы написали, уверен в этом потому что у меня есть второй прибор, третий пакет для этого прибора выглядит следующим образом

03: FF 3A 32 34 31 3B 33 37 3B 30 30 30 30 31 43 3B 34 30 32 33 35 0D

заводской номер этого прибора 16234, по Вашему алгоритму получил его. Также с Вашей помощью разобрался с этой статьей http://www.simplymodbus.ca/ASCII.htm а именно с таблицей. Буду дальше анализировать посылки датчиков - у меня их 3, по 11 пакетов обмена на каждый датчик, может быть удастся понять как закодирована контрольная сумма, о которой Вы сказали.

FF 21 32 34 31

FF 3A 32 34 31

А вот заголовки посылок у разных девайсов отличаются. FF, скорее всего, это байт начала посылки и он не имеет никакого смыслового значения кроме разделителя. Увидел FF — значит, дальше посылка. А вот дальше идут четыре байта. Это может быть закодированным типа устройства (разные датчики производителя разного назначения могут иметь разный код) и плюс еще это может быть какой-то логический номер устройства (если они, скажем, на шине). Можно предположить, что 32 34 31 - это устройство «ПДЭ-010 модель 130», но надо проверить. А вот 21 и 3A могут быть именно логическими номерами устройств. Там АРМ этот ничего не говорит? Есть ли там такой параметр, который можно запрограммировать в устройство?

это может быть версия протокола

Ну, быть может. Просто обычно во всякой промышленной автоматике гораздо надежнее понимать, от кого пришла та или иная посылка прямо по информации в ней, а не выясняя, что сейчас к какому порту или шине подключено. Дали устройствам логический номер и они шлют его каждую посылку (именно так и есть у него - у первого устройства одна последовательность в заголовке, а у второго чуть-чуть отличается в одном байте). Ну и хорошо бы еще знать, что за устройство прислало данные: датчик давления или температуры и какой именно. Фирменный софт может это распознать по заголовку, который шлется каждую посылку. А вот какой смысл версии протокола менять и каждый раз слать... В принципе, есть смысл, если он отличается логически. но мне кажется, что тут протокол простой как валенок: числа через разделитель стартовый символ, стоп-символ, контрольная сумма и данные через точку с запятой. И этот протокол у устройств этого производителя одинаковый, чтобы их типа в комплекс можно было включить. Или программировать только их софтом.

Протокол тут не похож на Modbus. больше похоже на то, что видоизмененный какой-то, чтобы на свой софт завязать. Возможно, что Modbus тоже есть, но для этого, может, надо что-то там переключить.

А вот 21 и 3A могут быть именно логическими номерами устройств.

А, нет, нифига. Я так понимаю, что 21 - это когда устройство присылает данные, а 3A - когда контроллер или компьютер пишет что-то в устройство.

И 21 может быть адресом, который производитель ставит по умолчанию для всех. (предположение), а компьютер как бы 3A. Но это вслепую предположения.

UPD, Или эти числа фиксированы. 3Ah - это как раз стандартный разделитель Modbus - ":", а 21h - это "!". Типа знака ответа устройства.

Да, номер устройства действительно логичнее. Просто я возился с gps датчиками, там в некоторых протоколах была версия, ну и идентификатор устройства был, но только если там udp, для тех что tcp использовали - номер был в заголовке, в виде серийника. А как тут для ком-порта - не знаю.

Буду дальше анализировать посылки датчиков - у меня их 3, по 11 пакетов обмена на каждый датчик, может быть удастся понять как закодирована контрольная сумма, о которой Вы сказали.

Мне кажется, что закодирована она хитро. Ну, если только мы считаем, что последнее поле после 3B — действительно контрольная сумма. Я предполагаю, что это так, потому что она каким-то слишком непредсказуемым образом меняется. И вот пример почти одинаковых посылок, а последнее поле, то пять символов, то четыре:

07: FF 21 32 34 31 3B 30 31 3B  36 39 35 32 0D
09: FF 21 32 34 31 3B 30 32 3B  36 30 32 30 30 0D
08: FF 21 32 34 31 3B 30 33 3B  33 31 35 32 39 0D

Отличие в одном байте у посылок. И странно, что то четыре символа, то пять. Однако я заметил одну особенность по тем данным, что ты изложил. Других нет. Особенность такая: последнее поле не содержит hex-символов A, B, C, D, E, F, а только десятичные цифры. Я предполагаю, что контрольная сумма в последнем поле записана в ДЕСЯТИЧНОМ виде в ASCII.

07: FF 21 32 34 31 3B 30 31 3B  36 39 35 32 0D
                                 6  9  5  2 -> 1B28 hex
09: FF 21 32 34 31 3B 30 32 3B  36 30 32 30 30 0D
                                 6  0  2  0  0 -> EB28 hex
08: FF 21 32 34 31 3B 30 33 3B  33 31 35 32 39 0D
                                 3  1  5  2  9 -> 7B29 hex

Я в твоих данных не увидел ни одного символа A-F в последнем поле. Выше показано, что если перевести это число в hex, то будет число из двух байт (проверь встречаются когда-нибудь числа выше 65535?). Моя гипотеза, что это CRC16, но записанная в десятичном формате. Значит надо проверить, по каким данным она считается.

Она может считаться по сырым данным до перекодирования в ASCII, она может считаться по данным после перекодирования в ASCII, она может считаться без учета заголовка или без учета части заголовка. Она считается наверняка без учета OD. В общем, тут надо взять любой онлайн-калькулятор контрольных сумм или программу написать и тупо проверять гипотезу.

Такой, например. https://www.lammertbies.nl/comm/info/crc-calculation.html

ВСЕ! ЕСТЬ! Понял как считается! Ща напишу

Это CRC-16 (Modbus). См. калькулятор. Считается она по уже закодированной ASCII посылке без учета заголовка FF 21 (в случае компьютера - без учета FF 3A) и с учетом разделителей 3B.

Допустим, у нас есть уже закодированная посылка с заводским номером и каким-то полем спереди (возможно, это номер устройства или модель устройства): 32 34 31 3B 37 36 34 30 30 30 30 30 3B

Считаем по калькулятору CRC-16 (Modbus) в режиме HEX и получаем 0xD4E5 = 54501. Переводим десятичную текстовую запись «54501» или «35 34 35 30 31», добавляем сзади OD, спереди заголовок FF 21 и получаем твою:

03: FF 21 32 34 31 3B 37 36 34 30 30 30 30 30 3B 35 34 35 30 31 0D
03: FF 21  2  4  1  ;  7  6  4  0  0  0  0  0  ;  5  4  5  0  1 0D

Но в итоге я присоединяюсь к совету комментаторов выше сначала попросить протокол у производителя. Написать им или позвонить, объяснить, что надо читать данные и программировать в Линуксе, поэтому ваше ПО не подходит, что написать программу можешь сам. Есть большая вероятность, что документ с протоколом у них есть и они лично тебе его смогут прислать. Однако бывают сильно забюрократизированные конторы, в которых так никто и не возьмет ответственность за передачу протокола кому бы то ни было. Будут ходить, выяснять, можно ли или нельзя, а потом вообще забьют или откажут.

Могут сразу отказать из-за принципиальной позиции: мол, это интеллектуальная такая собственность, а злые американцы или китайцы украдут наш супер-пупер протокол. :)

Другой вариант, который у нас в РФ, однако, не так часто встречается - дадут под NDA за подписью твоей организации. Но тут уже самому надо думать, подписывать с ними что-то или нет и на каких условиях. Если все пойдет по сценарию, «не дадим» или «под NDA», то можно с чистой душой делать дальше реверс-инжиниринг. Основные вещи уже и так понятны, можно и без документации обойтись, но просто время потратить придется, чтобы до конца разобратсья с полями и форматами.

Есть большая вероятность, что документа с протоколом у них есть

Надо было так:

Есть большая вероятность, что документа с протоколом у них... есть

FF 3A 32 34 31

FF, скорее всего, это байт начала посылки и он не имеет никакого смыслового значения кроме разделителя. Увидел FF — значит, дальше посылка. А вот дальше идут четыре байта.

Это наверное
FF 3A - адрес устройства
32 34 31 - код функции

Это наверное
FF 3A - адрес устройства
32 34 31 - код функции

Склонен думать по-другому. FF - синхронизационный стартовый символ, который в принципе не может встречаться внутри посылки. приемник ожидает этот символ, а потом принимает все до OD.

«32 34 31» полагаю, что это именно номер устройства, записанный в ASCII, то есть 241. В протоколе Modbus есть такое поле в посылках. За это говорит тот факт, что это поле в каждом типе ответа и команды неизменно присутствует и не меняется:

https://ru.wikipedia.org/wiki/Modbus

адрес ведомого устройства — адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 — зарезервированы;

Тут много функций выложено, но это поле всегда одинаковое. Причем его также посылает компьютер (master), обращаясь к конкретному устройству на шине как бы. Так как у двух разных устройств это поле 241 (он попробовал другой девайс тоже), то полагаю, что это значение по умолчанию, которое можно переназначить.

А 21/3A (!/:) может быть символом, обозначающим slave/master. Или может быть адресом тоже. Пока не ясно. Вот наверняка у него АРМ что-то такое пишет по этому поводу.

Благодарю Вас, всё действительно сходится. Набрал себе тематической литературы, чтобы быть в теме, потому что очень много из того, что Вы изложили для меня в новинку. Насчет начальных байтов в первой посылке 21/3A (!/:), я внимательно посмотрю еще на интерфейс АРМ-а, как будто никаких сведений о slave/master устройстве там не было, завтра выложу скриншоты программы. Осталось мне разобрать то, как датчик передает данные о том, какое измеренное значение на нем - в АРМ-е есть режим измерения, он в реальном времени строит график давления, подключусь к COM-порту и посмотрю как происходит обмен, но думаю, что теперь, имея всю предоставленную Вами информацию, я разберусь.Еще раз большое спасибо Вам, с программированием промышленной автоматики ранее не встречался, поэтому сам бы неизвестно сколько доходил бы того, чтобы разобраться с протоколом.

С производителем тоже свяжусь - на днях все равно поеду кним, чтобы забрать еще один интерфейс для связи с датчиком, может заодно договорюсь о встрече с человеком, который обсудить этот вопрос будет готов.

Ну, точно - 241 («32 34 31») - это адрес устройства. Вот выдержка из «ПРЕОБРАЗОВАТЕЛИ ДАВЛЕНИЯ эталонные ПДЭ-010.Руководство по эксплуатации»

2.2.10 При необходимости проведите проверку и изменение конфигурации преобразователя, подключив его к компьютеру и запустив программу настройки, входящую в комплект поставки преобразователей. При работе с программой настройки в графе «Адрес» должен быть установлен код 241.

Насчет начальных байтов в первой посылке 21/3A (!/:), я внимательно посмотрю еще на интерфейс АРМ-а, как будто никаких сведений о slave/master устройстве там не было,

Так а зачем там сведения? Это в протокол заложено, как и в Modbus (см wikipedia). master - это всегда либо контроллер, либо компьютер, а slave - это датчик. Но в классическом Modbus нет в протоколе обозначения ведущий/ведомый, но в этой ПДЭ и не чистый modbus, а что-то такое «по мотивам».

Производитель прислал протокол обмена, Вы все правильно сказали. Цитирую протокол

Любой запрос или ответ должен начинаться с посылки кода 0xFF
Запрос :<адрес прибора>;<Cmd>[;параметры команды];<контрольная сумма><CR>
Ответ !<адрес прибора>;<Cmd>[;параметры команды];<контрольная сумма><CR>
':' и "!" указывают на начало посылки

хотя в протоколе, который они прислали не описаны последовательности байт, которые соответствуют функциям, но с Вашей помощью и подключая имеющийся АРМ думаю уже получится написать программу под Linux, которая снимать данные с прибора будет

Вот, например, ответ прибора в хексе на посылки из АРМ:

01: FF 21 32 34 31 3B 34 33 3B 34 37 37 32 30 0D

Ответ !<адрес прибора>;<Cmd>[;параметры команды];<контрольная сумма><CR>

Что-то не сходится. По дампу получается, что ответ тоже начинается с ":", не с "!".

Вроде нет. Все правильно. Просто он по ошибке не то скопировал один раз. Сказал, что это датчик отвечает, а выложил какой-то запрос компьютера. Там должен был быть ответ второго датчика давления с его заводским номером.

А в первом сообщении как раз все правильно. Все ответы прибора с "!" и одно место, где показано, что компьютер в прибор шлет ":". Цитата:

Вот пример посылок, которые посылает АРМ в прибор

01: FF 3A 32 34 31 3B 30 3B 30 3B 36 35 34 30 35 0D 02: FF 3A 32 34 31 3B 33 38 3B 30 30 30 30 32 34 3B 46 30 30 30 3B 34 32 31 32 38 0D 03: FF 3A 32 34 31 3B 33 37 3B 30 30 30 30 38 42 3B 34 30 39 30 0D

Я видимо ошибся действительно, ответ прибора начинается с "!", а запись в прибор с АРМ-а с ":"

хотя в протоколе, который они прислали не описаны последовательности байт, которые соответствуют функциям,

А почему? Просто забыли или явно сказали, что это уже не дают? Нет, у них это даже может быть не задокументировано.

Я когда-то работал в компании, продукцию для которой делали болгары, так у них даже протокол обмена не был задокументирован. На очень долгие просьбы предоставить (предоставлять не хотели, но его хакнули), они через несколько лет только прислали протокол. Что это за бумаженция была. даже трудно передать. Чего-то не было, что-то вообще, видимо, от старых версий протокола, где-то явно неточности или вообще описания нет. Наш документ реверс-инжиниринга и то был лучше.

Я так понимаю, что они тебе прислали только формат кадра, но сам протокол (команды, ответы) они не прислали. Это, считай, что вообще ничего не прислали. Запроси еще раз. Вдруг еще что-нибудь дадут?

Вообще, конечно, пипец ребятки. Зачем-то придумали какой-то доморощенный протокол вместо стандартного Modbus как минимум. Устройство с Modbus можно интегрировать в стандартные контроллеры сбора данных, системы SCADA. Но нет! Это не наш путь! Надо сделать несовместимый протокол.

Если у них модель такая же, как и у Modbus, то обычно устройства, которые работают через Modbus в документации пишут карту регистров input/holding registers, дискретных входов , coils, их назначение и диапазон значений. Например в этом датчике могут быть регистры, содержащие калибровочные коэффициенты и др. параметры. Но вроде как в документации этого нет (?)