Проблемы при опросе при прибора по RS-232 (modbus RTU)

[keysansa]

В TCP нет понятия "мастер" и "слейв" - там есть "клиент" и "сервер".

С недавних пор, в связи с движением BLM, и применительно к RTU не рекомендуется использовать понятия "мастер" и "слейв", оптимально - "клиент" и "сервер"
https://www.modbus.org/docs/Client-Ser ... .docx.pdf

Да уж, но все равно, клиент делает запрос мастеру по их спецификации, в не зависимости, RTU, ASCII или TCP

[Jackson]

клиент делает запрос мастеру

Тушим свет.

[leon78]

Да уж, но все равно, клиент делает запрос мастеру по их спецификации, в не зависимости, RTU, ASCII или TCP

Клиент делает запрос серверу, а мастер - слэйву. В сети Modbus никто не может делать запрос мастеру.

[Jackson]

В сети Modbus никто не может делать запрос мастеру.

А если сделает, то это будет уже не модбас. :) Например Модбас Плюс был когда-то - там можно. Но это не Модбас.

[keysansa]

клиент делает запрос мастеру

Тушим свет.

https://modbus.org/docs/Modbus_Applicat ... _V1_1b.pdf
Страница 4-5.

[leon78]

https://modbus.org/docs/Modbus_Applicat ... _V1_1b.pdf
Страница 4-5.

Там описан запрос клиента серверу.
Или вы про что-то другое пишите?

А если сделает, то это будет уже не модбас. :) Например Модбас Плюс был когда-то - там можно. Но это не Модбас.

Modbus Plus отличается от Modbus как протоколом, так и физическим уровнем. Там нет отдельного мастера, маркер передается между каждым равноценным узлом, и на время узел с маркером становится мастером, а опрашиваемые им узлы -слейвами.

[Ryzhij]

Повторим ещё раз соответствие терминов и функций:
Клиент – это мастер в старой терминологии;
Сервер – это по-старому слейв.

Запросы шлет клиент, aka мастер.
Шлет он их одному из серверов, aka слейвов.

Сервер, он же слейв, отвечает на запросы клиента, по–старому мастера, но сам никому никаких запросов не шлёт. Не умеет сервер (слейв) этого делать.

Отправлено спустя 2 минуты 52 секунды:

клиент делает запрос мастеру

Какому? Самому себе что ли? Клиент и мастер это одно и то же, и такое устройство в сети канала последовательной связи одно единственное.

[keysansa]

Клиент делает запрос серверу, а мастер - слэйву. В сети Modbus никто не может делать запрос мастеру.

Там описан запрос клиента серверу.

Да. прошу прощения, Ryzhij, все мне объяснил.
Виноват с терминологией, каюсь.

keysansa писал(а): ↑03 фев 2022, 18:01
клиент делает запрос мастеру


Тушим свет.

Да уж, но все равно, клиент делает запрос мастеру по их спецификации, в не зависимости, RTU, ASCII или TCP

Клиент делает запрос серверу, а мастер - слэйву. В сети Modbus никто не может делать запрос мастеру.

Ну и классика

Это ещё не класика. Классика - это "протокол-то какой?" :)

Вас обманули. Или вы что-то не поняли.
В протоколах Modbus RTU/ASCII инициатор связи именуется мастером, в Modbus-TCP эти функции выполняет клиент. Отвечают слейвы и серверы соответственно.

Все вот тут объясняют мне, что я теперь не правильно Master-Slave, а правильно Server-Client понял,и когда я путаю старый мастер и новый client, нужно указать на ошибку.
Но вы мне это в личку напишите, я понимаю, что путаюсь, но тут это зачем?

rwg, один, по-моему, ответил, конкретно на вопрос ТС.

[Jackson]

нужно указать на ошибку.

Нужно просто просчитать спецификацию ModBUS, старую, только и всего.

[egorsubbotin]

Мне кажется, что проблема очевидная - после 2-3 минут работы у устройства зависает подпрограмма обмена по СОМ-порту. Например такое встречается у Овеновских ТРМов с прошивкой до февраля 2017 года (если правильно помню), только они перестают отвечать по Modbus RTU в случайный момент времени через несколько часов-месяцев после включения. Там приходится использовать Modbus ASCII или отключать питание прибора на пару секунд

Прибор не поддерживает обмен по ASCII, чтобы проверить ваше решение, к сожалению(

Отправлено спустя 1 минуту 35 секунд:

На уровне интерфейса RS-232 сигнал готовности порта прибора Ready анализируется? В кабеле он распаян?

А разве, при трехпроводном соединении RS232 и неверно установленной конфигурации синхронизации будет хоть какой-то обмен? У меня ни разу не было, что бы при установке RTS/CTS на трехпроводном соединении хоть что-то пошло.

[29.01.2022 8:38:22.696] Err : COM 4.LS NT:Включен таймаут ошибки запроса 1
[29.01.2022 8:38:22.696] Err : COM 4:Реиницилизация узла
[29.01.2022 8:38:22.825] Inf : COM 4:Порт 4 закрыт
[29.01.2022 8:38:22.825] Inf : COM 4.LS NT:Ошибка опроса устройства
[29.01.2022 8:38:33.435] Inf : COM 4:Порт 4 открыт
[29.01.2022 8:38:33.435] Inf : COM 4.LS NT:Старт опроса устройства
[29.01.2022 8:38:33.443] TRACE : (COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
[29.01.2022 8:38:38.496] TRACE : (COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
[29.01.2022 8:38:43.540] TRACE : (COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
[29.01.2022 8:38:48.580] TRACE : (COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
[29.01.2022 8:38:53.634] TRACE : (COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
[29.01.2022 8:38:58.673] Err : LS NT:Ошибка выполнения команды 3 <<Small input buffer (4 or 5)>> в устройстве 9 from LS NT:HOLDING_REGISTERS

Тут видно, что ответа от мастера нет вообще, слейв COM порт переоткрывает (делает ли Flush буферов - не понятно, но скорее всего делает, и даже если это не так, проходит 5 посылок и 5 секунд).

Я согласен с rwg, наиболее вероятно - перестает отвечать удаленное устройство. Можно, для достоверности, конечно, "поснифить" обмен, но врядли что-то новое будет, судя по опыту.

Реиницилизация порта в этот раз включена, для проверки возможного зависания порта

Отправлено спустя 1 минуту 54 секунды:

А какие параметры настройки RS-232 у logoscreen CF?

Отправлено спустя 53 минуты 38 секунд:
А вот еще вопрос к egorsubbotin - используете интерфейсный кабель ПК с преобразователем TTL/RS232 и адаптером, или напрямую соединение между портами?

Преобразователь moxa uport 1150
Параметры:
-скорость 9600
-Данные 8,1, без контроля четности
-сейчас мин. время отклика установлено 50 мс
-протокол модбас РТУ

[Jackson]

используете интерфейсный кабель ПК с преобразователем TTL/RS232 и адаптером, или напрямую соединение между портами?

Преобразователь moxa uport 1150

Moxa uPort1150 так же далек от TTL, как я от космонавтики.

[olexsa]

Moxa uPort1150 так же далек от TTL, как я от космонавтики.

Уважаемый Jackson, , но ведь нам неизвестно, насколько Вы далеки от космонавтики. Читая Ваши комментарии, сообщения на форуме, ничуть не удивлюсь, если окажется, что очень даже близки к ней.

Отправлено спустя 4 минуты 19 секунд:

Преобразователь moxa uport 1150

egorsubbotin, А можете не на словах, а схематично изобразить связь оборудования между собой?

[Ryzhij]

https://www.jumo.sk/media/PDFs/Support_ ... .2.0en.pdf
В описании интерфейса прибора про уровни TTL для связи я упоминания не нашёл (TTL там только для лицевого конфигурационного разъёма), но был удивлён максимальным временем задержки ответа регистратора в одну секунду (стр. 13).
Стандарт Modbus-RTU, если я верно помню, устанавливает максимальное время ожидания ответа в 5 раз меньше - 200 мс.
Может, в этом всё дело? Мастер (пардон - клиент) просто не дожидается ответа?

[Jackson]

Стандарт Modbus-RTU, если я верно помню, устанавливает максимальное время ожидания ответа в 5 раз меньше - 200 мс.
Может, в этом всё дело? Мастер (пардон - клиент) просто не дожидается ответа?

И в мануале и описано как с этим быть:

Internal waiting time of the paperless recorder before checking the
data request, and the internal processing time.
min.: 12.5 msec
typical: 12.5 — 30 msec
max. 1 sec
A minimum response time can be set in the instrument, under the
menu item Configuration ➔ Interface. This preset time is the
minimum waiting time that must elapse before an answer is
transmitted (0 — 500 msec). If a smaller value is set, then the
response time may be longer than the preset value (because the
internal processing time is longer), the recorder will then answer as
soon as the internal processing is completed. A preset time of 0
msec means that the recorder answers with the maximum possible
speed.
The minimum response time which can be set is required by the
RS485 interface in the master, in order to switch over the interface
driver from transmit to receive. This parameter is not required for
the RS232 interface.

С последним подчеркнутым я не согласен, но в целом мастер можно и настроить же, а в слейве время в 0 установить навсегда.

[Ryzhij]

но в целом мастер можно и настроить же, а в слейве время в 0 установить навсегда.

Ну, тут такое дело... Мы конечно можем по-просить слейв не торопиться с ответом, если мастер не готов сразу принять отклик после запроса, устанавливая МИНИМАЛЬНОЕ время задержки ответа, но вот на МАКСИМАЛЬНОЕ время задержки слейва (сервера) мы влиять не можем.

...the recorder will then answer as
soon as the internal processing is completed.

Если мастер позволяет в режиме RTU выставить время ожидания ответа более 200 мс, до 1 с, это ж будет отлично.
Беда только в том, что такие длительные задержки допускает лишь спецификация Modbus-ASCII.

[Jackson]

Мы конечно можем по-просить слейв не торопиться с ответом, если мастер не готов сразу принять отклик после запроса, устанавливая МИНИМАЛЬНОЕ время задержки ответа, но вот на МАКСИМАЛЬНОЕ время задержки слейва (сервера) мы влиять не можем.

Да, но судя по тому что там пишут про то, что быстродействие слейва сильно меньше чем может быть минимальное время отклика... Я ж не зря полную цитату закинул.

Если мастер позволяет в режиме RTU выставить время ожидания ответа более 200 мс, до 1 с, это ж будет отлично.
Беда только в том, что такие длительные задержки допускает лишь спецификация Modbus-ASCII.

Зависит от конкретного мастера. В модбас-пуле ведь выставляй хоть 10 секунд, в контроллерах я тоже видел времена таймаутов секунд по 3-5. Пусть топикстартер смотрит свой мастер в этой части, я считаю.

[keysansa]

8-01-2022 11:21:32.446 COM 4::LS NT:(COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
28-01-2022 11:21:16.933 COM 4::LS NT:(COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
28-01-2022 11:21:11.853 COM 4::LS NT:(COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
28-01-2022 11:21:06.757 COM 4::LS NT:(COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
28-01-2022 11:21:01.648 COM 4::LS NT:(COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
28-01-2022 11:20:56.490 COM 4::LS NT:(COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D
28-01-2022 11:20:55.375 COM 4::LS NT:(COM4) Rx: [0009] 09 03 04 50 00 48 43 15 02
28-01-2022 11:20:55.282 COM 4::LS NT:(COM4) Tx: [0008] 09 03 00 35 00 02 D5 4D

Это лог, когда все нормально. Выложите при срыве передачи лог.

[Ryzhij]

Это лог, когда все нормально. Выложите при срыве передачи лог.

Что тут нормального? Запросы (передача) есть, а ответы (прием) прекращается.
Когда не будет передачи запросов и будет отсутствовать прием ответов, это тоже будет нормально

[Ryzhij]

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

Хороший совет был дан в самом начале топика.
Поскольку больше секунды, по документации, должен быть не просто период опроса, а пауза на ожидание ответа слейва, то есть смысл для проверки учесть длительность посылки запроса от мастера.
Это можно сделать, если знать скорость и формат передачи.

Параметры:
-скорость 9600
-Данные 8,1, без контроля четности
-сейчас мин. время отклика установлено 50 мс
-протокол модбас РТУ

При таких параметрах посылка запроса в 8 байт займёт 8*10/9600=83,3 мс
Вывод - настройки слейва, в общем-то, нормальные, что-то со слейвом.
Надо искать, что заставило его стать таким "задумчивым".
Флеш-карту менять не пробовали? Может она сбоит и заставляет тормозить регистратор?

[Jackson]

Это лог, когда все нормально.

То есть запросы без ответов - это нормально? Не знал...

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

По этому логу кстати видно, что когда ответ приходит - он приходит за ~150мсек. Так что Ryzhij прав. Возможно и другие ответы все приходят, но не за 150мсек а за 180, 200, 300, 1000 - в мануале же написано что это возможно. Просто мастер этих ответов не видит, потому что уже не ждёт. Возможно.

Отправлено спустя 3 минуты 46 секунд:
"О чём думает курица, убегающая от петуха? Умная курица думает: а не слишком ли быстро я бегу?"

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

"Всё достаётся умеющему ждать"

[Ryzhij]

Просто мастер этих ответов не видит, потому что уже не ждёт. Возможно.

И это возможно. Мы не знаем настроек мастера.

[Jackson]

И это возможно. Мы не знаем настроек мастера.

Да. Я и рекомендовал поэтому:

Зависит от конкретного мастера. ... ... ... Пусть топикстартер смотрит свой мастер в этой части, я считаю.

[keysansa]

Это лог, когда все нормально. Выложите при срыве передачи лог.

Что тут нормального? Запросы (передача) есть, а ответы (прием) прекращается.
Когда не будет передачи запросов и будет отсутствовать прием ответов, это тоже будет нормально

В этом логе пакеты либо целиком принимаются, либо отбрасываются. Это не тот лог, который хотелось увидеть.
Хочется увидеть куски отброшенных данных, это часто дает понять, что не так с данными.
Если это подробный лог, то становится понятно, что клиент (не запутаться бы в новой терминологии) не понимает, что к нему запрос был. Но через 3-4 раза, отвечает.
Беда с линией связи, думается.
Но только, если лог полный.

Отправлено спустя 3 минуты 44 секунды:

По этому логу кстати видно, что когда ответ приходит - он приходит за ~150мсек. Так что Ryzhij прав.

150 мс для модбас - это много.

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

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

[leon78]

Если это подробный лог, то становится понятно, что клиент (не запутаться бы в новой терминологии) не понимает, что к нему запрос был. Но через 3-4 раза, отвечает.

клиент
сервер

[Ryzhij]

Это херня, извините.

Да, вот с такой вот фигнёй мы и работаем.
Не верите?
Читайте доку сами. Ссылка у Вас есть.