ТРМ201 опрос с ПК по протоколу Modbus

В описании на ТРМ201 сказано, что данный прибор можно опросить по протоколу modbus, чтобы считать какие-то параметры, например. Но нигде нет примеров какой должна быть посылка простейшего запроса. По опыту работы с модбасом сталкивался с тем, что производители то и дело отклоняются от этого "стандарта", поэтому хотелось бы спросить у Овена, какую последовательность байт я должен отправить по СОМ-порту, чтобы ТРМ201 вернул мне измеренную величину?

Формат посылки для запроса:
buf[0] = 0; //адрес прибора
buf[1] = 0x03; //функция чтения регистра
buf[2] = 0x00; //старший байт адреса регистра
buf[3] = 0x01; //младший байт адреса регистра
...
А потом? Проще говоря, меня интересует формат посылки для запроса параметров с прибора.

От стандарта мы не откланяемся. Иначе это было бы описано в документации. Формат посылки на запрос (COM7)Tx: [8] 08 03 00 00 00 01 31 53

То есть посылается 8 байт в hex: 0x08 0x03 0x00 0x00 0x00 0x01 0x31 0x53, где 0x08 - адрес прибора, 0х03 - номер функции, 0х00 и 0х00 адрес регистра STAT, 0x00 и 0х01 - это видимо кол-во регистров, которые надо получить, в нашем случае всегда будет один, если будем по одному запрашивать, 0х31 и 0х53 - CRC16. Всё правильно? Тогда по какому алгоритму вы считаете CRC-код? Считаю код для первых 6 байт, у меня получается 0x08, 0x03, 0x00, 0x00, 0x00, 0x01, 0x84, 0x93. Вот алгоритм, используется полином 0xA001, не табличный метод. Видимо поэтому ТРМ201 мой запрос и отвергает.

P.S.: Подключаюсь к прибору через приложение-конфигуратор без проблем, т.е. связь с прибором есть. В настройках СОМ-порта поставил 8 бит данных, без чётности, 2 стоп-бита. Проверил в меню прибора параметр "h.rtU" (в конфигураторе версии 2.2.0.6 сменить протокол нельзя, только настроить на внешнее управление от RS-485).

Цитата:

---

Сообщение от Максим Tomahawk

То есть посылается 8 байт в hex: 0x08 0x03 0x00 0x00 0x00 0x01 0x31 0x53, где 0x08 - адрес прибора, 0х03 - номер функции, 0х00 и 0х00 адрес регистра STAT, 0x00 и 0х01 - это видимо кол-во регистров, которые надо получить, в нашем случае всегда будет один, если будем по одному запрашивать, 0х31 и 0х53 - CRC16. Всё правильно? Тогда по какому алгоритму вы считаете CRC-код? Считаю код для первых 6 байт, у меня получается 0x08, 0x03, 0x00, 0x00, 0x00, 0x01, 0x84, 0x93. Вот алгоритм, используется полином 0xA001, не табличный метод. Видимо поэтому ТРМ201 мой запрос и отвергает.

---

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

capzap, зачем использовать что-то неизвестное, если "своё" работает с кучей типов приборов уже много лет и опрашивает их сотнями? Всего-то надо послать пару байт через СОМ-порт, потом прибор должен выдержать свой интервал тишины и отправить в ответ свои несколько байтов. Зачем мне для этого целая библиотека, если я собираюсь считывать всего 1 регистр, например?

Цитата:

---

Сообщение от Максим Tomahawk

capzap, зачем использовать что-то неизвестное, если "своё" работает с кучей типов приборов уже много лет и опрашивает их сотнями? Всего-то надо послать пару байт через СОМ-порт, потом прибор должен выдержать свой интервал тишины и отправить в ответ свои несколько байтов. Зачем мне для этого целая библиотека, если я собираюсь считывать всего 1 регистр, например?

---

потому чтио Вы в этом не разбираетесь, чтобы Вы там не говорили. Нет проблем с ответом у трмов по модбас, хоть с собственоручной посылкой запроса что на плк, что на ПК

capzap, если всё знаете, тогда может быть вы на мои вопросы ответите? :) Какую последовательность байт надо отправить на ТРМ201 с адресом 8, чтобы получить измеренное значение входной величины (параметр PV). Какой мне инструмент для этого использовать я сам разберусь, спасибо за советы.

Цитата:

---

Сообщение от Максим Tomahawk

capzap, если всё знаете, тогда может быть вы на мои вопросы ответите? :) Какую последовательность байт надо отправить на ТРМ201 с адресом 8, чтобы получить измеренное значение входной величины (параметр PV). Какой мне инструмент для этого использовать я сам разберусь, спасибо за советы.

---

последовательность на видео в правом окошке

capzap, спасибо. Запись 08 03 00 01 00 01 D5 53, ответ 08 03 02 00 00 64 45. Запрашивается PV регистр по адресу 0х0001. CRC16 тут считается верно, мой алгоритм тоже верно считает. У G.Mark значит просто для примера crc-код был написан. В этом я и хотел убедиться.

Пока тут разбирался, поставил сниффер и смотрел что конфигуратор на прибор шлёт. У него там какие-то свои служебные функции. Например, при чтении значения PV он посылает на ТРМ201 23 47 4F 48 47 52 4F 54 56 4C 4C 53 4A 0D, приходит пакет вида 23 47 4F 47 4A 52 4F 54 56 4B 49 51 50 4C 4E 52 4E 50 4F 0D, здесь последние ~7 байт меняются. Через моё приложение по такому же запросу ответ аналогичный. А вот на запрос 08 03 00 01 00 01 D5 53 ответ пока не приходит, хотя с точки зрения модбаса посылка верная. Возможно надо изменить какие-то настройки СОМ-порта, но это уже другая история.

Конфигуратор общается с приборами по протоколу ОВЕН. И если ТРМ отвечает конфигуратору, то ТРМ настроен на общение с внешним миром по протоколу ОВЕН, и соответственно на modbus-запросы отвечать не будет...

Цитата:

---

Сообщение от Гарчев Евгений

Конфигуратор общается с приборами по протоколу ОВЕН. И если ТРМ отвечает конфигуратору, то ТРМ настроен на общение с внешним миром по протоколу ОВЕН, и соответственно на modbus-запросы отвечать не будет...

---

Действительно, так и получается, 0х23 это код символа #, а 0x0D код символа CR, в протоколе Овен это прочитал. Раньше с ним не работал, поэтому сразу и не понял, что это он ) В конфигураторе нельзя выбрать протокол (а зря), поэтому я смотрел в меню самого прибора параметр h.rtU, увидел его и успокоился. Позднее каким-то образом прибор сменил протокол на ОВЕН, хотя я ему это делать не говорил. Ещё были некоторые проблемы с драйвером виртуального СОМ-порта, после настройки всё заработало.