ТРМ-201 + Siemens HMI MP377. Modbus RTU

[FPavel]

Да, прошу прощения, неправильно по памяти записал нотацию...

Конечно же, нужно было как поправил AlexandrGr, а написал в смысле как уточнил melky.

Функцией 03 читают регистры 4x (Holding register), которые имеют диапазон значений 40001...49999 (они же при помещении в запрос имеют значения 0...9998). Т.е. 40001 это логический адрес регистра, а 0 это его же физический адрес.
В разных реализациях Modbus по разному разрешается задавать адрес. Например, в ПЛК Koyo DL06 адрес регистра задавался логический и физический адрес регистра из карты Modbus для подключаемого прибора (в моём случае ВКТ-5) никак не подходил по диапазону (40001...49999) - потребовалось приведение к логическому.

[polubencev]

Всем спасибо, решено! RS-485 надо было А к В, В к А. Странно конечно, ну да ладно. А так да, правильно сказали - регистр 44105

[kon48]

Уважаемые коллеги!
Завал! Кто поможет буду вспоминать с благодарностью.
Проблема - пытаюсь выполнить опрос приборов ОВЕН (ТРМ10, ТРМ201 и др.) по протоколу Modbus Rtu средствами API и полный швах, мыслей нет.
Представляю прототип программы в среде Delphi 11.
Срочности никакой нет. Просто хочу понять как реализовать.
С праздником Пасхи и наступающими праздниками.
С уважением

[Cs-Cs]

У меня дельфи нет, я прогал раньше.
Я просто так открыл блокнотом код и стал смотреть ради интереса, поэтому могу дать ложную надежду.
К чему хочу придраться:
1. Все вот эти вот "Memo1.Lines.Add" указывают на то, что проект делался быстро-быстро и криво.
Лучше бы ты сделал процедуру типа AddToLog, и красиво её вызывал. Потому что если ты когда-нибудь захочешь поименовать Memo1 во что-то понятное типа txtLog, то замучаешься везде исправлять.
2. Не понял, зачем там разные расчёты CRC. Ты же делаешь опрос по Modbus RTU! А там CRC имеет ОДИН единственный алгоритм.
Вообще даже Modbus - медленный протокол. CRC явно считается быстрее, чем передача данных по протоколу.
3. Я не увидел составления посылок для протокола Modbus в принципе. Ты там тестируешь CRC, выводишь всякую инфу о возможностях портов... а где посылки данных-то?

Мои мысли о том, что тебе надо сделать:
0. Видимо, почитать про протокол Modbus. Он же работает как Запрос-Ответ. То есть, чтобы получить данные - надо что-то ПОСЛАТЬ. А у тебя в коде на "btnWritePortClick" написано "Пока Не использую".
1. Потренироваться опрашивать настоящие устройства через другие программы так, чтобы ты видел там реальные байты, какие идут между ними. Эти самые Запросы-Ответы. Такие программы могут быть OPC-серверами, Modbus Poll и прочими.
2. Разобраться с тем, как посылать и принимать байты в порт.
Составляешь массив байтов и потправляешь его в порт.
И получаешь данные из порта и склеиваешь их в массив байтов. НЕ в строку, так как строка с байтами работать не будет.
3. Потом из документации по Modbus понять, как составлять запрос (Адрес, Команда, Данные, CRC).
И уже его отсылать и смотреть, что тебе ответят.

[kon48]

У меня дельфи нет, я прогал раньше.
Я просто так открыл блокнотом код и стал смотреть ради интереса, поэтому могу дать ложную надежду.
К чему хочу придраться:
1. Все вот эти вот "Memo1.Lines.Add" указывают на то, что проект делался быстро-быстро и криво.
Лучше бы ты сделал процедуру типа AddToLog, и красиво её вызывал. Потому что если ты когда-нибудь захочешь поименовать Memo1 во что-то понятное типа txtLog, то замучаешься везде исправлять.
2. Не понял, зачем там разные расчёты CRC. Ты же делаешь опрос по Modbus RTU! А там CRC имеет ОДИН единственный алгоритм.
Вообще даже Modbus - медленный протокол. CRC явно считается быстрее, чем передача данных по протоколу.
3. Я не увидел составления посылок для протокола Modbus в принципе. Ты там тестируешь CRC, выводишь всякую инфу о возможностях портов... а где посылки данных-то?

Мои мысли о том, что тебе надо сделать:
0. Видимо, почитать про протокол Modbus. Он же работает как Запрос-Ответ. То есть, чтобы получить данные - надо что-то ПОСЛАТЬ. А у тебя в коде на "btnWritePortClick" написано "Пока Не использую".
1. Потренироваться опрашивать настоящие устройства через другие программы так, чтобы ты видел там реальные байты, какие идут между ними. Эти самые Запросы-Ответы. Такие программы могут быть OPC-серверами, Modbus Poll и прочими.
2. Разобраться с тем, как посылать и принимать байты в порт.
Составляешь массив байтов и потправляешь его в порт.
И получаешь данные из порта и склеиваешь их в массив байтов. НЕ в строку, так как строка с байтами работать не будет.
3. Потом из документации по Modbus понять, как составлять запрос (Адрес, Команда, Данные, CRC).
И уже его отсылать и смотреть, что тебе ответят.

Спасибо за советы. С чем то соглашусь. Почему в Delphi? Она мне ближе.
Проект делал долго. Криво? Соглашусь спора нет.
Документацию читал, изучал, вопросов по протоколу нет.
Расчет CRC разными алгоритмами провел для их сравнения по быстродействию. Для себя определил наимолее быстпый и им пользуюсь.

3. Потом из документации по Modbus понять, как составлять запрос (Адрес, Команда, Данные, CRC).
И уже его отсылать и смотреть, что тебе ответят

Формирование команды запроса реализовано. Как внутри запроса на Чтение, так и отдельной командой. Но вот здесь и кроются проблемы.
В *zip файле есть исплняемая программа. Там можно посмотреть на формирование команды.
С уважением

[FPavel]

Как-то для изучения Modbus делал простенькую консольную программу на FreePascal - опрашивал измеренное значение на ТРМ212.
Для обмена с портом использовал библиотеку Synaser (она - часть библиотеки Synapse).

Сделал примитивно - запрос-ответ (с учётом таймаута).
А правильно - нужно работать с потоками, чтобы интерфейс не зависал.
Встречал ссылку на статью "Работа с COM-портом с помощью потоков", с комментарием, что в ней правильно описано
https://usbsergdev.narod.ru/doc.html

Могу и свои наработки показать, но они примитивные, незаконченные в части диагностики обмена.
Работа в консоли меня не напрягает, приоритет отдаю функционалу утилиты (тест прибора нужно выполнить здесь и сейчас, а не зависать над красотами GUI) и поэтому программа консольная. Вывод консоли можно легко перенаправить в текстовый файл и сравнивать файлы из меню файл-менеджеров.
Использую их с небольшими изменениями под ситуацию для диагностики обмена по Modbus - то сканировать все адреса+скорость+чётность, то сканировать все регистры у устройства. Можно и готовый ModbusPoll использовать, но он платный, а у меня руки есть - могу сам сделать.
В прошлом году нужно было обосновать неправильность чужой программы комплекса на нескольких ПР200 - нужно было показать, что нет обмена состояниями от одного из Slave. Сначала доказал, что на Slave доступен всего один регистр для чтения, потом показал, что он не изменяется при большинстве нештатных ситуаций. Все проверки - модификациями этой программы.
TestModbusSynaser.zip

Также, для обмена с устройствами производства Овен есть готовая библиотека и к ней идут примеры
https://owen.ru/product/biblioteka_win_dll

[kon48]

Моя цель - выполнять запросы посредством функций API (ReadFile и WriteFile);
Взаимодействие с приборами ОВЕН по протоколу ОВЕН мною давно освоены. Сейчас проблема с Modbus RTU т.к. тенденция разработчика это полный отказ от протокола ОВЕН. Могу и ошибатся.
С уважением

[FPavel]

В статье по ссылке - как раз WinAPI, только с применением потоков. А что язык программирования не Delphi, так для WinAPI названия и параметры точно совпадают.

Библиотеку Овен можно посмотреть - там не только протокол ОВЕН. Но, если нужно самостоятельные реализации без внешних dll, то конечно, библиотека не подойдёт.

Библиотеку Synaser всё равно рекомендую - она открытая, богатая на подпрограммы, и тоже на WinAPI (где-то в глубине) - там есть и настройки таймаутов.

По Вашей проблеме ничего не понятно. Вы привели код. Какая у него проблема? Нет опроса?
Тогда установите на компьютер прослушку (сниффер) COM-порта, подключитесь к нужному и смотрите дамп обмена - или не то посылаете или не обрабатываете ответ или порт не так настроен - будет хотя бы понятно, чего не хватает.

[kon48]

За исчерпывающую информацию спасибо. Непременно ей воспользуюсь.
Посмотрел документацию на библиотеку и, к своему сожалению, не нашел функций работы с протоколом Modbus RTU. Упоминается протокол ОВЕН.